RE: [Geopriv] Response time use cases (was: HELDcommentonresponseTimeparameter)

From: Winterbottom, James ^lt;>
Date: Sat Aug 11 2007 - 19:23:40 EDT

Henning, I had already countered almost all of these arguments in my previous email to Brian. Please take a look at those and come back with something new. As a summary: 1) Your emergency citation is incorrect in the wireless case. 2) Applications generally have BOTH a time and an accuracy constraint 3) Your discussion on the operating system is a call for no timeouts in any applications ever. Please tell me that you don't seriously believe this? 4) timeouts for applications are based on empirical data, so yes, they do no how long to wait, yes there is not guarantee that the location will be better, but there is a very good chance that it will be. I for one don't see applications waiting minutes for location responses, so if the issue can be resolved with putting an upper bound on the responseTime then I am happy to set that in the schema to say a minute. I don't believe that this is misguided, I put this into the same category of proposals that I and others have put into this forum such as: an application layer location acquisition protocol, local service discovery, location by reference. All things that I have had to fight very hard over the last 2 and half years to get accepted because a small group said they were misguided! Regards James > -----Original Message----- > From: Henning Schulzrinne [] > Sent: Sunday, 12 August 2007 2:29 AM > To: Dawson, Martin > Cc: GEOPRIV WG > Subject: Re: [Geopriv] Response time use cases (was: > HELDcommentonresponseTimeparameter) > > > On Aug 10, 2007, at 8:53 PM, Dawson, Martin wrote: > > > Hi Henning, > > > > You continue to repeat the same incorrect statements and not > > acknowledge > > any of the valid points that have been made. Use cases have been > > provided. What is the point of people providing use cases if you just > > dismiss them without commentary as "not realistic"? > > > > Two questions you have not responded to and I insist you do > > > > 1. Please cite any real client-server request for location that would > > not see the client imposing some time-out on the request. > > Brian cited examples, so I saw no need to add to those. I had also > mentioned that almost all pre-call location determination calls will > fall into this category. For in-call techniques, the client wants "as > soon as I get a location useful for routing". Specifying a time that > is smaller than that (unknown) necessary time is pointless and > counterproductive. > > Naturally, eventually anything will time out, if only because some > TCP library will give up, but those timeouts are measured in multiple > minutes, i.e., beyond interesting location determination times. > Unfortunately, the client software generally won't know what these > values are, so even if they mattered, the HELD client couldn't offer > them. (Quick, what's the timeout in the OS you're using?) > > > > > > 2. Please explain how a LIS with 3 or more options for location > > determination which trade off response time against accuracy could use > > anything other than fast/bad or slow/accurate without this client > > guidance. > > As you keep ignoring, the client has no way to know what it will get > for different time-outs. In the cases I cited, the client wants a > certain accuracy as quickly as possible and could care beans about > the mechanism used. As I've also pointed out repeatedly, a timeout > provides no sensible means to select the mechanism except by the > equivalent of throwing darts. > > > > > If all we can get is the same general unsupported and academic > > statements made over and over again then this discussion is obviously > > going nowhere. > > Thanks for the helpful characterization. You have unfortunately never > offered a logical description as to how a client would pick the > timeout value except by random conjecture and the moral equivalent of > "ASAP". > > > > > Brian, BTW, has agreed to the scalar parameter without acknowledging > > himself to be a fan. I'd add the third question as to why you want to > > prevent an, at worst, benign and always optional parameter if others > > consider so strongly that it is valuable? > > > > Because I believe it to be misguided. > > > Regards, > > Martin > > > > > > _______________________________________________ > Geopriv mailing list > > ------------------------------------------------------------------------------------------------ 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
Received on Sat, 11 Aug 2007 18:23:40 -0500

This archive was generated by hypermail 2.1.8 : Sat Aug 11 2007 - 19:25:44 EDT