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

Sure, and so does: "Any URI can be used".  That isn't necessarily a good
thing.

If the text is like the "this document describes how you use
sip/sips/pres" then the ABNF I suggested is more appropriate.

Any ABNF can be significantly reduced if the only thing you are trying
to convey with it is strict syntactic compliance.  No significant
document with large hunks of ABNF in the IETF does that.  We almost
always try to make the ABNF show as much of the semantic meaning as is
reasonable.  If you follow the SIP threads, there are several messages a
month whose answer starts:
"you can't look at the ABNF alone, you have to read the text".  To me,
this is a document failure, unless the ABNF was has to be so ugly to be
completely correct it fails to communicate.  Alas, that happens.  But if
it is possible to simply communicate the semantics in the ABNF, then it
is appropriate to do so.

You can use the "token" construction a whole lot more than we do if all
you want is syntax checking.

Lots of examples in 3261:
Priority        =  "Priority" HCOLON priority-value
priority-value  =  "emergency" / "urgent" / "normal"
                   / "non-urgent" / other-priority
other-priority  =  token


Contact        =  ("Contact" / "m" ) HCOLON
                  ( STAR / (contact-param *(COMMA contact-param)))
contact-param  =  (name-addr / addr-spec) *(SEMI contact-params)
name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec      =  SIP-URI / SIPS-URI / absoluteURI

Let's settle on the words first.  The ABNF will follow.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:[email protected]]
> Sent: Monday, July 31, 2006 6:48 PM
> To: Rosen, Brian; Winterbottom, James; IETF SIP List
> Cc: GEOPRIV
> Subject: RE: [Geopriv] URI restrictions in location conveyance,was
Does
> Location-Conveyance have an HTTP dereferencemechanism defined
> 
> Just using absoluteuri seems like the complete simplification...
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email protected]]
> > Sent: Tuesday, 1 August 2006 8:44 AM
> > To: Winterbottom, James; IETF SIP List
> > Cc: GEOPRIV
> > Subject: 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]
> >
> > _______________________________________________
> > 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]

_______________________________________________
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