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

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Wed May 02 2007 - 10:23:55 EDT

Perhaps it would help if we were more concrete.

Quoth RFC 4119:
"When the value of this [the retransmission-allowed] element is 'no',
the Recipient of this Location Object is not permitted to share the
enclosed Location Information, or the object as a whole, with other
parties."

The critical part of this criterion for this discussion seems to be the
definition of "parties": Is a party a process, a box, a LAN, a trust
domain, a legal entity? These distinctions are what I suppose you're
referring to as "angels-on-a-pin" distinctions. But I also think that
they're largely irrelevant to this discussion, because allowing a
general LoST query will hand location to another "party" by any
reasonable definition.

First, let me say that there are situations in which
retransmission-allowed=no WOULD allow for location-based services. For
instance, if a telco were considered a party (as it is a legal Party to
a EULA), the location could be passed around within the telco for
whatever purposes.

However, focusing for the moment on the emergency case: When a proxy
does a LoST lookup, the query progresses through the LoST infrastructure
as described in the mapping architecture. In the base case, this means
that the "enclosed Location Information" is transmitted all the way to
the authoritative LoST server. Which means that in order to interpret
retransmission-allowed=no as allowing LoST queries, you'd have to
consider every authoritative LoST server as part of the same "party".
This hardly seems like a reasonable definition of "party".

So it seems clear that retransmission-allowed=no, with the semantic
given in RFC 4119, disallows LoST queries in general. With that in
mind, what is your proposed modification?

--Richard

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.
>
> (2) The second case is that of a second-level resolution, i.e., after
> the service URN has been resolved to a specific SIP URL. This could be
> the emergency service network or PizzaHut's internal network. In other
> words, this occurs if I place a call so sip:deliver@pizzahut.com which
> is then delivered to sip:brooklyn@nyc.pizzahut.com, say.
>
> In this second case, however, the trust domain for the UA and the proxy
> is exactly the same organization. In other words, as a caller, I have
> decided to hand my location information to PizzaHut so that they can
> deliver their service to me. The proxy is owned by PizzaHut. Thus, it
> seems rather strange that I would give PizzaHut my location information
> for pizza delivery, but not to route the call. This gets even stranger
> if it were ok that PizzaHut were to operate a back-to-back UA, extract
> the information, and then, as a UA, re-issue the call. On top of that,
> in this particular case, the LoST server hierarchy is likely to be
> operated by PizzaHut, too.
>
> I think we need to rely on organizational boundaries, rather than
> whether there's an Ethernet cable between the proxy and the location
> lookup service or other angels-on-a-pin distinctions. As far as I know,
> all privacy restrictions in the real world operate like that. In other
> words, the typical privacy rule that (a good) company X has is something
> like "we'll use the information you provide us with as necessary to
> provide the service you contracted for, but we won't hand the
> information to third parties, unless compelled to do so by law, or to
> our marketing department unless you opt in".
>
> Henning
>
> _______________________________________________
> 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, 02 May 2007 10:23:55 -0400

This archive was generated by hypermail 2.1.8 : Wed May 02 2007 - 10:24:06 EDT