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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.