Subject: [sipcore] BNF for Geolocation Header proposal

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Jan 2010 17:42:48 -0600

I thought I'd run this by the WG before finalizing the next rev of 
Location Conveyance.  I pretty sure I've solved the BNF issue in 
relation to RFC 5606 (retransmission of SIP location 
conveyance).  Does anyone have any heartburn with this:

   Geolocation      = "Geolocation" HCOLON (locationValue *(COMMA
                         locationValue)) (COMMA retrans-param)
   locationValue    = LAQUOT locationURI RAQUOT SEMI inserted-param
                         *(SEMI geoloc-param)
   locationURI     = sip-URI / sips-URI / pres-URI
                         / cid-url ; (from RFC 2392)
                         / absoluteURI ; (from RFC 3261)
   inserted-param   = "inserted-by" EQUAL geoloc-inserter
   geoloc-inserter  = DQUOTE hostport DQUOTE
                         / gen-value ; (from RFC 3261)
   geoloc-param     = "used-for-routing" / generic-param ;
                         (from RFC 3261)
   retrans-param    = "routing-allowed" EQUAL "yes" / "no"

The nut of the change is to create the retrans-param, and make it 
COMMA separated from any locationValue in the header.  This is 
because the routing-allowed parameter can exist in the Geolocation 
header value without a locationValue - i.e., when there's no location 
indicated within this SIP request, but there is a policy statement 
about whether this UAC wants its location - potentially inserted by a 
SIP server - to be allowed to retransmitted to a third party (i.e., 
to someone/entity not in the SIP signaling path) by any other in-path entity.

The routing-allowed parameter was moved from the geoloc-param portion 
of the BNF.

An agreement was reached by many (based on 5606) that since there 
should be only one of these parameters - regardless of how many 
locationValues there are in the header - thus making the parameter 
globally applicable. Moving this to the top line seemed best (i.e., 
there can be only one instance of it), instead of parsing though each 
locationValue -- potentially with competing routing-allowed values 
when there is more than one locationValue in the header value.

I'm updating the text now to reflect all of this.

Let me know if this is broken somehow.

James

---

From: [email-masked]
Date: Wed, 27 Jan 2010 14:38:17 +0100

Hi James,

This BNF doesn't allow for the case you describe, i.e. a 
"routing-allowed" param without location value.

Suggestion:
Geolocation      = "Geolocation" HCOLON value *(COMMA value)
value            = locationValue | retrans-param

and then in text describe that there may be at most 1 instance of 
retrans-param ( instead of "enforcing" this via BNF). Has been done 
before, ref. e.g. RFC3323 for the "Privacy" header

Regards,
Jeroen

Citeren "James M. Polk" <[email-masked]>:

> relation to RFC 5606 (retransmission of SIP location conveyance).  
> Does anyone have any heartburn with this:
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jan 2010 09:26:37 -0500

I do see a problem with this. More inline.

	Regards,
	Paul

James M. Polk wrote:
> relation to RFC 5606 (retransmission of SIP location conveyance).  Does 
> anyone have any heartburn with this:
> 
> The nut of the change is to create the retrans-param, and make it COMMA 
> separated from any locationValue in the header.  This is because the 
> routing-allowed parameter can exist in the Geolocation header value 
> without a locationValue - i.e., when there's no location indicated 
> within this SIP request, but there is a policy statement about whether 
> this UAC wants its location - potentially inserted by a SIP server - to 
> be allowed to retransmitted to a third party (i.e., to someone/entity 
> not in the SIP signaling path) by any other in-path entity.
> 
> The routing-allowed parameter was moved from the geoloc-param portion of 
> the BNF.

Section 7.3.1 of 3261 includes:

    Multiple header field rows with the same field-name MAY be present in
    a message if and only if the entire field-value for that header field
    is defined as a comma-separated list (that is, if follows the grammar
    defined in Section 7.3).  It MUST be possible to combine the multiple
    header field rows into one "field-name: field-value" pair, without
    changing the semantics of the message, by appending each subsequent
    field-value to the first, each separated by a comma.  The exceptions
    to this rule are the WWW-Authenticate, Authorization, Proxy-
    Authenticate, and Proxy-Authorization header fields.  Multiple header
    field rows with these names MAY be present in a message, but since
    their grammar does not follow the general form listed in Section 7.3,
    they MUST NOT be combined into a single header field row.

The references format in 7.3 is:

       header  =  "header-name" HCOLON header-value *(COMMA header-value)

