Subject: [sipcore] Location Conveyance -04 submitted, here's the changes

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Oct 2010 23:32:20 -0500

SIPCORE

I've submitted the next version of Location Conveyance (-04)
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-04.txt
and I believe this version has addressed each open item from the 
mailing list, as well as what was discussed and agreed to in the 
Maastricht meeting.

I have attempted to identify each open issue with the specific 
resolution here (in no particular order):

- Martin wanted Section 3 to be broken up into subsections, each 
revolving around each of the 4 diagrams. I have done this.

- allowed a maximum of two (up from one) locationValues to be present 
in the Geolocation header value. The text however recommends against 
inserting a second value. This was agreed to in Maastricht.

- Because we're allowing a max of two locationValues, they can be in 
separate Geolocation headers in the SIP request. This scenario 
necessitates bring a previous version's paragraph in stating that a 
'SIP intermediary MUST inspect all instances of each Geolocation 
header before considering the routing-allowed parameter to be 
considered =yes', to ensure there isn't a conflict in the 'other' 
Geolocation header that states the policy is =no.

- with the ability to add a second locationValue, it is necessary to 
warn against doing this (confusion at the LRs).

- Added the "you break it you bought it" philosophy to SIP 
intermediaries that choose to insert a second location where one 
already existed, especially for inserting a location URI in the 
downstream SIP request.

- Fixed the ABNF to handle zero, one or two (but no more) 
locationValues according to the agreement in Maastricht.  There is a 
one-off use case which won't be in play very often, but is a WG item 
in ECRIT that several wanted to allow the possibility for (involving 
allowing one coarse and one highly accurate location in the same SIP request).

- Paul K. wanted the use-case in which a SIP intermediary inserts a 
locationValue where one didn't exist previously, and received a 424 
(Bad Location Information) to that inserted location, from having the 
424 propagate towards the UAC (as the UAC might not know what to do 
with a 424). This is now covered in Section 4.3.

