Subject: [sipcore] Call for Consensus: Location Conveyance Syntax

From: Adam Roach - SIPCORE Chair <[email-masked]>
Date: Thu, 03 Feb 2011 13:58:48 -0600

[as chair]

With the changes around ordinality of Geolocation values in SIP 
messages, there were a handful of changes made and/or suggested to the 
Geolocation header field syntax.

Back in October, Paul Kyzivat suggested five concrete ABNF proposals. 
They appear near the bottom of this message:

http://www.ietf.org/mail-archive/web/sipcore/current/msg03594.html

    * James Polk spoke in favor of pursuing option #1, largely because
      it is closest to the current syntax.
    * Anders Kristensen favored #4 and #5 as being more consistent with
      typical SIP header field syntax.
    * John Elwell expressed a preference for #4, although was willing to
      accept #1.

That's not enough feedback to really inform consensus.

As an aside, options #1 and #4 contravene the later consensus expressed 
by the working group to allow an arbitrary number of location values; 
both options #1 and #4 enforce a 2-value maximum. Options #2 and #5 are 
effectively variations on #1 and #4 without such restrictions.

In practice, there are really two issues to resolve here, and we should 
consider them separately:

1. If there are multiple location values in a SIP message, are they:

    (a) Required to appear in a single Geolocation header field, or

    (b) Allowed to appear in a single Geolocation header field, but
        permitted to appear in their own Geolocation header fields?

