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

[Paul Kyzivat <[e-mail]>]

I have a bunch inline here.
This supersedes my earlier suggested ABNF change.

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

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

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