- changed existing text to "MUST NOT" from "does not" about a 424 not 
terminating an existing dialog (just increased the strength of this.

- I added the 424 to the table 2 entry in which the Geolocation 
header can be in only this response.

- I added text stating the conditions for adding a Geolocation header 
value to the 424, to make it clear what is and what isn't allowed for this.

- Martin wanted me to add back in the top level Geolocation-Error 
codes 100, 200, 300 and 400, which I did in section 4.3.

- rejected the idea that the geolocation option-tag hasn't been justified.

- Added RFCs 2616, 2818 and HELD Deref ID to the references section 
because I added the ability to include HTTP: and HTTPS: URIs, and 
stated if received, they should be dereferenced according to the HELD 
Deref doc.

- changed the Section 5 examples how Martin wanted them.

- Stated that GEO-URIs are not appropriate for the SIP Geolocation 
header, according to the discussion during the Maastricht Geopriv meeting.

- we changed the privacy section, and included a ref to the Geopriv 
Arch doc, according to the agreement in Geopriv at Maastricht.

Comments are encouraged

We plan to request (3rd?) WGLC during the SIPCORE meeting in Beijing 
(to give folks a sense of our plans).

James/Brian/Jon

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 27 Oct 2010 08:01:27 -0400

Thanks a lot for revising this document.

I'm pretty comfortable with the document at this point, but have just  
one minor question: Why are you still limiting the number of location  
values?  Why are three values harmful, but not two?  This still seems  
like pointless ABNF legislation.

--Richard

On Oct 27, 2010, at 12:32 AM, James M. Polk wrote:

> - allowed a maximum of two (up from one) locationValues to be  
> present in the Geolocation header value. The text however recommends  
> against inserting a second value. This was agreed to in Maastricht.
>
> (Bad Location Information) to that inserted location, from having  
> the 424 propagate towards the UAC (as the UAC might not know what to  
> do with a 424). This is now covered in Section 4.3.
>
> - changed existing text to "MUST NOT" from "does not" about a 424  
> not terminating an existing dialog (just increased the strength of  
> this.
>
> - I added text stating the conditions for adding a Geolocation  
> header value to the 424, to make it clear what is and what isn't  
> allowed for this.
>
> stated if received, they should be dereferenced according to the  
> HELD Deref doc.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Oct 2010 15:17:53 +0200

I am happy to see that http and https are added as schemes in locationURI. However, looking at 4.6, I am still uncomfortable that SIP-, SIPS- and PRES-URI are recommended and but HTTP- and HTTPS-URI are not recommended (by virtue of the fact they are only MAY strength, for use when one disregards the SHOULD for SIP-, SIPS- and PRES-).

We had an earlier thread starting here:
http://www.ietf.org/mail-archive/web/sipcore/current/msg03149.html
in which questions were asked about what one must support. The text in 4.6 says nothing about what a LR must support. The implication is that it either has two support all of the 5 schemes listed for sending in a request, or it can choose which to support and reject any that it doesn't support.

In practice, as pointed out on the thread, the schemes effectively boil down to 2 mechanisms: SIP and HTTP (if we for now ignore the absoluteURI option, which effectively leaves it open ended). So perhaps it is not unreasonable to mandate support for all 5 schemes (both mechanisms) by a recipient, although it does raise the bar somewhat for recipient implementations. I recall there was some interest on the thread in limiting to a single MUST support, and some interest in that scheme being HTTP(S). I am not sure we reached consensus on this. I don't have a strong opinion, but we certainly need some text to clarify things one way or the other.

Furthermore, it is unclear which code to use in a 494 response when rejecting an unsupported scheme - presumably the top level 400, but that says nothing about why dereference failed. Even if all the named schemes were MUST support (so you would never reject these), there could be other schemes under absoluteURI that you would want to reject.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: 27 October 2010 05:32
> To: [email-masked]
> Subject: [sipcore] Location Conveyance -04 submitted, here's 
> the changes
> 
> SIPCORE
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 13:38:44 -0500

>like pointless ABNF legislation.

we only added the ability to have a second locationValue because of 
your rough-loc ID. Before that, we were firm in not allowing more 
than one.  Given that choice, which do you like?

Remember, this was Jon's proposal in SIPCORE in Anaheim, which it 
seemed everyone and their brother was agreeable with, so ...

james

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 14:04:31 -0500

At 08:17 AM 10/27/2010, Elwell, John wrote:
>I am happy to see that http and https are added as schemes in 
>locationURI. However, looking at 4.6, I am still uncomfortable that 
>SIP-, SIPS- and PRES-URI are recommended and but HTTP- and HTTPS-URI 
>are not recommended (by virtue of the fact they are only MAY 
>strength, for use when one disregards the SHOULD for SIP-, SIPS- and PRES-).

well... this is a SIP document, why shouldn't a SIP-based URI be 
recommended? Do you want me to say HTTP:/HTTPS: is allowed in some other way?

>in which questions were asked about what one must support. The text 
>in 4.6 says nothing about what a LR must support. The implication is 
>that it either has two support all of the 5 schemes listed for 
>sending in a request, or it can choose which to support and reject 
>any that it doesn't support.

right now it is the latter, but I would - if I must - propose making 
SIP:/SIPS:/PRES: mandatory if there is any URI scheme that is (again, 
this is a SIP doc).

>In practice, as pointed out on the thread, the schemes effectively 
>boil down to 2 mechanisms: SIP and HTTP (if we for now ignore the 
>absoluteURI option, which effectively leaves it open ended). So 
>perhaps it is not unreasonable to mandate support for all 5 schemes 
>(both mechanisms) by a recipient, although it does raise the bar 
>somewhat for recipient implementations.

Several of us have and currently believe that is raising the bar a 
little too high.

>I recall there was some interest on the thread in limiting to a 
>single MUST support, and some interest in that scheme being HTTP(S). 
>I am not sure we reached consensus on this. I don't have a strong 
>opinion, but we certainly need some text to clarify things one way 
>or the other.
>
>Furthermore, it is unclear which code to use in a 494 response when 
>rejecting an unsupported scheme - presumably the top level 400, but 
>that says nothing about why dereference failed. Even if all the 
>named schemes were MUST support (so you would never reject these), 
>there could be other schemes under absoluteURI that you would want to reject.

The conclusion from the San Diego adhoc bof on this ID was to limit 
the number of error types to specific different actionable ones. At 
that adhoc, I had roughly 22 different error types, one set included 
the ability to indicate which URI scheme wasn't supported and which 
ones were. That idea was roundly rejected (most strongly by our 
newest co-author Jon Peterson).  I believe it was Henning (and maybe 
Hannes) that wanted the error codes limited as well, and to allow 
this RFC-to-be to be extended with an XML body in the response that 
included a much more detailed error explanation and ways detailed in 
how to resolve the problem.

No one has written that ID yet, so I don't know where that thought is now.

That said, -04 doesn't have a 494 response articulated because 
location specific rejections are for the 424 (Bad Location 
Information) response. Jon and I talked just last week about what do 
we do when an LR supports one URI scheme and receives another URI 
scheme (i.e., supports SIP:/SIPS:/PRES: URIs but gets an HTTP:/HTTPS: 
URI). We couldn't come up with anything that didn't have a lot of 
holes in it, so we left it for now.

James

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Oct 2010 21:37:37 +0200

> From: James M. Polk [mailto:[email-masked]] 
> Sent: 27 October 2010 20:05
> To: Elwell, John; James M. Polk; [email-masked]
> Subject: RE: [sipcore] Location Conveyance -04 submitted, 
> here's the changes
> 
[JRE] But the event package is [ID-GEO-FILTERS] and is based upon RFC 3856, a SIMPLE document. Not all SIP implementations support SIMPLE. On the other hand, I can see benefits in this (ability to receive notifications when location changes, plus filters). If the consensus is SIP/SIPS/PRES is the only mandatory one, I can live with it.

On re-reading 4.6, I see that, although the text "These schemes MUST be implemented according to this document" is within the paragraph concerning what you SHOULD place in a SIP request, perhaps it is intended to include what MUST be supported on receipt too, so perhaps it is OK as is, or perhaps it should say "A location recipient MUST implement these schemes".

> holes in it, so we left it for now.
[JRE] Sorry, 494 was a typo, I meant 424. What sort of holes would you have if you specified 401, say, as "URI scheme not supported"?
I guess one difficulty is what does the UAC do about it, if it doesn't have the means for obtaining a reference with a different URI. Was that the sort of hole you had in mind?

John

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 14:58:40 -0500

At 02:37 PM 10/27/2010, Elwell, John wrote:
>[JRE] But the event package is [ID-GEO-FILTERS] and is based upon 
>RFC 3856, a SIMPLE document. Not all SIP implementations support SIMPLE.

[jmp] Yes, but realistically - fewer will support HELD-Deref...

>On the other hand, I can see benefits in this (ability to receive 
>notifications when location changes, plus filters).

[jmp] I believe Brian wrote the Filters doc with that in mind (i.e., 
the benefits).

>If the consensus is SIP/SIPS/PRES is the only mandatory one, I can 
>live with it.
>
>On re-reading 4.6, I see that, although the text "These schemes MUST 
>be implemented according to this document" is within the paragraph 
>concerning what you SHOULD place in a SIP request, perhaps it is 
>intended to include what MUST be supported on receipt too, so 
>perhaps it is OK as is, or perhaps it should say "A location 
>recipient MUST implement these schemes".

[jmp] If we end up choosing a mandatory to implement scheme (or 
scheme set), then I think we can state that receivers MUST implement 
that scheme (set).

[jmp] Do you (or others) believe this should be done regardless of 
any mandatory to implement sending scheme, or wait until there is a 
mandatory to implement sending scheme?

>[JRE] Sorry, 494 was a typo, I meant 424. What sort of holes would 
>you have if you specified 401, say, as "URI scheme not 
>supported"?  I guess one difficulty is what does the UAC do about 
>it, if it doesn't have the means for obtaining a reference with a 
>different URI. Was that the sort of hole you had in mind?

[jmp] Jon and I talked specifically about adding a 401 "URI scheme 
not supported", but his point was "what does that really tell you?" 
and I tried to plead that it would mean that this scheme (set) (i.e., 
SIP based or HTTP based) wasn't supported, and to send the other 
scheme (set). His counter was that what happens when there is more 
than one scheme set to choose from, then what does a 401 really mean 
that a 400 doesn't already? I didn't really have a good answer for 
that one. In other words, if we're only ever going to have a choice 
between SIP and HTTP, then the 401 would work. Once you have a 3rd 
(or more) choice, it all falls apart.

The best way around this is to indicate which choice of scheme you 
want in the 424, perhaps this could become (Jon - don't hyperventilate!)

401 "URI scheme not supported - send SIP:URI"
402 "URI scheme not supported - send SIPS:URI"
403 "URI scheme not supported - send PRES:URI"
404 "URI scheme not supported - send HTTP:URI"
405 "URI scheme not supported - send HTTPS:URI"

and just add to the list when someone wants a new URI scheme supported.

James

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Oct 2010 08:23:25 +0200

> Sent: 27 October 2010 20:59
[JRE] What we want to achieve is that there is a certain group of schemes (one or more) that, if sent by the sender, will be supported by any receiver that supports location-conveyance. Assuming the WG settles on SIP/SIPS/PRES as that group of schemes, I think the present words get quite close to what we require. However, as I mention above, the paragraph talks about schemes to send in the request, so there is some ambiguity as to whether the "MUST be supported" includes receipt or not. Hence my proposed word change above.

> (or more) choice, it all falls apart.
[JRE] I would say that there would be a distinction between 401 (I don't know how to deal with that scheme because I don't support it) and 400 (which would include things like error response to the SIP/HTTP request, or dereference yielded a location that I couldn't interpret (unless that is a 100), etc.).

John

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Oct 2010 08:18:48 -0400

> seemed everyone and their brother was agreeable with, so ...

As I recall, the proposal was to just remove the limit on the number  
of locations values, not to bump it up by one.  From the minutes:

"Restore Geolocation header that has multiple URIs, even though we  
would not recommend it. Entities inserting persence are responsbile  
for any resulting errors. The header parameters distinguishing URIs  
would not be added back in."

At least in my mind, multiple != 2.

--Richard

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Oct 2010 15:01:07 +0200

To be more specific - we had a document that allowed multiple locations. It was reduced to one without any decision in that direction being made by the working group. It needs to go back to multiple values.

In my view there are clear use cases where multiple values are required.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of Richard L. Barnes
> Sent: Thursday, October 28, 2010 1:19 PM
> To: James M. Polk
> Cc: [email-masked]
> Subject: Re: [sipcore] Location Conveyance -04 submitted, 
> here's the changes
> 
> > your rough-loc ID. Before that, we were firm in not 
> allowing more than 
> > one.  Given that choice, which do you like?
> >
> >>> allowing one coarse and one highly accurate location in 
> the same SIP
> >>> request).
> >>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 28 Oct 2010 13:16:12 -0400

Reducing this issue to a process argument trivializes (as usual) any technical question about what location means in a SIP request. At the last working group meeting, I very reluctantly conceded to the (somewhat weak in my opinion) backwards-compatibility argument for allowing more than one Geolocation header field value. To be clear, the previous version of the draft never took away the ability to have multiple locations in a request - you could always put in multiple PIDF-LO MIME bodies with different or similar locations in the last version of the draft (and yes, with Content-Indirection or whatever if you wanted it by reference). You could also put multiple locations in the same PIDF-LO body, as both the presence data model and the relevant GEOPRIV RFCs recommend even. The contention that the previous version "reduced to one" the number of locations that a SIP request could carry is simply false.

The real issue is what semantic role we expect the Geolocation header to play when it points to more than one PIDF-LO body. While I think plenty of people have the intuition that this should be meaningful, I haven't heard a lot of people step up to explain what it should mean exactly. If you want to stuff ten locations into multipart MIME bodies of a SIP request, this document does not prevent you from doing so. As I've said before, it's kind of like stuffing ten SDP bodies into a SIP request, which RFC3261 also allows. You may mean something by those ten SDP bodies, but I have no idea what it is, and neither will anyone else who receives your request. The only argument (aside from rough-loc) I've heard for multiple locations is that there may be some application-specific agreement about their meaning. That's fine, but that sort of statement simply has no place in standards, as it is completely anathema to interoperability. If we seriously tried to design SIP in such a way that we relied on application-specific behavior to handle ten SDP bodies in one request with no further guidance to the implementers, we'd never set up a single call.

The high-level argument of the previous version of the draft was that when there were multiple PIDF-LO bodies associated with a SIP request, the job of the Geolocation header would be to designate one of them as the one the recipient was supposed to act on as if it were coupled to the sender of the request. If it indicated a PIDF-LO body with multiple locations within it, presumably the consuming application would be able to tell from the data model markup which location it should consume. I do understand the argument from rough-loc, or the backwards-compatibility argument that some applications today simply bandy these Geolocation values around in an application-specific manner. I didn't, however, walk away from either discussion with the impression that we ever needed the Geolocation header to indicate more than two PIDF-LO bodies for any of the use cases in question.

This draft is so tardy that I can't countenance delaying it over a deadlock on an issue like this, so I won't be stubborn on the text that goes in there. Honestly, though, we're a long way from understanding what coupling multiple locations to a SIP request is supposed to mean.

Jon Peterson
NeuStar, Inc.

On 10/28/10 6:01 AM, "DRAGE, Keith (Keith)" <[email-masked]> wrote:

regards

Keith

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 29 Oct 2010 08:00:10 +0800

> At least in my mind, multiple != 2.

In terms of damage done, allowing more is just a matter of degree.  The "you break it, you bought it" philosophy applies regardless.

--Martin

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Oct 2010 19:32:27 -0500

At 07:00 PM 10/28/2010, Thomson, Martin wrote:
>In terms of damage done, allowing more is just a matter of 
>degree.  The "you break it, you bought it" philosophy applies regardless.

I'll leave the warnings against more than one, but allow "many" in 
the next rev.

Everyone cool with that?

James

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Oct 2010 19:47:41 -0500

At 01:23 AM 10/28/2010, Elwell, John wrote:
>[JRE] What we want to achieve is that there is a certain group of 
>schemes (one or more) that, if sent by the sender, will be supported 
>by any receiver that supports location-conveyance. Assuming the WG 
>settles on SIP/SIPS/PRES as that group of schemes, I think the 
>present words get quite close to what we require. However, as I 
>mention above, the paragraph talks about schemes to send in the 
>request, so there is some ambiguity as to whether the "MUST be 
>supported" includes receipt or not. Hence my proposed word change above.

If others agree, I'm ok with making LRs supporting this spec have to 
support a or a group of schemes. I think this will easily get 
facetime during the preso in SIPCORE to get high BW feedback too.

>[JRE] I would say that there would be a distinction between 401 (I 
>don't know how to deal with that scheme because I don't support it) 
>and 400 (which would include things like error response to the 
>SIP/HTTP request, or dereference yielded a location that I couldn't 
>interpret (unless that is a 100), etc.).

I see the distinction, but to let you know, I'm not the one who 
really needs convincing among the editor team. Jon is fairly open 
about being opposed to have a bunch of error codes, but I personally 
think the list below is what I would do if it were up to me now. I 
think that is concise, has no ambiguity or room for error (pardon the pun).

James

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Oct 2010 20:07:12 -0500

Keith

I know you know this, but I'm going to say it anyway for those that don't.

Having multiple locations is different that having multiple locationValues.

The text has limited all locations to be about a single target (that 
was first introduced in -03).

Within a PIDF-LO, there can be multiple locations (this has always 
been allowed).

Having multiple locationValues, there is most likely going to be 
multiple PIDF-LOs.

The Text in version -03 said 1 PIDF-LO, that can have multiple 
locations describing where the same target is.

I want to make sure whether you are or you are not asking for 
multiple locationValues which likely lead to multiple PIDF-LOs. Is 
that what you really are after?  Most of the previous to version -03 
versions of Location-conveyance allowed multiple locationValues. The 
Jon's preso in Anaheim, which I am well away you were not a fan of, 
suggested that we can remove a LOT of complexity within this doc if 
we took away the ability to have multiple locationValues (and he's 
right on that account).  But this flew in the face of Richard's 
rough-loc ID that called for the ability multiple locationValues, 
with each having a different granularity of the same Target (one 
coarse and one highly accurate). rev -04, the current version, 
allowed zero, one or two locationValues just to satisfy this second 
type of location (i.e., the rough-loc locationValue). Richard agree 
to allow us in -04 state this isn't a good idea, and I don't believe 
he's asking us to change that part today.

I'm trying to tease out (exactly) what you want in -05 (which is 
obviously needed now for the ABNF changes, if nothing else).

James

At 08:01 AM 10/28/2010, DRAGE, Keith (Keith) wrote:
>To be more specific - we had a document that allowed multiple 
>locations. It was reduced to one without any decision in that 
>direction being made by the working group. It needs to go back to 
>multiple values.
>