RE: [Geopriv] ResponseTime

From: Roger Marshall ^lt;>
Date: Tue Aug 28 2007 - 15:53:02 EDT

This gets to the nagging problem of how good is 'good enough'?
Determining elements can certainly provide position, based on input of
67% confidence, but they can also do better. If you're willing to wait
a few more seconds, they can churn out a more accurate result based on a
90 or 95% input value. In fact, maybe they'll have to use 95% to get
the level of precision that some regulatory agency will ask for someday.
By providing confidence value as an input to these mechanisms, you can
achieve location hiding (to some degree) as well.
-roger marshall.


        From: Brian Rosen []
        Sent: Tuesday, August 28, 2007 12:45 PM
        To: 'Stuard, Doug';; 'Winterbottom,
        Cc: 'GEOPRIV'; 'Dawson, Martin'
        Subject: RE: [Geopriv] ResponseTime

        James pointed out to be that PIDF-LO profile actually does say
use 67%. While I'd much prefer 90 or 95%, a single standardized value
beats any set of values hands down.





        From: Brian Rosen []
        Sent: Tuesday, August 28, 2007 3:05 PM
        To: 'Stuard, Doug';; 'Winterbottom,
        Cc: 'GEOPRIV'; 'Dawson, Martin'
        Subject: RE: [Geopriv] ResponseTime


        In line



        From: Stuard, Doug []
        Sent: Tuesday, August 28, 2007 2:29 PM
        To: Brian Rosen;; Winterbottom,
        Cc: GEOPRIV; Dawson, Martin
        Subject: RE: [Geopriv] ResponseTime


        See embedded comments.




        From: Brian Rosen []
        Sent: Tuesday, August 28, 2007 1:49 PM
        To: Stuard, Doug;; Winterbottom,
        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.


        [Stuard, Doug] The fact that the time/accuracy tradeoff is
non-linear and often discontinuous is irrelevant, as it cannot be known
a priori by the client OR by the server (except in a general way). IMO
the actual shape of the curve matters little to the client. Time and
accuracy thresholds are the key items that matter. A client/application
should specify what it wants/needs, regardless of the server's apparent
intransigence. The client then must have a mechanism for dealing with a
response that is not entirely what it asked for (don't we all?).

        <br>The server knows what the curves look like. It's not
precise (this much accuracy in this much time), but they know the shape.
I believe in apps that adapt to reality, rather than assuming the server
can always do what the client wants. The client wants infinite accuracy
in zero time. It will put up with less, but it wants to know what it
has to work with. This is a big stumbling block: you-all seem to think
it's way too complicated for a poor little app to understand, so give
big daddy server your absolute drop dead limits and big daddy will do
the best it can. I don't believe in big daddy. My apps can make use of
whatever information you can give me. You all think there are finite
limits that apps drop dead after. There aren't; all the numbers are
arbitrary, and without any information they are really arbitrary.


        Recognize that you described this as all gated on time, but you
could have described it based on accuracy and come out the same;


        [Stuard, Doug] Perhaps, but people are impatient, and the
concept of "good enough" is usually limited by "not soon enough" (Case


         there is a time/accuracy tradeoff, it's non-linear, and you can
hold one constant and vary the other.


        [Stuard, Doug] This is in essence what you are doing with Case 5
(time>0, no accuracy specified), and Case 2 (accuracy specified, no time
limit). You can do it either way.


        Also need a mechanism to cope with time longer than a few


        [Stuard, Doug] Agreed


        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.


        [Stuard, Doug] I would think the client/application would like
to assume a "standard" (there's that word again!) value. Perhaps this
would be set at the server. We don't need to replicate the current
E9-1-1 confidence/uncertainty conundrum. People understand uncertainty,
but confidence is often lost on them. Better to settle on a reasonably
good but achievable confidence value (e.g., 90%, or whatever makes sense
for the application) then to leave it open.


        <br>Hey, I like it; if you can get everyone to agree, 90% is a
good number!






        From: Stuard, Doug []
        Sent: Tuesday, August 28, 2007 1:20 PM
        To:; 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

        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.





        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
> 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.



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.


The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

Geopriv mailing list
Received on Tue, 28 Aug 2007 12:53:02 -0700

This archive was generated by hypermail 2.1.8 : Tue Aug 28 2007 - 15:54:58 EDT