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

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Tue May 08 2007 - 16:08:23 EDT

On May 7, 2007, at 3:04 PM, Ted Hardie wrote:

> At 7:45 PM -0400 5/6/07, Henning Schulzrinne wrote:
>>> I'm sorry, nothing in the archive jumps out at me as a concrete
>>> proposal. Could I request a retransmission?
>>>
>>
>> Let me try to be more specific, collecting thoughts across
>> multiple postings:
>>
>> The goals are two-fold:
>>
>> - achieve logical consistency that doesn't make artificial
>> distinctions
>>
>> - create predictable behavior that users can understand
>>
>> We have agreed that no-forward does not affect the proxying of
>> location information by SIP proxies. There is no logical
>> distinction between routing SIP messages and copying a subset of
>> the information to some other protocol, from a privacy
>> perspective. Bits are bits, whether they are in XML or SIP bodies.
>> Thus, even if we ignore the privacy difference between identity-
>> less location and LOs, there are two possible logically consistent
>> rules:
>
> This isn't how all of us see this, Henning.
>

Which part of the above are you disagreeing with?

> Imagine for a moment that we had created two headers: Routing-
> location: and Recipient-location: . We might have done that in
> order to allow the routing location
> to be at a different level of precision than the location sent to a
> recipient, or to
> disambiguate the two cases in the current location conveyance document
> (intended for the end user and location-based-routing). If we
> had, the presence
> of a Routing-location: header certainly would be sufficient
> indication that the
> message sender was willing to have the message routed using location.
> It would be stating, in essence, that the SIP proxy engaged in the
> location-based
> routing was the intended recipient. The absence of that header
> might also be
> sufficient to say that the proxy should not do so, as delving into a
> "recipient-location:" header for data when there would be another
> place for
> routing location to go would be more clearly reading a location object
> intended for a different recipient.

I'll refer you back to my 'recipient' discussion. I think we need to
be more precise when we are talking about recipients, as they are at
least two types, logical and physical, or, if you like to divide it
further L3, L7 and L8. L8 is the organizational layer.

For privacy, we seem to have agreed that L3 is not "forwarding",
although it clearly is not distinguishable purely from a bits-on-the-
wire perspective. (In all cases, location goes in one interface and
pops out another [logical] interface.)

L7 is less clear. In IMS, is proxying between my access/roaming
provider and the destination provider (neither of whom I'm addressing
directly) retransmission?

I suspect we also agree that a L8 transition has possible privacy
implications.

>
> That's not the current proposal, which uses the same header for two
> different use
> cases. Since those use cases involve different intended recipients
> (the end recipient
> and the SIP proxy which might do location-based routing), there is
> some ambiguity.
> Using an explicit parameter for routing location gets us to the
> state where the
> permissions can be disambiguated without having to have two headers.
> Having two headers would do that too, but it's yet more stuff to
> carry around.
>

As I've tried to point out, the distinction is wholly artificial from
a privacy perspective and, in almost all cases of practical interest,
the end user will have to grant routing permission, or, conversely,
should encrypt it from prying eyes.

That said, I think a use-this-for-routing tag might actually be
useful for a slightly different reason, based on the multiple-
location case you mention. The reason it needs to be a header is
simple, namely location by reference. You really don't want the proxy
to attempt to resolve a reference and then find that the answer is
"sorry, not for you". That just adds delay and complexity.

> As you know by now, some of us do believe that there is an
> important distinction
> between using standard SIP mechanisms to carry the location to an
> end-user
> (case one, for which retransmission=no seems to work for everyone,
> since the SIP proxy is just acting to forward the message) and
> examining the
> header and managing the routing based on it (case two, for which
> some of us
> have argued an explicit retransmission="routing-permitted" would be
> valuable).
> Allowing "retransmission=no" to allow location-based routing via
> whatever
> means eliminates the user's ability to distinguish between those
> and weakens,
> at least in my opinion, the user's control over location.

Except for the multiple-location case mentioned, I have yet to see
where this matters in any practical case. As I've said numerous
times, having a flag where the choices are "no = failure" or "yes =
no additional privacy" just doesn't seem particularly valuable.

>
> Ted
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 8 May 2007 16:08:23 -0400

This archive was generated by hypermail 2.1.8 : Tue May 08 2007 - 16:06:54 EDT