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

From: Rosen, Brian ^lt;Brian.Rosen@neustar.biz>
Date: Mon Jul 31 2006 - 19:01:46 EDT

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:Martin.Dawson@andrew.com]
> 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:Brian.Rosen@neustar.biz]
> > 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:James.Winterbottom@andrew.com]
> > > 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:Brian.Rosen@neustar.biz]
> > > 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:James.Winterbottom@andrew.com]
> > > > 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:Brian.Rosen@neustar.biz]
> > > > 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
> > > > Geopriv@ietf.org
> > > > 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
> > Geopriv@ietf.org
> > 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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 31 Jul 2006 19:01:46 -0400

This archive was generated by hypermail 2.1.8 : Mon Jul 31 2006 - 19:13:26 EDT