RE: 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