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

From: Tom-PT Taylor ^lt;taylor@nortel.com>
Date: Tue May 08 2007 - 17:22:05 EDT

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.

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
Received on Tue, 08 May 2007 17:22:05 -0400

This archive was generated by hypermail 2.1.8 : Tue May 08 2007 - 17:23:20 EDT