RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined

Can't let go can you?  I changed the subject line to start a different
thread.  I'd still like the answer to the original thread.

There are two separable issues with respect to the ABNF.  The syntactic
and the semantic.

The syntactic issues could be dealt with by saying:

location-param = LAQUOT loc-URI RAQUOT *( SEMI loc-param ) 
;cid-url from RFC2392, SIP/SIPS-URI from RFC3261, PRES-URI from RFC3859 
;Absolute URI from RFC3261
loc-URI = cid-uri / SIP-URI / SIPS-URI / PRES-URI / AbsoluteURI

This answers Henning and Jeroen's objection to strictly limiting the
ABNF.
The alternative is to just use AbsoluteURI.

I guess the question is, what does the text say? I can make the ABNF
match what the text says.

Does the text say: any URI can appear in the location header, entities
must use some undefined mechanism to maintain interoperability.

Does it say: location dereferencing is a "using protocol" as defined in
geopriv requirements.  Any URI found in the location header MUST meet
the requirements of a using protocol.

Does it say: This document describes the use of SIP and SIPS as a
dereferencing protocol (and the use of a pres: uri if the resolution of
the pres: scheme in the referenced domain is to a presence service using
the sip/sips protocol).  All entities using the Location header MUST
support SIP dereferencing.  

Does it say (if the paragraph immediately above is there): Other
protocols used for dereferencing MUST have a (?standards track?) RFC
defining how to dereference.

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:[email protected]]
> Sent: Monday, July 31, 2006 6:19 PM
> To: Rosen, Brian; IETF SIP List
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP
> dereferencemechanism defined
> 
> Not true
> 
> "> This is NOT the discussion of what the ABNF of the location header
> looks
> > like (although it would NOT have http/https in it for sure if we
agree
> > that an HTTP dereference protocol is a separate draft)."
> 
> This is a discussion on ABNF and what the document contains, and to
that
> extent they are not separable.
> The consensus has been, do not restrict the ABNF, keep the discussion
in
> the document about references limited. I am failing to understand why
you
> can't accept that.
> 
> 
> 
> ________________________________
> 
> From: Rosen, Brian [mailto:[email protected]]
> Sent: Mon 31/07/2006 5:05 PM
> To: Winterbottom, James; IETF SIP List
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP
> dereferencemechanism defined
> 
> 
> 
> Please don't change the subject, I understand the controversy on
> constraining the ABNF.  I tried (apparently without success) to
separate
> those issues.
> 
> I'm asking if anyone objects to NOT mentioning HTTP in any way with
> respect to dereferencing URIs carried by the Location header.  That is
> the only question I asked.
> 
> I'm not trying to evade the constrained ABNF issue, and I'm not
implying
> anything tricky.  I simply want to know if it's okay if we leave
> anything that deals specifically with HTTP and the Location header URI
> to another document.
> 
> Brian
> 
> > -----Original Message-----
> > From: Winterbottom, James [mailto:[email protected]]
> > Sent: Monday, July 31, 2006 5:55 PM
> > To: Rosen, Brian; IETF SIP List
> > Cc: GEOPRIV
> > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP
> > dereferencemechanism defined
> >
> > Brian,
> >
> > Your second paragraph re-opens the sore I am afraid.
> > A large number of people have agreed with Henning's statements and
> these
> > are clear:
> > 1) Do not constrain the ABNF
> > 2) Provide minimal description of the reference function.
> >
> > If you insist on saying then that the ABNF will be restricted if
there
> is
> > not matching text, then I think it unlikely that you will reach a
> > consensus.
> >
> > Cheers
> > James
> >
> > ________________________________
> >
> > From: Rosen, Brian [mailto:[email protected]]
> > Sent: Mon 31/07/2006 8:38 AM
> > To: IETF SIP List
> > Cc: GEOPRIV
> > Subject: [Geopriv] Does Location-Conveyance have an HTTP
> > dereferencemechanism defined
> >
> >
> >
> > I have lost track of where we stand on whether the only mentioned
URI
> > schemes in location-conveyance are sip/sips/pres.  I "think" we have
> > agreed that an HTTP/HTTPS dereference is in a separate document, but
> I'm
> > not sure.
> >
> > This is NOT the discussion of what the ABNF of the location header
> looks
> > like (although it would NOT have http/https in it for sure if we
agree
> > that an HTTP dereference protocol is a separate draft).
> >
> > If you think location-conveyance DOES have HTTP dereference text in
> it,
> > please say so, and please explain why you would not be satisfied if
> > there were a separate draft on the subject.
> >
> > Brian
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
> >
> >
>
------------------------------------------------------------------------
> --
> > ----------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> >
>
------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
> 
> 
> 
>
------------------------------------------------------------------------
--
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
>
------------------------------------------------------------------------
--
> ----------------------
> [mf2]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip