Re: [Geopriv] Location in SIP and "retransmission-allowed"

From: Ted Hardie ^lt;hardie@qualcomm.com>
Date: Tue May 08 2007 - 17:28:52 EDT

At 5:22 PM -0400 5/8/07, Tom-PT Taylor wrote:
>I'm actually a little concerned about the implications for a PSAP. Typically a PSAP may hand off an emergency to a specific service: fire, police, or whatever. The PSAP has to hand off the location too, or how will dispatch happen? This is definitely at the application level.

Tom,
        We've agreed long since that emergency services are a special
case. That's why I put "SHOULD NOT" in the replacement text below. What
a PSAP should do doesn't belong in the SIP location conveyance document
at this point (they've punted that whole discussion to ECRIT).
        Have you any comments that don't relate to that special case?

                                Ted

>Ted Hardie wrote:
>>At 4:08 PM -0400 5/8/07, Henning Schulzrinne wrote:
>>>>That's not the current proposal, which uses the same header for two different use
>>>>cases. Since those use cases involve different intended recipients (the end recipient
>>>>and the SIP proxy which might do location-based routing), there is some ambiguity.
>>>>Using an explicit parameter for routing location gets us to the state where the
>>>>permissions can be disambiguated without having to have two headers.
>>>>Having two headers would do that too, but it's yet more stuff to carry around.
>>>>
>>>As I've tried to point out, the distinction is wholly artificial from a privacy perspective and, in almost all cases of practical interest, the end user will have to grant routing permission, or, conversely, should encrypt it from prying eyes.
>>
>>And here's the crux of the disagreement; you believe that this distinction
>>doesn't matter, but I believe (and I think at least Richard believes) that it does.
>>I also think that it makes a predication about future use cases that is not
>>justified or justifiable.
>>
>>>That said, I think a use-this-for-routing tag might actually be useful for a slightly different reason, based on the multiple-location case you mention. The reason it needs to be a header is simple, namely location by reference. You really don't want the proxy to attempt to resolve a reference and then find that the answer is "sorry, not for you". That just adds delay and complexity.
>>>
>>
>>If splitting the current header into two headers can get us to group consensus, I'm
>>all for it. As I said in my previous message, there are cases where you might give
>>different locations to the routing infrastructure and the end user so there are additional
>>justifications here.
>>To be clear this would eliminate "routing-query-allowed", add a header and update
>>at least this language:
>>
>> A proxy MAY read the Geolocation header, and the associated body, if
>> not S/MIME protected, in transit if present, and MAY use the
>> contents of the header to make location-based routing decisions.
>>to something like:
>>
>> A proxy MAY read the Routing-location header and the associated body and
>> MAY use the contents of the header to make location-based routing decisions. A proxy SHOULD NOT read the Recipient-location header and its associated body
>> for the purpose of making location-based routing decisions.
>>
>>We would also need to add advice for proxies adding location (for which header
>>to add it to).
>>
>>It's a non-trivial change, but that path forward works, at least in my opinion.
>>
>>How do other folks feel about making a change like this?
>>
>> Ted
>>
>>
>>_______________________________________________
>>Geopriv mailing list
>>Geopriv@ietf.org
>>https://www1.ietf.org/mailman/listinfo/geopriv
>>
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 8 May 2007 14:28:52 -0700

This archive was generated by hypermail 2.1.8 : Tue May 08 2007 - 17:30:12 EDT