RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance

From: Rosen, Brian ^lt;Brian.Rosen@neustar.biz>
Date: Tue Jul 25 2006 - 20:56:48 EDT

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:James.Winterbottom@andrew.com]
> Sent: Tuesday, July 25, 2006 8:46 PM
> To: Brian Rosen; Andrew Newton; Jeroen van Bemmel
> Cc: sip@ietf.org; Rosen, Brian; Marc Linsner; geopriv@ietf.org;
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:br@brianrosen.net]
> > Sent: Wednesday, 26 July 2006 10:40 AM
> > To: 'Andrew Newton'; 'Jeroen van Bemmel'
> > Cc: sip@ietf.org; Rosen, Brian; 'Marc Linsner'; geopriv@ietf.org;
> > 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
> > Geopriv@ietf.org
> > 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 25 Jul 2006 20:56:48 -0400

This archive was generated by hypermail 2.1.8 : Tue Jul 25 2006 - 21:02:59 EDT