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

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Tue May 01 2007 - 21:13:41 EDT

Your example doesn't work. There are two cases:

(1) You use a service URN for "car service". The first proxy needs to
do a LoST lookup, or the call will fail. Saying 'no' simply ensures
that the call fails. Thus, there's no additional privacy.

(2) You dial a specific car service, say (in NYC) CARMEL. You are
willing to disclose your location to that particular service, for
dispatch. But for some reason, you're not willing to disclose it to
route the call? (In your example, your evil mega-corporation will
have obtained the location by the time they answer with "New
EvilCorp, formerly friendly neighborhood car service". They'll
probably default route to their national call center in Bangalore...)

I have to admit that I find this highly contrived and can't imagine
that anybody would constructively use such a feature.

The costs, in terms of error handling and failure modes, seem like a
bad trade-off for a feel-good, do-nothing flag.

If you truly want to prevent location-based routing, why not just
skip the Geolocation header and simply include a (location) body? Or
simply encrypt the information so that only the intended recipient
can read it? That offers real security, as opposed to make-believe
security.

Henning

On May 1, 2007, at 8:19 PM, Ted Hardie wrote:

> At 7:42 PM -0400 5/1/07, Henning Schulzrinne wrote:
>> Your example seems to assume that the flag adds privacy by being
>> set. Unfortunately, that's not the case.
>>
>
> <snipped emergency example>
> I continue to think using the emergency case as the driving example is
> warping this discussion. I've reproduced a different example to
> reinforce
> this point below.

Richard made up the example, not I.

>
>> The same is true for the pizza call, so this does not depend on
>> the specific example.
>>
>> Henning
>
> Let's go with the pizza example, or, even better, a car service
> example. I occasionally
> call a car service to go to the airport, rather than driving and
> leaving my car there
> or getting a ride. There are several local car services that are
> truly local to me,
> and a few that have local numbers but are regional or national
> operators. As a
> consumer I prefer to deal with the truly local operators, since I
> want to
> keep my dollars in my area and believe that they are more reliable
> than operators
> that may have to negotiate traffic just to get to me. I also
> occasionally find that
> one of my "local" car services has been sold, so that calling them
> transfers me
> to one of the big operators.
>
> I don't want that, and I hang up when I realize it.
>
> The parallel in the LoST-using case is any situation where the end
> user would
> be willing to share location with the intended recipient, but is
> not willing for
> it to be used to route the call to the service provider the proxy/
> LoST combination
> finds.
>
> You may not find that a particularly compelling use case. But the
> simple fact
> is that this semantic, "willing to distribute to the recipient, but
> not wiling for
> this to be used in routing", is achievable with one of the two
> syntax proposals
> and it is not achievable with the other. Since the second proposal
> (relaxing
> what "no" means) runs contrary to the basic principles of the
> work: user
> control and a default no, I believe there is no strong reason to
> accept it
> and that loss. It violates the principle of least surprise (no
> means no to most
> folks). There is an obvious way to make sure that the semantics
> retain
> their original force and are appropriately extended. Let's adopt
> that obvious
> way, and move on.
> 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, 1 May 2007 21:13:41 -0400

This archive was generated by hypermail 2.1.8 : Tue May 01 2007 - 21:14:12 EDT