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

[Anders Kristensen <[e-mail]>]

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
>