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

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

At 07:53 AM 10/27/2010, Paul Kyzivat wrote:
>I was going to suggest alternative ABNF in my prior posting, but I 
>ran out of time and wanted to send it. So here is a proposal:
>
>    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"

this is what I had before -04, and was told to correct it to what is in -04.

I'm getting so many corrections (i.e., what I currently have is 
considered wrong by someone), I can't tell who's more knowledgeable about this.

Paul, since you're WGC, I'm going to go with this until your (or 
Adam) tell me how to change it.

In other words, it has to come through either of you before I change 
what's in the next version, no matter who tells me (other than my 
co-conspirators writting this).


>This syntax is consistent with 3261 section 7.3:
>
>    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.
>
>(That means there is an equivalence between multiple occurrences of 
>the header, and a single header with multiple fields.)
>
>(I would prefer to have a separately named header for the 
>routing-param, but I think we are too far down the river to make 
>that change now.)
>
>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)
>
>Actually the MUST requirement on the routing-param also seems 
>unmotivated to me. Why not just a default of routing-allowed=no?

that is the default value already in text, but we want to limit this 
to avoid any possible misinterpretation which allows a person's 
(i.e., Target's) location to inadvertently be advertised to any and 
possibly all 3rd parties.

James


>         Thanks,
>         Paul
>
>On 10/27/2010 12:06 AM, Thomson, Martin wrote:
>>On 2010-10-27 at 12:36:02, Paul Kyzivat wrote:
>>>I have never understood why the routing-param is required to be last.
>>>And as my examples show, its difficult/impossible to enforce this in
>>>ABNF.
>>
>>If "routing-allowed" is mandatory, it IS possible:
>>
>>      Geolocation-header = "Geolocation" HCOLON Geolocation-value
>>      Geolocation-value  = [ locationValue [ COMMA locationValue ] COMMA ]
>>                           routing-param
>>
>>It's a little strange, but it does work.  Especially if you also 
>>add text that states there can be only one GeoLocation header?
>>
>>(The other thing that I find strange is the fact that there can be 
>>zero, one or two locationValue parts.  This is confusing for 
>>computer scientists who can only count: zero, one, many.)
>>
>>--Martin