RE: [Geopriv] ResponseTime

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Tue Aug 28 2007 - 13:48:36 EDT

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]

 

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 28 Aug 2007 13:48:36 -0400

This archive was generated by hypermail 2.1.8 : Tue Aug 28 2007 - 13:50:23 EDT