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

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

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