RE: RE: [Geopriv] Consensus on changes to location-conveyance
"Rosen, Brian" <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Message-ID | <ED0887AEB595F74DB74934F4C37C08DC0A1966BB@stntexch04.cis.neustar.com> |
Ah, yes, but they can do the same with endpoint assertion of location, except that the user has more control over it. Don't object to carriers, or other service providers, making money off of location based routing. I just want the user to decide when it is, and isn't, okay to do that with his location. Controlling when the location header is attached to the message is a really hard stop on not-so-nice folks. When you let them assert location, then it's harder. Now, reiterating what I have said several times, I think location assertion by proxy is a done deal, whether I like it or not, just as I think location by reference is a done deal. There is one use case I like -- emergency call during transition, when the network knows, in some circumstances, where you are, but the endpoint and/or the access network is not yet upgraded. I just hate opening a big loophole for that one case though. Brian > -----Original Message----- > From: Winterbottom, James [mailto:[email protected]] > Sent: Tuesday, July 25, 2006 8:46 PM > To: Brian Rosen; Andrew Newton; Jeroen van Bemmel > Cc: [email protected]; Rosen, Brian; Marc Linsner; [email protected]; Peterson, > Jon > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance > > Brian, > > The fact that people can make money out of a solution scarcely seems a > good reason not to permit it! > > > > > -----Original Message----- > > From: Brian Rosen [mailto:[email protected]] > > Sent: Wednesday, 26 July 2006 10:40 AM > > To: 'Andrew Newton'; 'Jeroen van Bemmel' > > Cc: [email protected]; Rosen, Brian; 'Marc Linsner'; [email protected]; > > Peterson,Jon > > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location- > > conveyance > > > > > Please tell me that you are merely suggesting guidelines and > > > considerations by operators and are not suggesting 2119 language for > > > these? Because just like you'd never get agreement on the intended > > > duration or accuracy or confidence of location-by-value, you'd never > > > get agreement on these. > > I agree here > > > > > > > > > For the latter point: except for emergency scenario's, the UAC > > > > should include some flag in the INVITE saying "proxy: please > append > > > > location". You'd probably also want some feedback (eg proxy or UAS > > > > adding a header to the response saying 'this is the URL that I > > > > appended/got' > > > > > > Just thinking out loud here, but maybe the rule should be that > > > proxies never append a Location header except for emergencies. > > Works for me. Probably wouldn't work for those carriers who do not > intend > > to support location acquisition by endpoints and do plan to support > > commercial location based routing. They plan to make mucho dineros > > charging > > for location used for location based routing, and don't want those > pesky > > users to get in the way of their plans. Of course, they can overcome > all > > manner of protocol machinery with "As a condition of providing > service, > > user > > agrees ...." > > > > Brian > > > > > > _______________________________________________ > > Geopriv mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------ -- > ---------------------- > 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] _______________________________________________ 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