RE: [Geopriv] ResponseTime

From: Roger Marshall ^lt;>
Date: Mon Aug 27 2007 - 17:21:28 EDT

What about using two independents, or even three variables?
Timing and Uncertainty are two variables that could, (if implemented
rightly among the elements which determine location), provide additional
control, as well as allow the server to choose among different back-end
determination technologies, as Robert mentioned in this thread.
Examples of:
0 : 0 (means give me whatever location you have asap)
0 : 50 (means provide location which is reported as being within a
radius of 50m asap)
30 : 50 (means provide a location inside a radius of 50m within 60
Coupling what is also done (by some vendors) within Wireless/CS domains
today, you could add a third variable, though a 'confidence' parameter
is still somewhat misunderstood (and certainly mis-applied), so most
might want to set this third value to a constant for now:
30 : 50 : 95 (give me the location with a 50m or less tolerance,
determined within 30 seconds with a confidence of at least 95%)
-roger marshall.


        From: Stuard, Doug []
        Sent: Monday, August 27, 2007 2:13 PM
        To: Dawson, Martin; Stark, Barbara;;
Robert Sparks
        Cc: GEOPRIV
        Subject: RE: [Geopriv] ResponseTime

        Given the practical limits stated, option i) is good

        Option ii) as stated seems too open ended. If restated to "as
accurate as you can get it within the stated time limit", I think
virtually all realistic use cases are covered.


        In practice, a number of techniques converge within 20 seconds
or so, so you could either wait until the stated time limit, or until
(reasonable) convergence is achieved.





        From: Dawson, Martin []
        Sent: Monday, August 27, 2007 4:46 PM
        To: Stark, Barbara;; Robert Sparks
        Cc: GEOPRIV
        Subject: RE: [Geopriv] ResponseTime


        The semantics of response time are "most accurate you can get
within this time".


        I think I've seen both defaults proposed. That is, the absence
of the response time parameter can be:


        i) As fast as possible at whatever accuracy that
results in.

        ii) Take as long as you like until you think it's as
accurate as you can get it.


        Given there are technologies that could see incremental (and
diminishingly small) improvements in accuracy for every
iteration/measurement - even if it went on all day - the LIS would have
to apply its own interpretation of "accurate as you can get it" but
that's an invisible judgement as far as the client is concerned.


        Obviously both defaults can't apply. To me, logically, a
response time of zero would mean as fast as possible (since zero can
only have theoretical significance so it might as well have a special
interpretation). That would leave option ii) as the default semantic.






        From: Stark, Barbara []
        Sent: Tuesday, 28 August 2007 6:30 AM
        To:; Robert Sparks
        Cc: GEOPRIV
        Subject: RE: [Geopriv] ResponseTime


        I think there is a need for a device to be able to ask for a
"ASAP" vs. "accurate" response for location to be used when requesting
emergency services. If it were totally optional, and not using it means
"ASAP", then how does a device request "accurate"? I was suggesting
using a default value, like 60 seconds (but hopefully recommended by
phonebcp) to mean "accurate".




        Sent: Monday, August 27, 2007 2:39 PM
        To: Robert Sparks
        Cc: GEOPRIV
        Subject: Re: [Geopriv] ResponseTime

> ... need to hear from more of the group than
> just the folks that were active in the discussion earlier in
the month
        I have stayed mostly out of the debate thus far, so here goes.

        I would support response time parameter ONLY as an optional
extension. This for the following reasons:
        o I do not see value in it for the most part; I expect most
applications (including ECS) simply don't need it or it would bring
fairly minimal value added. (I can certainly see some special cases /
applications where it might be helpful, hence do see value as optional
extension for those.)
        o It seems very difficult to make such a parameter specific
enough to get the proposed value out of it in any consistent way,
        o MOST IMPORTANT I desperately want endpoints needing to support
HELD for ECS purposes to have an absolutely ruthlessly simple subset of
the functionality that they must implement. The subset must be both
small (footprint) and very easy to implement correctly. Endpoints that
want to do more than ECS can add to the simple subset by using extended
options, but those that do only the ECS part need to be very
constrained. The value added bar needs to be set very high for the core
subset. The value of response time parameter in ECS does not make that
grade for me.
        Just to be clear on that last point, I'm not all that concerned
about the protocol itself (pretty easy) but more so about the
implications to the rest of the implementation: What to do if response
does not come back in requested time ... what to do if not at requested
accuracy .. what if .. what if .... And also I have the general concern
of "feature creep", of which this is one potential example.
        -- Peter


Robert Sparks <>

27.08.07 12:05

        To: GEOPRIV <>
        Subject: [Geopriv] ResponseTime

        All -
        Lets push to close on the responseTime question.
        To do this, I'm going to need to hear from more of the group
        just the folks that were active in the discussion earlier in the
        So far, I've seen a good argument that a server can have
        technologies available for determining location and would
        from knowing something about how long a client is willing to
wait in
        order to choose which one to focus on. There has been a question

        about an implicit time/accuracy tradeoff here and a suggestion
        we should explore a more explicit separation of indicating those
        I've also seen a good argument that it is unclear how a client
        implementation is going to provide values that would be useful
to the
        server. Without more clarity around this point, I see discomfort
        several people that the proposed mechanism is an opportunity for

        "Unintended Consequences" to rear its head.
        On rereading the threads, I strongly suspect that there are a
set of
        assumptions going into arguing for this parameter that haven't
        made explicit yet, and I'd like to try a round of teasing those
        to see if it closes the gap in the discussion.
        Lets start with these two statements (which I _think_ the folks

        pushing for the parameter are assuming are true - correct what I
        wrong please):
        1) The clients will provide a useful indication of responseTime
        the server's point of view.
        2) Different clients (or different applications at the same
        will provide different enough values to make the same server
        different location technologies in servicing the query.
        I can see the parameter helping a system work as long as the
        has some way to tell the client what to ask for (and I recognize
        means the client has to know what service it's invoking).
        James (or anyone else who has deployed or is developing a
        of something like this) - do you expect to have some influence
in a
        deployment over what the clients include in this parameter? Are
        expecting to have a relationship with the vendors providing
        that lets you hand them values to hardcode,
        or give you a configuration interface you can use as a service
        provider? Or are you expecting that to be entirely outside your
        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.


        The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential,
proprietary, and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please contact
the sender and delete the material from all computers. GA622

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 Mon, 27 Aug 2007 14:21:28 -0700

This archive was generated by hypermail 2.1.8 : Mon Aug 27 2007 - 17:23:56 EDT