RE: [Geopriv] ResponseTime

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Tue Aug 28 2007 - 16:57:37 EDT

I really don't see how this meets the "keep it simple" test. I'd argue that a simple scalar response time parameter is simple. I couldn't agree that returning accuracy/time tradeoff curves is at all simple. It's also impractical. As soon as you put an accuracy requirement in, you have to define semantics for that requirement not being met. The server can always meet a response time requirement (if it wants). But what should the server do if the accuracy requirement isn't met? Should it return a specific error code or should it return the location it was able to determine and let the application choose? Cheers, Martin ________________________________ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 29 August 2007 3:49 AM To: Stuard, Doug; peter_blatherwick@mitel.com; Winterbottom, James Cc: 'GEOPRIV'; Dawson, Martin Subject: RE: [Geopriv] ResponseTime Generally, I think this is getting there. I think you want a way for the server to tell the client what kinds of time/accuracy tradeoffs it can make. Something simple would be fine. I just want to see some way to represent the time/accuracy curve(s), recognizing that they are non linear, discontinuous and not completely controlled. If the server always gives you an answer within 100m in 30 seconds, no matter what you ask for, I'd like the client to know that. I'm not looking for the whole curve, just the shape and dimensions. Recognize that you described this as all gated on time, but you could have described it based on accuracy and come out the same; there is a time/accuracy tradeoff, it's non-linear, and you can hold one constant and vary the other. Also need a mechanism to cope with time longer than a few seconds. I agree that we need confidence. I dearly would love to specify 90% and leave it at that. I fear we cannot. Normally, this is something you get back from the server, not an input parameter. Brian ________________________________ From: Stuard, Doug [mailto:Doug.Stuard@andrew.com] Sent: Tuesday, August 28, 2007 1:20 PM To: peter_blatherwick@mitel.com; Winterbottom, James Cc: GEOPRIV; Dawson, Martin Subject: RE: [Geopriv] ResponseTime Using only two optional parameters: (Time and Accuracy), I think all request cases can be addressed, and fairly simply: 1) No time or accuracy specified: "No location required" (inclusion of either optional parameter would require a location response). a. It was suggested that this case might mean "AGAP, no time limit", but how is "AGAP" determined? - there has to be some point at which calculations stop and a result is reported, either a time limit or an accuracy threshold or convergence (cases 2 and 6 below)) 2) No time specified, accuracy specified: However long it takes to achieve the specified accuracy. 3) Time=0, no accuracy specified: ASAP with whatever accuracy is available* 4) Time=0, accuracy specified: ASAP so long as specified accuracy met, otherwise fail. a. This case may be of limited usefulness. 5) Time >0, no accuracy specified: AGAP within the specified time limit* 6) Time >0, accuracy specified: AGAP within the time limit or until specified accuracy is achieved, whichever comes first. *In cases where there is no accuracy specification (3&5), the accuracy should be included in the result if available. It may be included in the others as well. Most database based responses would either be of type 1 (civic) or type 3 (fixed geo). Emergency call routing would be based on a Type 3 request or a Type 5 with an appropriate time limit Also, the definition of "accuracy" needs to be addressed. For calculated accuracy as in wireless, the uncertainty at a specified confidence (90% is often mentioned) might be appropriate. Doug From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Tuesday, August 28, 2007 11:24 AM To: Winterbottom, James Cc: Stark, Barbara; Stuard, Doug; GEOPRIV; Dawson, Martin; Robert Sparks; Roger Marshall Subject: RE: [Geopriv] ResponseTime Hmmm .... This is tending towards more complicated, not less. (Noting esp the proposal for possibly 3 parameters.) James wrote: > Given my description of profiling above, would people be prepared to accept the following: > > 1) No responseTime provided, you get AGAP, however long that takes. > 2) responseTime = 0, you get ASAP > 3) responseTime >0, you get best in time provided. > > If people want other things, then they can profile those in HELD extensions. > This meets Peter's previous concern, if he wants minimal wired-client support, his HELD client says responseTime=0. Actually, in a wired case where location is actually known virtually instantaneously, I would expect the client would include no ReponseTime parameter at all. How about a different compromise? Since it *seems* to be the case that ResponseTime is primarily a concern for mobile devices (particularly cellular), how about it the parameter is an extension, but mobile devices (or ones which might be mobile, such as soft clients), by their nature, need to implement it. This is predicated on others in cellular space also agreeing that ResponseTime is actually needed there. (I am not a cellular expert, but also note most responses are coming from what Robert rightly termed "just the folks that were active in the discussion earlier" ;-) -- Peter ------------------------------------------------------------------------ ------------------------ 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] ------------------------------------------------------------------------------------------------ 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, 28 Aug 2007 15:57:37 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 28 2007 - 16:59:32 EDT