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

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

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

- but that the Geolocation header *will* have a routing-param
        - which is the "routing-allowed" paramter that RFC 5606 wanted included

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?

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

>    Geolocation-value  = ( locationValue [ COMMA locationValue ] )
>                         / routing-param

but it doesn't, so I'm confused.


>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

?


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

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

>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