RE: [Geopriv] HELD comment on responseTime parameter

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Tue Aug 14 2007 - 20:52:04 EDT

Hi Cullen, Thank you - and you've still got your head :) My quick response is: I think the client *has* to know what the application for the location is. If the client is implemented as an "agent" on the device through which other applications query, then that agent needs to support an API through which the applications can prescribe the sensible response time. If the client doesn't know what response time is appropriate then it's not going to know any more if the LIS replies with some information about a better location being available if you'd like to hang around. If the client doesn't know how quickly it needs location then all bets are off. It also can't say whether ASAP or "MostAccurate" are appropriate. Cheers, Martin Oh - you're right LIS means exactly the same thing as LCS. (LCS=LIS=LS+LG) I use the term because LIS is what is used in the vernacular in the rest of the industry. I think all the regulars in Geopriv understand this but occasional visitors from the wider industry do not. LCS was coined relatively recently - and for no apparent useful purpose that I can fathom. The term "configuration" was only ever adopted to resonate with DHCP - and despite the fact that location isn't being "configured" in the same sense that a host is being "configured". I like "LIS", people outside Geopriv know what it means, it can be pronounced, and it doesn't have the namespace collision that LCS has with 3GPP. Call me an oddball - but I'll keep using it. -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Wednesday, 15 August 2007 10:23 AM To: Dawson, Martin; GEOPRIV Subject: Re: [Geopriv] HELD comment on responseTime parameter On Aug 13, 2007, at 9:34 PM, Dawson, Martin wrote: > Hi Cullen, > > There are certainly some people who haven't changed their stated > opinion. As ever, despite the consensus theory, any given thread in > Geopriv seems to have 90% of the emails generated by 3 or 4 people, > the > rest by one or two others. Who knows what the majority view is? It's > easy to suspect that most subscribers don't actually read the thread, > let alone have an opinion. You are probably right - makes it a challenge for the chair to determine consensus but the high bandwidth meeting time where people can talk about this does help. > > So, procedural conundrums aside - and given you've stuck your head > over > the trench :) - What do you think? Mostly I think that I should have kept my head firmly stuck in the mud at the bottom of the trench :-) > > In particular, how do you recommend the following be addressed? > > "A LIS has three or more methods of location determination, or a > single > method of location determination, where accuracy improves the > longer the > response time that is incurred. How does a LIS know which method to > use, > or how long to spend on a given method?" (as an irrelevant side note, I suspect that by LIS you mean something with significantly more functionality than I would meant but LCS but I will more or less read LCS where you write LIS because I don't think it makes much difference for the topic at hand) Also you mention the following > > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, 14 August 2007 11:31 PM > To: Dawson, Martin; 'Cullen Jennings' > Cc: geopriv@ietf.org; 'Mary Barnes' > Subject: RE: [Geopriv] HELD comment on responseTime parameter > > The answer to your question is that if a quick fix is available (1-2 > sec) > you use that to respond to ASAP, you use the most accurate response > for > the > rest. > [[MCD]] Which would completely fail to satisfy the routing requirement > for E911 in wireless access - because ASAP is not accurate enough and > most accurate is too slow. Which has been stated a lot of times > now. Do > you think this is an acceptable limitation? Because the cellular E911 > industry, including emergency services, didn't think so. So, just hypothetically let me assume that three methods that take small, medium, and large amount of time and that only one of these (medium) will be usable for E911 calls. I get that you are saying "The LCS needs to know which one of these to use and response time could be used to choose". I think Brian (and others) are saying the phone has no idea what is the right value to put in the responseTime parameter for a E911 call. Now I understand different application would have different requirements but none the less we do need to make sure that at least this E911 application is implementable on both the phone and LCS side. You have proposed text of what the server would do with this parameter but it might help if you tried to propose text that explained what phone implementers should do to set the responseTime value for the specific E911 application. It might also help if people thought about if all applications had only time based constrains, or if they had accuracy constraints, or if some applications really needed to know what the server could provide to pick which set of tradeoffs to take. A few people have proposed solutions of the form: The server returns the quickest answer possible along with information about other answers that can be returned and allows the client to pick the one that is right for it. This also allows things like users interfaces feedback about remaining time till an answer is received. You seemed to think this sort of design would not work but I did not really understand why not. It might be useful to explain that. Ted's email thread seemed like path that might lead to a good understanding of the solutions. I'm not sure that any of my questions are really worth replying to if the thread Ted started can help get to a good understanding of the solution space. Cullen <with my individual hat on> PS. - I don't have an opinion on if any particular design is the right one or not but the earlier threads did not really enlighten me enough that I can say I understand why it should be one way or the other. I suspect I am not the only one that feels that way. ------------------------------------------------------------------------------------------------ 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, 14 Aug 2007 19:52:04 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 14 2007 - 20:53:57 EDT