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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 31 Jul 2006 19:01:46 -0400

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-masked]]
> 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-masked]]
> > 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-masked]]
> > > 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-masked]]
> > > 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-masked]]
> > > > 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-masked]]
> > > > 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-masked]
> > > > 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-masked]
> > 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]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 31 Jul 2006 18:08:41 -0500

Brian,
 
So the two things are linked then?
 
It is my belief that the consensus is in favour of what Henning suggested, and that is what I would like.
Perhaps you would like to include precisely that position in your next quest for consensus, rather than trying to re-word it and losing the intent.
 
Cheers
James

From: Rosen, Brian [mailto:[email-masked]]
Sent: Mon 31/07/2006 6:01 PM
To: Dawson, Martin; Winterbottom, James; IETF SIP List
Cc: GEOPRIV
Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does Location-Conveyance have an HTTP dereferencemechanism defined

Brian

Does
different
entities
meet
to
with
That
and
a
mentioned
header
information.

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 31 Jul 2006 19:24:24 -0400

No James, the two threads are not linked.  The first asks if there is any
reference to HTTP use in dereferencing.  The other discusses what the text,
and the resulting ABNF says about dereferencing in general.

Note in the message below, the token "http" does not appear, yet the text is
readable.

IF we were to include an http based dereferencing protocol in location
conveyance AND we were to have a more semantically correct ABNF, THEN you
would see HTTP in the list of protocols.  However, you can answer the
questions independently without any problem.

Henning said we should not syntactically limit the ABNF.  The "more
specific" ABNF directly addresses that concern, and Jeroen's concern about
diagnostics by including AbsoluteURI as an alternative.  I'm bowing to list
consensus on strictly limiting the ABNF.  

Let's get back to the question, which in this thread is "what does the text
say about what can appear in the Location URI?"

Brian

> Sent: Monday, July 31, 2006 7:09 PM
> To: Rosen, Brian; Dawson, Martin; IETF SIP List
> Cc: GEOPRIV
> Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does
> Perhaps you would like to include precisely that position in your next
> quest for consensus, rather than trying to re-word it and losing the
> intent.
> 
> Cheers
> James
> 
> Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does