RE: [Geopriv] HELD comment on responseTime parameter

From: Winterbottom, James ^lt;James.Winterbottom@andrew.com>
Date: Sat Jul 21 2007 - 10:08:22 EDT

-----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Sat 7/21/2007 8:57 AM To: Winterbottom, James; 'Stark, Barbara'; 'Mary Barnes'; geopriv@ietf.org Subject: RE: [Geopriv] HELD comment on responseTime parameter Please describe a realistic use case where there actual value in a variable, especially with the client not understanding what the capabilities of the server are. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, July 20, 2007 11:17 PM > To: Stark, Barbara; Mary Barnes; geopriv@ietf.org > Subject: RE: [Geopriv] HELD comment on responseTime parameter > > I don't agree with this position for several reasons. > > The first is that in the geopriv space we are not simply talking about > routing and I can wait applications, there may be a range of > applications that we have not yet considered. Placing an unnecessary > restriction of this type in the protocol may well stop it from being > useful in other applications later. > > Secondly wireless networks deployed today may have several ways of > determining the location of device, and each one takes a different > amount of time. Moving this type parameter to being strictly to a binary > scheme means that an LCS can only ever support two such mechanisms since > if it has more than 2 it has no appreciative way of determining which of > longer period mechanisms to invoke. > > I would like to see the parameter stay as it is. > > Cheers > James > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Saturday, 21 July 2007 4:25 AM > > To: Mary Barnes; geopriv@ietf.org > > Subject: [Geopriv] HELD comment on responseTime parameter > > > > I'm probably opening a can of worms with this comment, but I'll make > it > > anyway... > > > > There have been discussions elsewhere as to whether it's really > > useful/meaningful to specify a desired response time, or whether it's > > better to specify that the response is needed right away (presumably > for > > routing purposes) or the device can wait a little to get a more > precise > > location. > > > > Should we have that conversation here, about this parameter? > > Barbara > > > > ***** > > > > The information transmitted is intended only for the person or entity > to > > which it is addressed and may contain confidential, proprietary, > and/or > > privileged material. Any review, retransmission, dissemination or > other > > use of, or taking of any action in reliance upon this information by > > persons or entities other than the intended recipient is prohibited. > If > > you received this in error, please contact the sender and delete the > > material from all computers. GA623 > > > > > > > > > > _______________________________________________ > > 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 Brian, We have had this discussion before. An application may well know how quickly it needs location, without having any idea how long the access network will take to obtain it. Simply having arbitrary low, medium high for latency is not prescriptive and will run into problems when moving between different access networks unless you have international standard values for each of these. Providing a time means that this complexity is not required, and applications can decide how long they are prepared to wait. Cheers James ------------------------------------------------------------------------------------------------ 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 Sat, 21 Jul 2007 09:08:22 -0500

This archive was generated by hypermail 2.1.8 : Sat Jul 21 2007 - 10:11:32 EDT