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

From: Brian Rosen ^lt;>
Date: Fri May 04 2007 - 09:14:12 EDT

The discussion on this item seems to have died down. Could the chair please
call the consensus so we can change the text in the conveyance document?

I believe the consensus on the first issue, which was whether a proxy can
forward a sip message containing location to the next hop if
retransmission-allowed=no, is a yes, it can.

I think several people spoke in favor of requiring a new tag,
"routing-query-allowed" which, when set to "yes" would permit a sip element
to send location to some other entity for the purpose of doing location
based routing if retransmission-allowed=no. Henning strongly denounced this
as being unnecessary because the location did not have any user identity in

If the consensus is to require routing-query-allowed, -conveyance will
normatively update PIDF-LO to add this tag. Although there was some
sentiment to make a more broadly applicable tag with multivaried values, the
authors would prefer to have routing-query-allowed, and there was not, in my
opinion, enough of a consensus on this aspect. It's a chair call, of


-----Original Message-----
From: Ted Hardie []
Sent: Thursday, May 03, 2007 12:23 AM
To: Henning Schulzrinne
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"

At 11:00 PM -0400 5/2/07, Henning Schulzrinne wrote:
>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 '' and
'' retargeting in your definition? Or does this
depend on an organizational change? In your example, 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.

I am apparently not being clear enough here. Let me try again. My view is
if the proxy acts to forward the call without reference to the location,
then it is
not acting as a recipient. That is related to the first point Brian raised
in the
email that started this thread. The proxy is simply acting as one hop in a
hop-by-hop protocol in its normal manner. From the point of view of
privacy, it is just passing things along.

If the proxy does use the location, either by reference to some local cache,
a distant LoST server, or related mechanism, to *pick a destination for the
call*, then I think the proxy is no longer acting as pass-through from the
point of view of location privacy. At that point, all of the location
rules have to be considered. We need to make sure that the vocabulary
of those rules is rich enough to allow users to permit that when they wish
to allow it and to forbid it when they do not. Overloading
eliminates needed semantics, in my opinion.

I believe this is relatively easy to express ("If a proxy uses the location
to route the request, it must have permission to do so, expressed by
retransmission="routing-permitted" or retransmission="yes").

This does not eliminate any potential privacy concerns that may exist
when SIP's normal behavior would cause the location to go to someone
surprising to the end user. I agree with your points that this would
require more, probably the initiating user encrypting the location
so that only the original recipient can read it. If the original recipient
sold the key with the business, then even that bet is off.

>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
>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
>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.

I am more than willing to do the work to make specify this correctly. I
we are actually disagreeing on the goals. I believe that this level of user
is both needed and consistent with GEOPRIV's charter. Your responses seem
indicate that you do not. Your opinion appears instead to be that it is not
needed because proxy can use a mechanism to route that does not require it
reveal the identity on whose behalf it made the query. I don't think that
the need, for many of the same reasons Richard has already put forward. If
I have misunderstood you and we do agree on the goals, then I have
how you can achieve them while overloading retransmission=no. If that is
case, please restate that for me.

>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
>>>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
>>or otherwise retargeted. I make a call to local@carservice.example.
>>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 mailing list

Geopriv mailing list
Received on Fri, 4 May 2007 09:14:12 -0400

This archive was generated by hypermail 2.1.8 : Fri May 04 2007 - 09:14:34 EDT