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

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Wed May 02 2007 - 23:00:01 EDT

As Tom pointed out, re-targeting is a whole different can of worms
and largely independent of the LoST issue. This is probably something
worth thinking about and is a bit more complicated than you hint at.
This is something that the draft should cover, as it is SIP-specific
and really not addressed in general GEOPRIV documents, as far as I
can tell.

(Most) any SIP proxy, other than outbound, will do retargeting -
otherwise, it shouldn't be there...

Let's assume that retargeting would not be allowed if the PIDF-LO
prohibits retransmission. This sounds fairly simple, but is tricky in
practice.

Is the translation between 'hardie@qualcomm.com' and
'12345@phones.qualcomm.com' retargeting in your definition? Or does
this depend on an organizational change? In your example,
carservice.com is now part of the giantco, so it is not a different
organization. Otherwise, any time that an organization has new
management, you'd have to fail calls.

In this case, I actually sympathize with your desire to prohibit
redistribution by call routing (although this has nothing to do with
whether the call routing is based on location or, say, just the From
or To header), as I expected to send my LO, with identity, to X and
it's going to Y. The hard part will be defining when X is not
equivalent to Y. An expansive definition will mean that no call that
has retransmission=no will succeed and thus, people will pretty
quickly have to give up on that flag if they want location-bearing
calls to go anywhere.

There are some clear cases that I think we can easily consider
retransmission: If company X sends a call to some totally
unaffiliated company Y, this is clearly retransmission. It gets
trickier for private individuals. What if I forward my son's location-
bearing calls to the dinner party I'm at? How is my phone supposed to
know whether that's an ok thing or not?

Usually, privacy policies list all the affiliates and subsidiaries
that a company considers to be part of the same organization, so this
is not a new problem.

It is obviously easier if I just agree with your opinion. I've tried
to make technical arguments why the approach doesn't work and is
likely to lead to either a false sense of privacy or call failures,
or likely both, with lots of additional complexity. As far as I can
tell, you have not been able to provide a single example that
actually works once one goes through the details. Protocol behavior
that is under-specified, but is lawyer-bait, just doesn't seem like a
good idea to me.

Henning

On May 2, 2007, at 12:44 PM, Ted Hardie wrote:

> At 9:04 AM -0400 5/2/07, Henning Schulzrinne wrote:
>> Another thought on this topic, which seems to have gotten lost. In
>> the end, this is all about trust. We sometimes have the notion
>> that SIP proxies are kind of like routers, operated by random
>> entities that we don't control. However, that's a clear
>> misunderstanding of how SIP request routing works. Those familiar
>> with SIP will have seen the SIP trapezoid picture, consisting of a
>> proxy in the outbound domain (typically, my VSP) and in the
>> destination domain.
>>
>> For the topic at hand, as I noted, there are two cases:
>>
>> (1) The destination URL is a service URN. If not resolved by the
>> UA, it needs to be resolved by the very first (outbound) proxy.
>> Thus, this proxy needs to do a location-based lookup. There simply
>> is no choice other than failing the call, assuming that there is
>> no worldwide catch-all call center for that service. Thus, any
>> privacy indication in this case is simply a waste of time, since
>> you might as well have a "fail this call, please" flag.
>
> Henning, I think you're missing the possibility that the call may
> get transferred
> or otherwise retargeted. I make a call to
> local@carservice.example. They've
> been bought, and my call is now forwarded to dispatch@giantco.example,
> which wants to do location based routing. The user might be fine with
> it going to the original recipient and even fine with the
> forwarding, but
> not okay with the location based routing that occurs as a result.
>
> I am sorry if you feel this is not a compelling example, but I
> don't think
> you can guarantee that this semantic (the "real no") is never needed.
> I think Richard's notion of something beyond a binary "routing
> permitted"
> flag is probably a good one, since it gives extensibility, but I'm
> fine
> with "routing permitted" if we want to do one thing and stop.
>
> I'm not fine with us breaking one of the core semantics of GEOPRIV,
> and your attempts to mock that position simply won't convince me.
> We can go around and around, but that's probably not productive.
> There is an easy way past this. Let's take it and move on.
>
> regards,
> Ted
> 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 Wed, 2 May 2007 23:00:01 -0400

This archive was generated by hypermail 2.1.8 : Wed May 02 2007 - 23:02:49 EDT