Subject: [sipcore] Location Conveyance Question: Multiple Location

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 19 Jul 2010 10:14:58 +0200

Hi, 

The document states that attaching multiple Geolocation headers is not allowed. How would I attach a location by reference and a location by value in the same SIP message? I believe this is a quite common use case given that the LbyR will be used by the PSAP to obtain fine grain location information and the ESRP will use rough location for routing purposes. A discussion about this use case would be useful in the document, if you believe it should be dealt with in two independent SIP exchanges.  

Did I misunderstood the text in the draft?

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 13:57:06 -0500

At 03:14 AM 7/19/2010, Hannes Tschofenig wrote:
>Hi,
>
>The document states that attaching multiple Geolocation headers is 
>not allowed. How would I attach a location by reference and a 
>location by value in the same SIP message? I believe this is a quite 
>common use case given that the LbyR will be used by the PSAP

PSAP? that's a corner case that is talked about in the draft -03.

>to obtain fine grain location information and the ESRP will use 
>rough location for routing purposes. A discussion about this use 
>case would be useful in the document,

again - that's a corner case, as are many others that are not mentioned.

>if you believe it should be dealt with in two independent SIP exchanges.
>

yes - the purpose of -03 was to reduce the complexity of the whole 
proposal, and your suggestion would increase the complexity back to 
where it was, which everyone else seems to be opposed to.

SIP is an end-to-end protocol - which anyone who knows SIP knows 
this. If there are multiple inserters of location, these inserters 
need to be identified if an LR determines any one of the locations is 
insufficient (in some way) and said LR needs to reject the message 
(or just reject the location).  Given multiple locations in a single 
SIP request, each inserter needs to be able to identify which 
location they inserted (because the actual location and/or location 
URI are not in the SIP response) to know that they inserted 'bad' 
location - in the hopes that they would correct the location 
information. If this is a rejection by the LR, then the Target needs 
to send new - better - location in the subsequent SIP request. It can 
only do that if it knows what to correct, meaning it has to have been 
able to be told what was wrong with its location in the first place, 
*and* to explicitly ignore location errors NOT meant for that SIP entity.

This lead to the complexity of previous versions of the ID and what 
many opposed.

You seem to want to go back to that complexity for your one use-case; 
many do not.

James

>Ciao
>Hannes
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 19 Jul 2010 15:12:57 -0400

I might be mistaken, but it looks to me as if the header ABNF would  
allow the following:

Geolocation: <cid:[email-masked]>,<http://lis.example.net/ 
foobar>

So what's the problem? Is there language that says proxies can't  
modify a Geolocation header (or delete/add)?

--Richard

On Jul 19, 2010, at 2:57 PM, James M. Polk wrote:

>> location by value in the same SIP message? I believe this is a  
>> quite common use case given that the LbyR will be used by the PSAP
>
> need to be identified if an LR determines any one of the locations  
> is insufficient (in some way) and said LR needs to reject the  
> message (or just reject the location).  Given multiple locations in  
> a single SIP request, each inserter needs to be able to identify  
> which location they inserted (because the actual location and/or  
> location URI are not in the SIP response) to know that they inserted  
> 'bad' location - in the hopes that they would correct the location  
> to send new - better - location in the subsequent SIP request. It  
> can only do that if it knows what to correct, meaning it has to have  
> been able to be told what was wrong with its location in the first  
> place, *and* to explicitly ignore location errors NOT meant for that  
> SIP entity.
>
> You seem to want to go back to that complexity for your one use- 
> case; many do not.
>
> James
>
>
>> Ciao
>> Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 14:43:17 -0500

At 02:12 PM 7/19/2010, Richard L. Barnes wrote:
>Geolocation: <cid:[email-masked]>,<http://lis.example.net/ foobar>
>
>So what's the problem?

are you asking me or Hannes?

>Is there language that says proxies can't modify a Geolocation 
>header (or delete/add)?

Table 1 indicates proxies cannot delete this header, but the text 
doesn't clarify that point.

The text explicitly says proxies can add one locationValue, but does 
limit it to a maximum of one locationValue in the Geolocation header. 
See Jon's recent note for the argument why this is.

This ID specifies no limit on the number of message bodies in a SIP 
message, and a location URI can be added by a SIP intermediary along 
the signaling path.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jul 2010 18:34:16 -0400

>> Geolocation: <cid:[email-masked]>,<http://lis.example.net/ 

The ABNF permits that (by virtue of allowing absoluteURI, http: is 
permitted), but the text does not:

    The Geolocation header field has zero or one locationValue, but
    MUST NOT contain more than one locationValue.

>> Is there language that says proxies can't modify a Geolocation header 
>> (or delete/add)?
> 

Text I quoted above limits it.

	Thanks,
	Paul

> message, and a location URI can be added by a SIP intermediary along the 
> signaling path.
> 
> James
> 
> 
>> --Richard
>>
>>
>>
>>
>>
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 20 Jul 2010 07:19:01 +0800

By the same token absoluteURI also permits pres:, sip: and sips: URI schemes, yet these are explicitly called out, presumably because there is specification work that says how to use them for acquiring location information. Hannes's comment, and indeed my comment made nearly a week ago, are simply calling for the inclusion of the http: and http2: URI schemes to also be included because similar specification work on how to use these schemes to acquire location information exists.

If the argument is that this is covered by the absoluteURI component, then presumably that is all the ABNF requires, and the sips: sips: and pres: URI schemes can also be removed.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Tuesday, 20 July 2010 8:34 AM
> To: James M. Polk
> Cc: Richard L. Barnes; Hannes Tschofenig; [email-masked]
> Subject: Re: [sipcore] Location Conveyance Question: Multiple Location
> 
> 
> 
> James M. Polk wrote:
sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jul 2010 20:06:48 -0400

Fair enough. I guess that must be what the following words from the 
draft are about:

    Other URI schemas used in the location URI MUST be reviewed against
    the RFC 3693 [RFC3693] criteria for a Using Protocol.

I guess I don't understand the details of that MUST. Who/what must do that?

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 20:26:49 -0500

James

I logged your comment from a week ago on this, and Jon also agreed to it.

-04 will have this explicitly allowed.

James

At 06:19 PM 7/19/2010, Winterbottom, James wrote:
>By the same token absoluteURI also permits pres:, sip: and sips: URI 
>schemes, yet these are explicitly called out, presumably because 
>there is specification work that says how to use them for acquiring 
>location information. Hannes's comment, and indeed my comment made 
>nearly a week ago, are simply calling for the inclusion of the http: 
>and http2: URI schemes to also be included because similar 
>specification work on how to use these schemes to acquire location 
>information exists.
>
>If the argument is that this is covered by the absoluteURI 
>component, then presumably that is all the ABNF requires, and the 
>sips: sips: and pres: URI schemes can also be removed.
>
>Cheers
>James
>
>
>
>
> > >> Geolocation: 
> <cid:[email-masked]>,<http://lis.example.net/> >> foobar>
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 20 Jul 2010 10:17:57 +0800

Thanks James

James Winterbottom
Global Product Manager
Andrew GeoLENs
IP Location Product Portfolio
Email: [email-masked]
Phone: +61-2-42-212938
Mobile: +61-447-773-560

> Of James M. Polk
> Sent: Tuesday, 20 July 2010 11:27 AM
> To: Winterbottom, James; Paul Kyzivat; James M. Polk

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 20:26:49 -0500

James

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 20 Jul 2010 10:17:57 +0800

Thanks James

James Winterbottom
Global Product Manager
Andrew GeoLENs

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 20:26:49 -0500

James

James