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

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Tue May 01 2007 - 21:42:18 EDT

> If you truly want to prevent location-based routing, why not just skip
> the Geolocation header and simply include a (location) body?

This is probably the simplest solution to achieve the desired effect.
As Martin pointed out, there is a distinction between SIP information
(the header) and application-layer information (the body).

However, it's really beside the point, since you still have to deal with
the case when a Geolocation value arrives with retransmission-allowed
set to "no".

--RB

> 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, 01 May 2007 21:42:18 -0400

This archive was generated by hypermail 2.1.8 : Tue May 01 2007 - 21:42:27 EDT