Re: [sipcore] draft-ietf-sipcore-location-conveyance-04

["James M. Polk" <[e-mail]>]

At 05:38 AM 10/28/2010, Elwell, John wrote:
>Yes, 4 looks good, but I could live with 1.

I think this has become #1 of two major open issues to address in 
Beijing (along with the supported and unsupported URI schemes and 
their respective possible error codes, as 2a and 2b).

James


>John
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Anders Kristensen
> > Sent: 28 October 2010 05:53
> > To: [e-mail]
> > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04
> >
> > I haven't really followed the discussion closely but I'll say this
> > anyway. Many header fields are of a form similar to Geolocation,
> > essentially lists of URI, and allow for parameters. But I think the
> > parameters are pretty much always associated with individual
> > entries in
> > the list and may be present for more than one.
> >
> >  From what I can tell, in the case of Geolocation, the
> > routing-allowed
> > param is not really attached to any particular entry in the list
> > suggesting that maybe it doesn't belong in the same header field. I
> > think that's the thinking that lead Paul to options 4 or 5 which seem
> > much preferable to me. That allows Geolocation to fit the text in RFC
> > 3261 that talks about combining header fields:
> >
> >     Specifically, any SIP
> >     header whose grammar is of the form
> >
> >        header  =  "header-name" HCOLON header-value *(COMMA
> > header-value)
> >
> >     allows for combining header fields of the same name into a comma-
> >     separated list.
> >
> > Granted, there's no rule that says that header fields with
> > comma-separated values *must* fit the above grammar but ISTM
> > that it's a
> > pretty established pattern which is worth observing.
> >
> > Thanks,
> > Anders
> >
> > On 10/27/2010 9:10 PM, James M. Polk wrote:
> > > At 06:50 PM 10/27/2010, Paul Kyzivat wrote:
> > >> I have a bunch inline here.
> > >
> > > I'll say ;-)
> > >
> > >> This supersedes my earlier suggested ABNF change.
> > >
> > > ack
> > >
> > >
> > >> On 10/27/2010 2:32 PM, James M. Polk wrote:
> > >>> Paul
> > >>>
> > >>> in-line
> > >>>
> > >>> At 08:36 PM 10/26/2010, Paul Kyzivat wrote:
> > >>>> I took a quick look at the new version, and it seems to
> > have cleanup a
> > >>>> lot. But there *still* seems to be a problem with the syntax.
> > >>>> (Interplay between ABNF and text.) From the text, I find:
> > >>>>
> > >>>> The placement of the "routing-allowed" header field parameter,
> > >>>> strongly encouraged by [RFC5606], is outside the
> > locationValue, and
> > >>>> MUST always be last in the header field value. The
> > routing-allowed
> > >>>> parameter MUST be present, even when no locationValue is present.
> > >>>>
> > >>>> This is questionably supported by the ABNF:
> > >>>>
> > >>>> Geolocation-header = "Geolocation" HCOLON Geolocation-value
> > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] )
> > >>>> / routing-param
> > >>>
> > >>> the above, I believe - but am open to be corrected by
> > those better at
> > >>> ABNF syntax that I, says
> > >>>
> > >>> - the Geolocation header can optionally have one or more
> > locationValues
> > >>> - which are where the location URIs go
> > >>
> > >> The above says *a* Geolocation header can have
> > >> - one or two locationValues
> > >> - OR one routing-param
> > >>
> > >> (The slash means OR)
> > >>
> > >> But it doesn't state that the Geolocation header itself can appear
> > >> only once. And obviously if the goal is to have a
> > locationValue AND a
> > >> routing-param in the message, then with the above syntax
> > at least TWO
> > >> Geolocation headers will be required.
> > >>
> > >>> - but that the Geolocation header *will* have a routing-param
> > >>> - which is the "routing-allowed" paramter that RFC 5606
> > wanted included
> > >>
> > >> Since the slash means OR, it doesn't mean it *will*.
> > >>
> > >>> The text of the ID then says that only zero, one or two
> > locationValues
> > >>> are allowed, which we all agreed to in Maastricht (in SIPCORE and
> > >>> ECRIT/GEOPRIV).
> > >>>
> > >>>> locationValue = LAQUOT locationURI RAQUOT
> > >>>> *(SEMI geoloc-param)
> > >>>> locationURI = sip-URI / sips-URI / pres-URI
> > >>>> / http-URI / HTTPS-URI
> > >>>> / cid-url ; (from RFC 2392)
> > >>>> / absoluteURI ; (from RFC 3261)
> > >>>> geoloc-param = generic-param; (from RFC 3261)
> > >>>> routing-param = "routing-allowed" EQUAL "yes" / "no"
> > >>>>
> > >>>> It only works if you presume that there are separate
> > occurrences of
> > >>>> GeoLocation-header in the message, one with just
> > locations, another
> > >>>> with just the routing-param.
> > >>>
> > >>> I don't get that part of your point, but I guess Martin's
> > next message
> > >>> says I need to add a "COMMA" after the ']' but before the
> > ')'. Would
> > >>> this satisfy your issue?
> > >>
> > >> Adding the COMMA and removing the slash would require the
> > >> routing-param, and would separate it from the
> > location-value. But then
> > >> if you only wanted the routing-param without any locationValues you
> > >> would have to write:
> > >>
> > >> Geolocation:,routing-allowed=no
> > >>
> > >> which is at least a bit weird, which I think is what Martin meant.
> > >>
> > >>>> The routing-param certainly can't be "last in the header
> > field value"
> > >>>> except in the degenerate sense, since it must be first
> > and only in a
> > >>>> Geolocation-header.
> > >>>
> > >>> If the routing-param was intended to be first, wouldn't
> > it appear first
> > >>> on this line?
> > >>
> > >> My point was that the syntax as written only allows
> > routing-param by
> > >> itself in a geolocation-header. E.g.
> > >>
> > >> Geolocation:routing-allowed=no
> > >>
> > >> It can't share a single Geolocation header with a
> > locationValue. Hence
> > >> it is *both* first and last in that header.
> > >>
> > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] )
> > >>>> / routing-param
> > >>>
> > >>> but it doesn't, so I'm confused.
> > >>
> > >> Again, the slash means OR. So you have:
> > >>
> > >> Geolocation-value = ( locationValue [ COMMA locationValue ] )
> > >> OR
> > >> Geolocation-value = routing-param
> > >>
> > >> (Though you can't write it that way in ABNF.
> > >>
> > >>>> Below are some specific cases - both valid and invalid.
> > In each case I
> > >>>> show some headers bracketed by "...". That is intended
> > to mean other
> > >>>> headers in a message, but all in the same message. (And
> > when I show
> > >>>> multiple headers, there could be other non-geoloc
> > headers interleaved.)
> > >>>>
> > >>>> * The following are legal according to the above, and
> > probably within
> > >>>> expected usage:
> > >>>>
> > >>>> ...
> > >>>> Geolocation: cid:[e-mail]
> > >>>> Geolocation: routing-allowed=yes
> > >>>> ...
> > >>>>
> > >>>> ...
> > >>>> Geolocation: cid:[e-mail],cid:[e-mail]
> > >>>> Geolocation: routing-allowed=yes
> > >>>> ...
> > >>>>
> > >>>> ...
> > >>>> Geolocation: routing-allowed=no
> > >>>> ...
> > >>>>
> > >>>> * IIUC the following are allowed by the above both
> > syntactically and
> > >>>> according to the text, but is presumably not *intended*
> > to be valid.
> > >>>> (Its legal because the in each instance of Geolocation-header its
> > >>>> last.)
> > >>>>
> > >>>> ...
> > >>>> Geolocation: routing-allowed=no
> > >>>> Geolocation: routing-allowed=yes
> > >>>> ...
> > >>>>
> > >>>> The following is also allowed - I don't know if its
> > intended or not:
> > >>>>
> > >>>> ...
> > >>>> Geolocation: routing-allowed=yes
> > >>>> Geolocation: cid:[e-mail],cid:[e-mail]
> > >>>> ...
> > >>>>
> > >>>> * The following is allowed by the ABNF though disallowed
> > by the text:
> > >>>>
> > >>>> ...
> > >>>> Geolocation: cid:[e-mail],cid:[e-mail]
> > >>>> Geolocation: cid:[e-mail]
> > >>>> ...
> > >>>>
> > >>>> * The following is *not* allowed by the ABNF. I suspect
> > it might be
> > >>>> intended to be valid, but I'm far from sure about it:
> > >>>>
> > >>>> ...
> > >>>> Geolocation: cid:[e-mail],routing-allowed=yes
> > >>>> ...
> > >>>
> > >>> to get this above example "allowed", would I correct the
> > existing ABNF
> > >>> to be
> > >>>
> > >>>> Geolocation-value = ( locationValue [ COMMA
> > locationValue ] COMMA )
> > >>>> / routing-param
> > >>>
> > >>> ?
> > >>
> > >> No. *That* would allow all of the following but not the
> > example above:
> > >>
> > >> Geolocation: cid:[e-mail],
> > >> Geolocation: cid:[e-mail],cid:[e-mail],
> > >> Geolocation: routing-allowed=yes
> > >>
> > >>>> In addition to that, the text is very explicit that:
> > >>>>
> > >>>> The routing-allowed
> > >>>> parameter MUST be present, even when no locationValue is present.
> > >>>>
> > >>>> but then it says:
> > >>>>
> > >>>> If no routing-allowed parameter
> > >>>> is present in a SIP request, a SIP intermediary MAY insert this
> > >>>> value with a RECOMMENDED value of "no" by default.
> > >>>>
> > >>>> So its required, but we have rules to follow if its
> > missing. But I
> > >>>> don't understand how it *can* be required, since the
> > sender of the
> > >>>> request may not understand/support Geolocation and so
> > won't include it.
> > >>>
> > >>> What we're trying to do here is explicitly give
> > instructions to SIP
> > >>> intermediary implementers to include the routing-allowed
> > parameter if
> > >>> one isn't present, with a default value of =no.
> > >>
> > >> I went back and reread the section containing this text. It is in a
> > >> section explicitly about this header. So on reflection I
> > suppose the
> > >> "MUST be present" was intended to imply "in the
> > Geolocation *header".
> > >> I took it to mean "in the request".
> > >>
> > >> Requiring it to be in the header only makes sense if there
> > can be at
> > >> most one header. And then it only makes sense if the
> > syntax is altered
> > >> to allow both the routing-parameter and the locationValue
> > in the same
> > >> header.
> > >>
> > >>>> ISTM that in reality its only *required* if the is a
> > locationValue
> > >>>> present, and is otherwise optional.
> > >>>
> > >>> which is how most would read it if ...
> > >>>
> > >>>> If no routing-allowed parameter
> > >>>> is present in a SIP request, a SIP intermediary MAY insert this
> > >>>> value with a RECOMMENDED value of "no" by default.
> > >>>
> > >>> ... weren't present in the document. But, there is no
> > permission to
> > >>> allow SIP intermediaries to add the routing-allowed
> > parameter, which we
> > >>> wanted to cover.
> > >>
> > >> I'm still confused. Let me state what I think you are after:
> > >>
> > >> - a request may or may not contain a Geolocation header
> > >> - a request may not contain more than one Geolocation header
> > >
> > > of what you have, this one is one I hadn't considered
> > important, but if
> > > that gets everything aligned, then I'm all for adding it in.
> > >
> > >> - a Geolocation header MUST contain a routing-param
> > >> - a Geolocation header Must contain zero, one, or two
> > locationValues
> > >> - you prefer the routing-param to be the last field in the header
> > >> - a proxy MAY add a Geolocation header if one is not present
> > >> (in which case it MUST include a routing-param)
> > >> - a proxy MAY add a locationValue to an existing Geolocation header
> > >> if it doesn't already have two locationValues. (And I guess it
> > >> could add two if there initially were none.)
> > >>
> > >> And you would like ABNF that is consistent with the above.
> > >
> > > with the one caveat, yes.
> > >
> > >
> > >> I'm going to give you some alternatives that should all be
> > >> syntactically correct. I'll give you one that meets the above, and
> > >> some others that may be more appealing variations. Then we can see
> > >> which people prefer.
> > >>
> > >> 1) The following tries to meet the requirements I spelled
> > out above:
> > >>
> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
> > >> Geolocation-value = locationValue [ COMMA locationValue]
> > >> COMMA routing-param
> > >> / routing-param
> > >
> > > I hadn't even thought that was possible, but seeing it, I'm amazed I
> > > didn't try it
> > >
> > > (i.e., it's another classic "I could've had a v8" moment)...
> > >
> > > I'm not as smart as you, Paul <:-|
> > >
> > >> locationValue = LAQUOT locationURI RAQUOT
> > >> *(SEMI geoloc-param)
> > >> locationURI = sip-URI / sips-URI / pres-URI
> > >> / http-URI / HTTPS-URI
> > >> / cid-url ; (from RFC 2392)
> > >> / absoluteURI ; (from RFC 3261)
> > >> geoloc-param = generic-param; (from RFC 3261)
> > >> routing-param = "routing-allowed" EQUAL "yes" / "no"
> > >>
> > >> This must be accompanied by text stating that there MUST be at most
> > >> one Geolocation-header in a request.
> > >
> > > you've sold me on this one (and yes, I examined all the
> > others before
> > > jumping on this first one!). Do others have strong opinions
> > about why
> > > not #1?
> > >
> > > thank you for this!
> > >
> > > James
> > >
> > >
> > >> 2) The following is similar to (1), but allows more than two
> > >> 'locationValue's
> > >>
> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
> > >> Geolocation-value = *(locationValue COMMA) routing-param
> > >> locationValue = LAQUOT locationURI RAQUOT
> > >> *(SEMI geoloc-param)
> > >> locationURI = sip-URI / sips-URI / pres-URI
> > >> / http-URI / HTTPS-URI
> > >> / cid-url ; (from RFC 2392)
> > >> / absoluteURI ; (from RFC 3261)
> > >> geoloc-param = generic-param; (from RFC 3261)
> > >> routing-param = "routing-allowed" EQUAL "yes" / "no"
> > >>
> > >> The same wording is required with it
> > >>
> > >> 3) The following is a copy from my earlier posting:
> > >>
> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
> > >> *( COMMA Geolocation-value)
> > >> Geolocation-value = locationValue / routing-param
> > >> locationValue = LAQUOT locationURI RAQUOT
> > >> *(SEMI geoloc-param)
> > >> locationURI = sip-URI / sips-URI / pres-URI
> > >> / http-URI / HTTPS-URI
> > >> / cid-url ; (from RFC 2392)
> > >> / absoluteURI ; (from RFC 3261)
> > >> geoloc-param = generic-param; (from RFC 3261)
> > >> routing-param = "routing-allowed" EQUAL "yes" / "no"
> > >>
> > >> The above is overly forgiving, in that it permits zero or more
> > >> locationURIs and zero or more routing-params. That then needs to be
> > >> tightened up with text. I think the text needs to say,
> > more or less:
> > >>
> > >> - if there are any locationURIs in a sip request,
> > >> then a routing-param MUST be present in the request
> > >> - there MUST NOT be more than one routing-param present in a
> > >> sip request.
> > >> - there MUST NOT be more than two locationURIs in a sip request
> > >> (if there is really a reason for such a restriction)
> > >>
> > >> 4) The following is a more radical change:
> > >>
> > >> Geolocation-header = "Geolocation" HCOLON locationValue
> > >> [ COMMA locationValue ]
> > >> locationValue = LAQUOT locationURI RAQUOT
> > >> *(SEMI geoloc-param)
> > >> locationURI = sip-URI / sips-URI / pres-URI
> > >> / http-URI / HTTPS-URI
> > >> / cid-url ; (from RFC 2392)
> > >> / absoluteURI ; (from RFC 3261)
> > >> geoloc-param = generic-param; (from RFC 3261)
> > >>
> > >> Georouting-header = "Geolocation-Routing" HCOLON
> > >> ( "yes" / "no" / gen-value )
> > >>
> > >> This one needs to be accompanied by text stating that each of
> > >> Geolocation-header and Georouting-header may appear at most once
> > >> in a request, and that if Georouting-header is absent it defaults
> > >> to "no".
> > >>
> > >> 5) A more lenient variant on (4):
> > >>
> > >> Geolocation-header = "Geolocation" HCOLON locationValue
> > >> *( COMMA locationValue )
> > >> locationValue = LAQUOT locationURI RAQUOT
> > >> *(SEMI geoloc-param)
> > >> locationURI = sip-URI / sips-URI / pres-URI
> > >> / http-URI / HTTPS-URI
> > >> / cid-url ; (from RFC 2392)
> > >> / absoluteURI ; (from RFC 3261)
> > >> geoloc-param = generic-param; (from RFC 3261)
> > >>
> > >> Georouting-header = "Geolocation-Routing" HCOLON
> > >> ( "yes" / "no" / gen-value )
> > >>
> > >> This one needs to be accompanied by text stating that
> > >> Georouting-header may appear at most once in a request, and that
> > >> if Georouting-header is absent it defaults to "no".
> > >>
> > >> (The Geolocation-header can appear zero or more times.)
> > >>
> > >> This is only preferred to (4) if more than two locationValues
> > >> are acceptable. ISTM that once we allowed two, allowing more
> > >> makes sense, with the same limitations imposed with two - that
> > >> its up to the recipient to figure out which to use.
> > >>
> > >> Of the above, I technically and esthetically prefer (5) - or (4) if
> > >> the limitation to two URIs is important. I see no reason
> > to *require*
> > >> the routing-param if the default is understood to be "no".
> > >>
> > >> Pragmatically I think I prefer (1) - its the least
> > variation from what
> > >> has been recently discussed that, IMO, makes any sense.
> > >>
> > >>
> > >>>> In that case, an intermediary that adds a locationValue
> > not only MAY,
> > >>>> but presumably MUST add a missing routing-param if it adds a
> > >>>> locationValue.
> > >>>
> > >>> We can get there (i.e., allow this) without stating this
> > is a MUST,
> > >>> can't we?
> > >>
> > >>>> I have never understood why the routing-param is
> > required to be last.
> > >>>
> > >>> maybe it doesn't need to be, but it certainly is easier for
> > >>> monitoring/reading human to find if it is last when
> > looking at a decode.
> > >>>
> > >>>> And as my examples show, its difficult/impossible to
> > enforce this in
> > >>>> ABNF.
> > >>>>
> > >>>> Thanks,
> > >>>> Paul
> > >>>
> > >
> > > _______________________________________________
> > > sipcore mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
>_______________________________________________
>sipcore mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sipcore