[No one has yet suggested that they be forced to appear each in their
own header field, so I'm not listing that as an option]

2. Does the "routing allowed" flag:

    (a) Appear as a *field* in a Geolocation header field
        (e.g., "Geolocation: <sip:...>, routing-allowed=yes"), or

    (b) Appear as its own header field
        (e.g., "Geolocation-Routing: yes")

Please weigh in with opinions on these two choices. Be sure to give the 
rationale, however brief it might be, for your decision in your response.

/a

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 03 Feb 2011 14:42:26 -0600

At 01:58 PM 2/3/2011, Adam Roach - SIPCORE Chair wrote:
>messages, there were a handful of changes made and/or suggested to 
>the Geolocation header field syntax.
>
>Back in October, Paul Kyzivat suggested five concrete ABNF 
>proposals. They appear near the bottom of this message:
>
><http://www.ietf.org/mail-archive/web/sipcore/current/msg03594.html>http://www.ietf.org/mail-archive/web/sipcore/current/msg03594.html
>
>    * James Polk spoke in favor of pursuing option #1, largely 
> because it is closest to the current syntax.
there's another reason: if we separate these two header parameters 
into separate SIP header fields, with the default behavior remaining 
<routing-allowed=no>, each time a SIP entity receives a Geolocation: 
header, they will have to search for a "Geolocation-Routing: yes" 
header value if they are configured as an Location Recipient (meaning 
they need explicit permission to actually look at the included 
PIDF-LO message body (part) or dereference the (or any) locationURI 
in any Geolocation: header field.  I have heard some implementers not 
want to have to do this additional processing. Keeping the 
"routing-allowed=yes or no" header parameter within the same 
Geolocation: header field relieves implementers from doing such searches.

Multiple locationValues, and therefore multiple Geolocation header 
values, is NOT RECOMMENDED in the doc (and uses RFC-2119 strength), 
therefore only bad implementations will have multiple instances of a 
Geolocation header with Option #1, which seems easiest, and does not 
really buy us much. I believe the goal lately of this effort is to 
simplify it, and choosing Options #4 or 5 would complicate it 
relative to Option #1.

My personal concern is that (dare I say) lazy implementers *could* 
see a Geolocation: header and not look for the explicit permission 
(if in a separate header value) to view or dereference the location, 
thereby violating the privacy and security considerations of this effort.

James

>    * Anders Kristensen favored #4 and #5 as being more consistent 
> with typical SIP header field syntax.
>    * John Elwell expressed a preference for #4, although was 
> willing to accept #1.
>
>As an aside, options #1 and #4 contravene the later consensus 
>expressed by the working group to allow an arbitrary number of 
>location values; both options #1 and #4 enforce a 2-value maximum. 
>Options #2 and #5 are effectively variations on #1 and #4 without 
>such restrictions.
>
>In practice, there are really two issues to resolve here, and we 
>should consider them separately:
>
>
>        (e.g., "Geolocation: <sip:...><sip:...>, routing-allowed=yes"), or
>
>Please weigh in with opinions on these two choices. Be sure to give 
>the rationale, however brief it might be, for your decision in your response.
>
>/a
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 4 Feb 2011 06:08:42 +0800

On 1. (a) Nothing more than preference; I have insufficient knowledge of other SIP headers to decide based on the basis of precedent/consistency, which is where I would look when everything else is equal.

Experience with HTTP suggests that multiple headers with different values is STRONGLY discouraged because it causes interop failures.  (I acknowledge that this is a superficial argument when we consider the fact that we're inviting interop failure just by allowing multiple values).

On 2. (a) Routing allowed in the same header keeps relevant information together.  The routing-allowed flag is an attribute of the information being conveyed.  That's equally true for 0, 1, 2 or 300 location values.  In this, I agree with James.

On multiplicity: #2 and #5 are preferred to #1 and #4 based on what we've already discussed.

--Martin

On 2011-02-04 at 06:58:48, Adam Roach - SIPCORE Chair wrote:
> *	John Elwell expressed a preference for #4, although was willing
> to accept #1.
> 
> 
>        (e.g., "Geolocation: <sip:...> <sip:...> , routing-
> allowed=yes"),
> or
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Feb 2011 17:46:12 -0500

(as participant, not chair):

> own header field, so I'm not listing that as an option]

Requiring them to appear in a single header field is "weird" from a sip 
syntax perspective.

> (e.g., "Geolocation-Routing: yes")

Combining these into a single header field is again "weird".
It will complicate parsers, which otherwise could use standard patterns.

Because of that I prefer option (5). That will simplify parsing, and 
will allow dropping an additional location into a message without 
messing with the existing header fields.

I don't find the argument compelling that separately searching for the 
routing allowed header is hard. Obviously this depends on the details of 
your stack, but in my experience this ought to be *easier* than the 
alternative.

	Thanks,
	Paul

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 4 Feb 2011 07:24:02 +0800

I should point out that this sort of feedback is probably of more use than my intuition.  I don't have a strong investment in this.  If what Paul suggests makes it easier to implement, then I'm all for that.

BTW, that wouldn't be #5, that would be the simpler child of #5 that has just one locationValue in the header.

--Martin

---

From: Adam Roach <[email-masked]>
Date: Thu, 03 Feb 2011 17:33:33 -0600

(as an individual)

No, it would be #5. There's a difference between "Allowed to appear in a 
single Geolocation header field, but permitted to appear in their own 
Geolocation header fields" and "Forced to appear in their own 
Geolocation header fields."

Having worked on several different SIP stacks, I can say that #5 would 
be, far and away, the easiest thing to implement. I'd re-use the same 
parser for "Gelocation" as I do for the myriad other header fields that 
contain one or more URIs, and then put in another very simple parser 
type for the "Geolocation-Routing" header field.

Under this scheme, it would be very easy for intermediaries who might 
make routing decisions based on location information to first look for 
the "Geolocation-Routing" header field. If it's "no" (or absent), they 
stop, do not pass "Go," do not collect $200, and don't even dream of 
parsing through the "Geolocation" header field. It it's "Yes," they 
parse "Geolocation" and go about doing their location logic.

Pretty clean, if you ask me.

/a

On 2/3/11 5:24 PM, Thomson, Martin wrote:
>>> (e.g., "Geolocation:<sip:...>, routing-allowed=yes"), or
>>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 3 Feb 2011 20:51:00 -0500

+1

Like Martin, I don't much care what color this bikeshed is, but Adam's argument seems pretty cogent to me.  

Maybe just one tiny addendum to the parsing logic: If I were writing the parser, I would probably just read straight through the headers, possibly hitting the Geolocation before the Geolocation-Routing.  So it might not just be "no => don't parse", but "no => don't parse || seek&destroy".  This has absolutely no relevance to the syntax, of course.

--Richard

On Feb 3, 2011, at 6:33 PM, Adam Roach wrote:

> (as an individual)
> 
> No, it would be #5. There's a difference between "Allowed to appear in a single Geolocation header field, but permitted to appear in their own Geolocation header fields" and "Forced to appear in their own Geolocation header fields."
> 
> Having worked on several different SIP stacks, I can say that #5 would be, far and away, the easiest thing to implement. I'd re-use the same parser for "Gelocation" as I do for the myriad other header fields that contain one or more URIs, and then put in another very simple parser type for the "Geolocation-Routing" header field.
> 
> Under this scheme, it would be very easy for intermediaries who might make routing decisions based on location information to first look for the "Geolocation-Routing" header field. If it's "no" (or absent), they stop, do not pass "Go," do not collect $200, and don't even dream of parsing through the "Geolocation" header field. It it's "Yes," they parse "Geolocation" and go about doing their location logic.
>