Your syntax is in violation of this rule.

Even ignoring the restriction in 3261, there are real implementation 
difficulties with what you have written. Most notably, suppose there are 
two instances of the header in a message:

Geolocation: <location1>;inserted-by="example.com", routing-allowed=yes
...
Geolocation: <location2>;inserted-by="example.org", routing-allowed=no

That would seem to be allowed by your syntax, but makes no sense.

A straightforward way to deal with this would be to create a distinct 
header for this value, separate from the Geolocation header. Another way 
would be:

   Geolocation      = "Geolocation" HCOLON locationArg
                         *(COMMA locationArg)
   locationArg      = locationValue / retrans-param

And then just supply text that says retrans-param may appear at most 
once in a message.

(I think a separate header is cleaner.)

> An agreement was reached by many (based on 5606) that since there should 
> be only one of these parameters - regardless of how many locationValues 
> there are in the header - thus making the parameter globally applicable. 
> Moving this to the top line seemed best (i.e., there can be only one 
> instance of it), instead of parsing though each locationValue -- 
> potentially with competing routing-allowed values when there is more 
> than one locationValue in the header value.
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Jan 2010 11:21:54 -0600

>value            = locationValue | retrans-param

I think the (*COMMA value) means there can be more than one of these 
values in the header.  We only want one retrans-param in all of the 
header (to prevent conflicting indications by this parameter). So is 
this really the right way to do this?  (i.e., it appears to be inconsistent)

James

>>header value without a locationValue - i.e., when there's no 
>>location indicated within this SIP request, but there is a policy 
>>statement about whether this UAC wants its location - potentially 
>>inserted by a SIP server - to be allowed to retransmitted to a 
>>third party (i.e., to someone/entity not in the SIP signaling path) 
>>by any other in-path entity.
>>
>>The routing-allowed parameter was moved from the geoloc-param 
>>portion of the BNF.
>>
>>there can be only one instance of it), instead of parsing though 
>>each locationValue -- potentially with competing routing-allowed 
>>values when there is more than one locationValue in the header value.
>>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Jan 2010 14:24:36 -0600

>I do see a problem with this. More inline.

thanks for reviewing this quickly, Paul!

comments and new text/BNF below

>difficulties with what you have written. Most notably, suppose there 
>are two instances of the header in a message:
>

I knew about this multiple rows scenario, but was looking for a way 
for the BNF to solve it in the single header. I guess that cannot happen.

>A straightforward way to deal with this would be to create a 
>distinct header for this value, separate from the Geolocation 
>header. Another way would be:
>

