Re: RE: [Geopriv] Consensus on changes to location-conveyance
Henning Schulzrinne <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Message-ID | <[email protected]> |
> Proxy insertion of location, whether by value or by reference has > the threat > of not being as subject to user control, but I think in every case > you have > to trust your provider to do as you wish, whether it is your presence > provider or your location provider independent of your presence > provider, > and proxy insertion doesn't fundamentally alter that. I worry more > about > it, but I don't objectively think it's much different. It is slightly different: For the presence provider, I can fairly easily verify whether the presence provider does what I tell him to do (unless the presence provider is clearly violating my privacy rules, which is probably subject to legal breach-of-contract recourse in most jurisdictions). This is much harder to do with proxy insertion. > sufficiently, and we have RFCs that permit it. Adding restrictions > on the > The only one that permits is the presence subscription model, which gives the target/rule maker a lot of control of who can do what with my location data. I can, on a person-by-person basis, restrict access to that data. If my proxy inserts some location object or reference to it that it made up, I don't even control the privacy rules in the object returned. > > I kind of like the idea that the proxy inserts the header in the > response so > the UAC can see it. What do others think of that? > This is probably a good idea, but imposes additional restrictions on the longevity of the reference. How long should I be able to "see" it? We don't want LIS to keep the location data around any longer than is needed, but there are no expectations set of what's reasonable. By-value doesn't suffer from these problems. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip