Re: [Geopriv] Response time use cases (was: HELDcommentonresponseTime parameter)

From: Henning Schulzrinne ^lt;>
Date: Sat Aug 11 2007 - 12:28:55 EDT

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

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

> 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
Received on Sat, 11 Aug 2007 12:28:55 -0400

This archive was generated by hypermail 2.1.8 : Sat Aug 11 2007 - 12:30:51 EDT