Subject: [Sip] SIP Location Conveyance -04 submitted

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 Sep 2006 14:12:07 -0500

SIP WG

We've just submitted the -04 version of SIP Location Conveyance, with some 
minor and some major changes to the text and structure of the doc. It can 
be found here:

http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-04.txt

Here is a highlevel list of the changes that have been made from the SIP WG 
version -03 to this version -04:

    - removed the inappropriate 2119 language from the Requirements section 
(which is now an appendix in the back, but will stay in the final version 
as a point of history of the doc)

    - removed the old Section 2., which was a "Location in a header vs. in 
a body" artifact from the original versions of the document. That subject 
is no longer current.

    - Added a new Geopriv (or Privacy) Considerations section, and 
interwove critical to know Geopriv points into the Intro

    - Changed the ABNF to reflect discussion on how restrictive the 
location-by-reference schemes should be, with an added "Editor's Note" 
discussing the issues being faced on this point.

    - Changed the "Location" header and option-tag to "Geolocation" header 
and option-tag, due to it being pointed out that there is a conflicting 
HTTP header called "Location".

    - Added a new element to PIDF-LO 'routing-query-allowed', which will 
"update" RFC 4119

    - Stipulated the Reason Header can be used in the 424 Response Message. 
This is allowed in 3326, but not normally how Reason is used.

    - added SUBSCRIBE and NOTIFY as Methods for location conveyance when 
used to dereference a sip:, sips: or pres: location-by-reference URI

    - Added OPTIONS Method for a UAC to request the location of a UAS with 
a Require header geolocation option-tag.

Comments are appreciated

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 2 Sep 2006 02:49:53 +0200

James,

> a Require header geolocation option-tag.

I hope you meant something like "...to check whether the UAS supports the 
geolocation extension"?
If not, the above sounds like a very bad idea.

Regards,

Jeroen

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 1 Sep 2006 21:02:52 -0400

Since you mention it: I think the Supported header is not a great  
idea. It is unnecessary since a receiver can simply ignore the  
Geolocation header. The Require usage is unorthodox, to say the least.

To cite RFC 3261, Section 8.1.1.9:

If the UAC supports extensions to SIP that can be applied by the
    server to the response, the UAC SHOULD include a Supported header
    field in the request listing the option tags (Section 19.2) for  
those
    extensions.

However, the Geolocation header is in the *request*, not the  
response, so it is inappropriate.

Similarly, the Require header (Section 20.32 and elsewhere) is also  
inappropriately used:

  The Require header field is used by UACs to tell UASs about options
    that the UAC expects the UAS to support in order to process the
    request.  Although an optional header field, the Require MUST NOT be
    ignored if it is present.

Thus, the usage is not correct as written.

The simple solution is to add a "Location Required" 4xx response  
code. However, I find it hard to believe that you'd really want this.  
If an emergency call doesn't contain location information, are you  
going to refuse the call and let the person die (instead of routing  
to a default call center)? You might as well rename the response/ 
require option "Lawyer required".

Henning

On Sep 1, 2006, at 8:49 PM, Jeroen van Bemmel wrote:

> James,
>
>>    - Added OPTIONS Method for a UAC to request the location of a  
>> UAS with a Require header geolocation option-tag.
>
> I hope you meant something like "...to check whether the UAS  
> supports the geolocation extension"?

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 2 Sep 2006 11:41:21 +0200

Henning,

> The simple solution is to add a "Location Required" 4xx response  code. 
> However, I find it hard to believe that you'd really want this.  If an 
> emergency call doesn't contain location information, are you  going to 
> refuse the call and let the person die (instead of routing  to a default 
> call center)? You might as well rename the response/ require option 
> "Lawyer required".
>
> Henning

For the emergency case, I agree that a server requiring location to process 
the request would not be desirable. However, for other applications such as 
location based routing in general, I think this could be a valid use case.

Another thing: we might want the following addition (in section 5.2): if the 
UAS supports this extension, it SHOULD add a Supported: geolocation to its 
response. This will enable the UAC to verify that the UAS understood / 
processed its location. If it is missing, particularly in an emergency 
scenario, the UAC could warn the user that location conveyance might have 
failed.

Regards,

Jeroen

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 02 Sep 2006 05:03:52 -0500

>response, so it is inappropriate.

Fair point, but in times that the UAC understands this extension, but does 
not have its location, it needs to be able to tell a location-routing proxy 
not to bother erroring the request with a 424, and just continue with 
processing the original request, either to a default destination or to 
search for the UAC's location itself (somehow, and I have ideas if wifi is 
used, or if there is any probing capability this document shouldn't mention)

>Similarly, the Require header (Section 20.32 and elsewhere) is also

It was originally only in an INVITE message (requiring the UAS's location 
in the response).  I figured out quickly that if that use-case were 
permissable, then its use in OPTIONS was equally valid, which I know isn't 
popular.

I have to admit, this was a chancy inclusion for requesting the UAS's 
location.  It can easily be removed unless someone really wants it.  The 
text is pretty standalone, so nothing else is affected by its removal.

>to a default call center)? You might as well rename the response/ require 
>option "Lawyer required".
>
>Henning
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 2 Sep 2006 10:50:36 -0400

> Fair point, but in times that the UAC understands this extension,  
> but does not have its location, it needs to be able to tell a  
> location-routing proxy not to bother erroring the request with a  
> 424, and just continue with processing the original request, either  
> to a default destination or to search for the UAC's location itself  
> (somehow, and I have ideas if wifi is used, or if there is any  
> probing capability this document shouldn't mention)
>

This may be more a matter of lack of clarity in the description.

Let's take the non-emergency case of ordering pizza and see what  
needs to happen:

(1) hungry customer places call to pizza.example.com, but the SIP  
client doesn't know that this destination would like to do location- 
based routing and obviously doesn't want to include location with  
every call;

(2) the destination needs to be able to tell the UAC that it should  
include location, if possible, but directly process the request if not

Thus, the Supported option tag would *only* appear in requests and  
only if the Geolocation header is not present.

I think Sections 3.5 and 5.1 are very unclear and confusing on that  
score.

The draft should say that such inclusion can't be automatic for non- 
emergency calls. (It could be pre-configured; for example, I could  
configure my address book to always include location information when  
calling AAA.)

> It was originally only in an INVITE message (requiring the UAS's  
> location in the response).  I figured out quickly that if that use- 
> case were permissable, then its use in OPTIONS was equally valid,  
> which I know isn't popular.
>
> I have to admit, this was a chancy inclusion for requesting the  
> UAS's location.  It can easily be removed unless someone really  
> wants it.  The text is pretty standalone, so nothing else is  
> affected by its removal.

Unless you're proposing to update RFC 3261, removal is not exactly a  
matter of choice.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 2 Sep 2006 10:53:24 -0400

>
> Another thing: we might want the following addition (in section  
> 5.2): if the UAS supports this extension, it SHOULD add a  
> Supported: geolocation to its response. This will enable the UAC to  
> verify that the UAS understood / processed its location. If it is  
> missing, particularly in an emergency scenario, the UAC could warn  
> the user that location conveyance might have failed.
>

My suggestion would be to keep the number of cases low and keep this  
simple. SIP is already more than complex enough, and this seems to be  
another example of would-be-nice complexity. In this particular case,  
I'd argue that this really doesn't add much value. What does it mean  
for a UAS to "understand" the header - parse it? log it? show it to  
the recipient?

Plus, for location-based routing, I care that the proxy does  
something with it, not the UAS.