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

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Wed May 09 2007 - 08:48:13 EDT

On May 9, 2007, at 12:40 AM, Ted Hardie wrote:

> At 9:27 PM -0400 5/8/07, Henning Schulzrinne wrote:
>> This does not address my question at all. First, I'm not sure what
>> you define as "service provider". If 'service provider' is the
>> pizza deliverer as opposed to the call center, this is not too
>> helpful, since almost all location-based calls will require the
>> release of in
>> formation to them to be useful.
>
> Stop. Read the following sentence carefully:
>
> As currently described, not all calls which will contain the
> Geolocation header
> will route based on it.
>
> Do you agree with this?

That's certainly correct, but in those cases, a header or declaration
of any sort is unnecessary.

The issue you keep missing is that of choice. I believe and have
tried to demonstrate that there are two cases of practical interest:

(1) The URI is a normal SIP destination, which performs no routing.
No flag of any sort is needed since no proxy is trying to use any
location information for anything.

(2) The URI is either a service URN or another URI that needs further
routing. In that case, any flag is useless since the call will fail
without it. Thus, the flag or indication offers no additional
privacy, unless you consider call failure privacy.

Let me turn the question around, maybe to clarify your intent:

Do you want an indication that says, basically, "If you want to do
location-based call routing, please fail the call instead"?

The reason that do-not-distribute is somewhat useful is that the
assumption was that 'normal' services are possible without it, and
only 'extra' (but privacy-infringing) services are prevented by
having it be set to 'no'. This is in line with standard privacy
policy practices.

> Ted

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 9 May 2007 08:48:13 -0400

This archive was generated by hypermail 2.1.8 : Wed May 09 2007 - 08:48:42 EDT