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

From: Dawson, Martin ^lt;>
Date: Wed May 02 2007 - 10:33:52 EDT

I'd like to understand the issue a bit more from your perspective though Richard. The identity of the user has not been provided to the LoST server (Henning's point). Indeed, to the LoST server it's just a request to provide the routing information associated with an arbitrary and anonymous location. Do you think that 4119 is trying to say that the location information should not be used or is it actually saying that the location of the user should not be forwarded on to other parties (and I'd expect the intention of "parties" was someone other than the trust domain but who knows what the author was actually thinking)? That is, is a PIDF-LO significant if it is in isolation from the rest of the PIDF information? (I'm assuming it's stripped of anything unique to the user) Cheers, Martin -----Original Message----- From: Richard Barnes [] Sent: Thursday, 3 May 2007 12:24 AM To: Henning Schulzrinne Cc: GEOPRIV Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed" 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 which > is then delivered to, 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 mailing list ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

Geopriv mailing list
Received on Wed, 2 May 2007 09:33:52 -0500

This archive was generated by hypermail 2.1.8 : Wed May 02 2007 - 10:33:58 EDT