ok -- I've changed the BNF to

   Geolocation       = "Geolocation" HCOLON (locationArg
                          *(COMMA locationArg)
   locationArg       = locationValue / routing-param
   locationValue     = LAQUOT locationURI RAQUOT SEMI inserted-param
                          *(SEMI geoloc-param)
   locationURI       = sip-URI / sips-URI / pres-URI
                          / cid-url ; (from RFC 2392)
                          / absoluteURI ; (from RFC 3261)
   inserted-param    = "inserted-by" EQUAL geoloc-inserter
   geoloc-inserter   = DQUOTE hostport DQUOTE
                          / gen-value ; (from RFC 3261)
   geoloc-param      = "used-for-routing" / generic-param ;
                          (from RFC 3261)
   routing-param     = "routing-allowed" EQUAL "yes" / "no"

which is what you stated would work above.

I'll also include the text surrounding the routing-allowed parameter 
for review too, including the text about how the routing-allowed 
parameter cannot occur more than once, as well as what to do if a SIP 
intermediary does receive more than one that conflict:

==
   The "routing-allowed" header field parameter is a global parameter
   over any (and all/each) locationValues in the Geolocation header
   field. The placement of the parameter is outside any locationValue,
   appears only once, and is always last in the header field value. The
   routing-allowed parameter can be present when no locationValue is
   present. This scenario sets the routing-allowed policy downstream
   along the request's signaling path.

   This header field parameter only has the values "=yes" or "=no".
   When this parameter is "=yes", any locationValue can be used for
   routing decisions along the downstream signaling path by
   intermediaries. When this parameter is "=no", this means no
   locationValue (inserted by the originating UAC or any (or
   subsequent) intermediary(ies) along the signaling path) can be used
   by any SIP intermediary to make routing decisions. This behavior
   MUST be adhered to. Section 4.3 describes the details on what a
   routing intermediary does if it believes it needs to use the
   location in the SIP request in order to process the message further.

   The practical implication is that when the "routing-allowed"
   parameter is set to "no", if a cid:url is present in the SIP
   request, intermediaries MUST NOT view the location (because it is
   not for intermediaries to view), and if a location URI is present,
   intermediaries MUST NOT dereference it. UASs are allowed to view
   location in the SIP request even when the "routing-allowed"
   parameter is set to "no".

   There MUST not be more than one routing-allowed parameter in any SIP
   request, regardless of when there are cases of more than one
   Geolocation header field rows (i.e., more than one Geolocation
   header in the SIP request, as defined in section 7.3.1 of RFC 3261).
   There does not have to be any routing-allowed parameter present in a
   Geolocation header value of a SIP request. However, the default
   treatment of the absence of the routing-allowed parameter is as if
   it were present, and set to "=no" without exception.

   If a routing-allowed parameter is parsed as set to "=yes", an
   implementation MUST parse the rest of the SIP header for another
   instance of the Geolocation header value to determine if there is
   another instance of the routing-allowed parameter set to "=no". If
   this is the case, the behavior MUST be to process the "=no" only,
   and ignore the "=yes".
==

Does this work (for everyone)? Let me know (fairly soon) if there are 
mods you want to this.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jan 2010 15:53:55 -0500

Inline

James M. Polk wrote:
> I knew about this multiple rows scenario, but was looking for a way for 
> the BNF to solve it in the single header. I guess that cannot happen.
> 
> 
>> header for this value, separate from the Geolocation header. Another 
>> way would be:
>>

You have an extra "(" in the above, just after HCOLON. Just remove it 
and it will be ok.

> I'll also include the text surrounding the routing-allowed parameter for 
> review too, including the text about how the routing-allowed parameter 
> cannot occur more than once, as well as what to do if a SIP intermediary 
> does receive more than one that conflict:
> 
> ==

I think it unwise to impose the "must be last" rule. I don't see that it 
adds anything but grief. If the UAC includes a "Geolocation: 
routing-allowed=yes", and then an intermediary wants to add the actual 
location, a reasonable thing to do would be to simply add another 
Geolocation header, or header field, after the prior onces have been 
examined. Changing the order would be annoying.

>   this is the case, the behavior MUST be to process the "=no" only,

I have mixed feelings about the above. You have already stated that 
there MUST only be one. And now you are stating what to do if there is 
more than one. Usually we don't spec behavior on non-conforming cases.

It might be better to state that there SHOULD only be one, and that when 
there is more than one, "no" takes precedence over "yes".

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Jan 2010 17:20:08 -0600

in-line

At 02:53 PM 1/27/2010, Paul Kyzivat wrote:
>>>>I thought I'd run this by the WG before finalizing the next rev 
>>>>of Location Conveyance.  I pretty sure I've solved the BNF issue 
>>>>in relation to RFC 5606 (retransmission of SIP location conveyance).
>>>>because the routing-allowed parameter can exist in the 
>>>>Geolocation header value without a locationValue - i.e., when 
>>>>there's no location indicated within this SIP request, but there 
>>>>is a policy statement about whether this UAC wants its location - 
>>>>potentially inserted by a SIP server - to be allowed to 
>>>>retransmitted to a third party (i.e., to someone/entity not in 
>>>>the SIP signaling path) by any other in-path entity.
>>>Even ignoring the restriction in 3261, there are real 
>>>implementation difficulties with what you have written. Most 
>>>notably, suppose there are two instances of the header in a message:
>>>
>>>And then just supply text that says retrans-param may appear at 
>>>most once in a message.
>You have an extra "(" in the above, just after HCOLON. Just remove 
>it and it will be ok.

thanks, I've made the correction

>>I'll also include the text surrounding the routing-allowed 
>>parameter for review too, including the text about how the 
>>routing-allowed parameter cannot occur more than once, as well as 
>>what to do if a SIP intermediary does receive more than one that conflict:
>>==
>I think it unwise to impose the "must be last" rule. I don't see 
>that it adds anything but grief. If the UAC includes a "Geolocation: 
>routing-allowed=yes", and then an intermediary wants to add the 
>actual location, a reasonable thing to do would be to simply add 
>another Geolocation header, or header field, after the prior onces 
>have been examined. Changing the order would be annoying.

ok, you've talked me into removing the "must be last" wrt the 
"routing-allowed" parameter.

>there MUST only be one. And now you are stating what to do if there 
>is more than one.

the reason for this (which may be more appropriate in the SIP Proxy 
section, as it only applies to these SIP entities) is bad 
implementations, and what to do with receiving multiple of this 
parameter *from* a bad implementation (trying to prevent entities 
barfing when it likely is 100% the case that the original UAC didn't 
cause this problem, and can't fix it regardless of the 4XX or 5XX 
code in the reply indicating there was a problem with this request).

>Usually we don't spec behavior on non-conforming cases.

Usually we don't spec abilities for SIP servers to inject something 
into request that can cause a bad reaction either - such as the UAC 
and Proxy inserting location of the UAC in the request, yet point to 
two different locations. What's a UAS to do with this?

The prevailing belief coming out of RFC 5606 was that the 
"routing-allowed=no" would rule out any conflicting indication of 
"=yes'. The above text instructs what to do in the case of two 
parameter values that conflict. Perhaps it could be said better.

>It might be better to state that there SHOULD only be one, and that 
>when there is more than one, "no" takes precedence over "yes".

This is a thought... I'd still like to instruct the Proxy that parses 
a "=yes" to have to search for another routing-allowed parameter in 
each Geolocation header value to find out if there is a "=no" also in 
the same request -- and not just jump on the policy of the first 
routing-allowed parameter and move on to something else entirely.

Thoughts?

James

>         Thanks,
>         Paul
>
>>==
>>Does this work (for everyone)? Let me know (fairly soon) if there 
>>are mods you want to this.
>>James
>>
>>>>locationValues there are in the header - thus making the 
>>>>parameter globally applicable. Moving this to the top line seemed 
>>>>best (i.e., there can be only one instance of it), instead of 
>>>>parsing though each locationValue -- potentially with competing 
>>>>routing-allowed values when there is more than one locationValue 
>>>>in the header value.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jan 2010 18:40:34 -0500

at end...

James M. Polk wrote:

>> I think it unwise to impose the "must be last" rule. I don't see that 
>> it adds anything but grief. If the UAC includes a "Geolocation: 
>> more than one.
> cause this problem, and can't fix it regardless of the 4XX or 5XX code 
> in the reply indicating there was a problem with this request).
> 
> Usually we don't spec abilities for SIP servers to inject something into 
> request that can cause a bad reaction either - such as the UAC and Proxy 
> inserting location of the UAC in the request, yet point to two different 
> locations. What's a UAS to do with this?
> 
> "=yes'. The above text instructs what to do in the case of two parameter 
> values that conflict. Perhaps it could be said better.
> 
> This is a thought... I'd still like to instruct the Proxy that parses a 
> "=yes" to have to search for another routing-allowed parameter in each 
> Geolocation header value to find out if there is a "=no" also in the 
> same request -- and not just jump on the policy of the first 

Yes, definitely.

I gather the behavior you are looking for is:

- if a "yes" is present and a "no" is *not* present, then
   routing based on the geoloc is permitted,
- else routing on the geoloc is *not* permitted.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Jan 2010 17:46:26 -0600

at end...

At 05:40 PM 1/27/2010, Paul Kyzivat wrote:
>>>that it adds anything but grief. If the UAC includes a 
>>>"Geolocation: routing-allowed=yes", and then an intermediary wants 
>>>to add the actual location, a reasonable thing to do would be to 
>>>simply add another Geolocation header, or header field, after the 
>>>prior onces have been examined. Changing the order would be annoying.
>>>I have mixed feelings about the above. You have already stated 
>>>that there MUST only be one. And now you are stating what to do if 
>>>there is more than one.
>>barfing when it likely is 100% the case that the original UAC 
>>didn't cause this problem, and can't fix it regardless of the 4XX 
>>or 5XX code in the reply indicating there was a problem with this request).
>>
>>and Proxy inserting location of the UAC in the request, yet point 
>>to two different locations. What's a UAS to do with this?
>>>It might be better to state that there SHOULD only be one, and 
>>>that when there is more than one, "no" takes precedence over "yes".
>>This is a thought... I'd still like to instruct the Proxy that 
>>parses a "=yes" to have to search for another routing-allowed 
>>parameter in each Geolocation header value to find out if there is 
>>a "=no" also in the same request -- and not just jump on the policy 
>>of the first routing-allowed parameter and move on to something else entirely.
>
>Yes, definitely.

good!

>- else routing on the geoloc is *not* permitted.

exactly

Thanks!

James