Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-http-location-delivery-01.txt

From: [email-masked]
Date: Thu, 12 Jul 2007 13:17:12 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title		: HTTP Enabled Location Delivery (HELD)
	Author(s)	: M. Barnes
	Filename	: draft-ietf-geopriv-http-location-delivery-01.txt
	Pages		: 37
	Date		: 2007-7-12
	
A Layer 7 Location Configuration Protocol (L7 LCP) is described that
   is used for retrieving location information from a server within an
   access network.  The protocol includes options for retrieving
   location information either by-value or by-reference.  The protocol
   supports mobile and nomadic devices through Location URIs.  The
   protocol is an application-layer protocol that is independent of
   session-layer; an HTTP, web services binding is specified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-geopriv-http-location-delivery-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Robert Sparks <[email-masked]>
Date: Thu, 12 Jul 2007 13:00:50 -0500

Now would be a good time to comment on this draft.

Does it meet the requirements in draft-ietf-geopriv-l7-lcp-ps-02?

Is there anything here that shouldn't be?

Do you feel this is a good place to work from to provide an http  
location delivery mechanism?

RjS

On Jul 12, 2007, at 12:17 PM, [email-masked] wrote:

> Content-Type: text/plain
> Content-ID: <[email-masked]>
>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Jul 2007 13:58:23 -0500

Here's a summary of changes between the -00 and -01 versions:
1) heldResponse renamed to locationResponse
2) Changed namespace references for the PIDF-LO geoShape in the schema
to match the agreed GML PIDF-LO Geometry Shape Application Schema
3) Removed "options" element - leaving optionality/extensibility to XML
mechanisms
4) Changed error codes to be enumerations and not redefinitions of HTTP
response codes
5) Updated schema/examples for the above and removed some remnants of
the context element 
6) Clarified the definition of "Location Information (LI)" to include a
reference to the location (to match the XML schema and provide
consistency of usage throughout the document).  Added an additional
statement in section 7.2 (locationType) to clarify that LCS MAY also
return a Location URI. 
7) Modifed the definition of "Location Configuration Server (LCS)" to be
consistent with the current definiton in the requirements document.
8) Updated Location Response (section 6.3) to remove reference to
context and discuss the used of a local identifier or  unlinked
pseudonym in providing privacy/security. 
9) Clarified that the source IP address in the request is used as the
identifier for the target/device for the HELD protocol as defined in
this document. 
10) Miscellaneous editorial changes.

And, here's the diff from the tools page that might be handy for folks
that reviewed previous versions:
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-http-location-delive
ry/draft-ietf-geopriv-http-location-delivery-01-from-00.diff.html

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 12, 2007 12:17 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Geopriv] I-D
ACTION:draft-ietf-geopriv-http-location-delivery-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Geographic Location/Privacy Working
Group of the IETF.

	Title		: HTTP Enabled Location Delivery (HELD)
	Author(s)	: M. Barnes
	Filename	:
draft-ietf-geopriv-http-location-delivery-01.txt
	Pages		: 37
	Date		: 2007-7-12

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-del
ivery-01.txt

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt".
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Jul 2007 14:11:18 -0500

In addition to the points that Robert highlights, James and I had 
some email discussions on a few issues while I was making the editorial
changes.
Feedback from the WG on these would also be appreciated.

The first is to do with locations provided in a location response
message. One of the features of HELD is that it will always try to
provide
you location in some form, unless you explicitly tell the LCS to provide
only
what you ask for. This is based on the presumption that something is 
better than nothing. The issue is that if you ask for say geodetic, 
jurisdictionalCivic,and postalCivic, but the resulting location only 
includes geodetic and jurisdictional, how do you know what was provided?

Something similar is done in LoST, and could be done with HELD using
something like: 
<returned>geodetic,jurisdictionalCivic</returned> 
<notReturned>postalCivic</notReturned> 
and perhaps a new response code of "partialSuccess". 

The second is the concern of LCS server redirects. Our general position
is that these are a bad thing. A Device will generally have to discover
the address of the LCS. This yields a URL from which the Device requests

location information. We expect the LCS to proffer a server-side
certificate that the Device can check against the host name in the URL.
If we allow a redirect, it does not seem that the Device
can be sure that it is getting location from the correct source? 
The current position would be to forbid server redirects.

The third is whether or not a specific HELD URI-type is
required/necessary. There are some advantages to providing it. Does
anyone have a strong opinion either way?

Mary.

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Thursday, July 12, 2007 1:01 PM
To: [email-masked]
Subject: Re: [Geopriv] I-D

RjS

readers

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jul 2007 15:59:36 -0400

> includes geodetic and jurisdictional, how do you know what was  

I don't quite understand the problem. The XML itself indicates  
whether this is geo or civic (or both). Clearly, you'd need a label  
of whether this is jurisdictional or postal, but that seems like a  
broader problem and occurs even if the query succeeds.

> The current position would be to forbid server redirects.

Are you talking about HTTP redirects or some special HELD redirect?

Note that the certificate authenticates the server, not the path.  
Thus, a query to

https://lcs.com/foobar/old/server

could be redirected to, via HTTP 302,

https://lcs.com/new/server

without breaking authentication or causing much other harm. I  
certainly wouldn't want to invent redirect functionality for HELD,  
but restricting legitimate  HTTP behavior seems pointless. (HTTP  
redirects sometimes happen for strange reasons, often somewhat  
outside the control of the writer of the application.)

> anyone have a strong opinion either way?

I see it as unnecessary and unhelpful. HELD is roughly similar to a  
SOAP query and the spec explicitly makes that connection; not every  
SOAP application gets a new top-level URL scheme. (Actually, none do.)

We had a similar discussion for LoST. You either pretty quickly  
encode the whole query into the URL (I can sell you a proposal that  
does that....) or it doesn't do anything useful.

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 12 Jul 2007 16:38:33 -0500

Hi Henning,

Thanks for the notes.
See inline.

> broader problem and occurs even if the query succeeds.

[AJW] I don't understand your comment here. The concern is what is in
the response, not what was sent to the LCS, the latter is expressed in
the schema.

> Are you talking about HTTP redirects or some special HELD redirect?

[AJW] Nope only talking about HTTP redirects. I don't see a need for
specialized HELD redirects.

> outside the control of the writer of the application.)
[AJW] Does it seem reasonable then that a redirect must only be allowed
within the same domain then?
 
> does that....) or it doesn't do anything useful.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jul 2007 18:18:42 -0400

> the response, not what was sent to the LCS, the latter is expressed in

Indeed. The response XML clearly indicates what kind of information  
this is, except for the postal vs. jurisdictional aspect, as they  
both look the same.

> within the same domain then?

I'm not sure this is necessary. Even a redirect across servers is  
just another trust indirection:

(1) Client trusts secure1.example.com

(2) Client connects to secure1.example.com and gets, via HTTPS, a 302  
to secure2.example.com; nobody else can inject that answer.

(3) Client trusts the answer and asks secure2.example.com for the  
location information.

This doesn't seem to introduce any new vulnerabilities.

I don't know how browsers react to this scenario. Maybe somebody who  
has more direct HTTPS experience can tell us.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 12 Jul 2007 17:36:49 -0500

> this is, except for the postal vs. jurisdictional aspect, as they

[AJW] This may also become problematic for geodetic information if we
adopt a profiling mechanism as you suggested on the ECRIT mailing list.
So the <provided> <not provided> tags might still have a use even with
different geodetic profiles. Just a thought.

> has more direct HTTPS experience can tell us.

[AJW] This seems fair, though having someone confirm how other things
handle the same problem would be good.

Cheers
James

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jul 2007 22:24:08 -0400

> different geodetic profiles. Just a thought.

I just don't see how this helps significantly. If you have two civic- 
looking elements, you still won't know which is postal.

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 12 Jul 2007 22:07:10 -0500

Oh okay I think I understand the issue you are raising.
It is not such much that the thing that made the HELD request can't
understand which is which, because the LCS is supposed to put things in
the same order in which they were requested. It is more that if I
subsequently pass my PIDF-LO to you, that you don't necessarily know
which is which.

This seems a more general problem with PIDF-LO with HELD per say. This
is either something we can address at the root, or ignore for now. I am
definitely open to suggestions.

Cheers
James

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, 13 July 2007 12:24 PM
> To: GEOPRIV
> Subject: Re: [Geopriv]I-D ACTION:draft-ietf-geopriv-http-location-
> delivery-01.txt
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jul 2007 23:21:13 -0400

I don't see much of a problem for the geo shapes, as they should be  
self-identifying from the XML tags. For the civic one, it may be  
sufficient to use indirect identification. Anything containing the  
PCN (postal community name) is presumably postal, and something that  
only contains A[1-6] labels is jurisdictional. We obviously have  
hybrid versions, which have both PCN and A3, say, since often only  
the community name differs between the two, if they differ at all. A  
different issue is the source of the address, or its verification  
against either postal or jurisdictional records. The latter seems to  
require more explicit labeling if we care about this.

I'm not thrilled with adding extra labels since this simply adds more  
error conditions and more opportunities for strange implementation  
quirks. (What if the labels and the data disagree? We have the whole  
IE content-type experience as an instructive example, where a  
combination of labeling and deduction-from-content results in a royal  
mess.)

Henning

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 20 Jul 2007 14:18:52 -0400

After reading the current HELD draft, I have a few comments, which I'll
separate into a few emails.

The locationType parameter is noted as being mandatory in a Location
Request. However, it has a default defined, if none is specified.

If the parameter is mandatory, there's no need for a default. If there's
a default (for when the parameter isn't specified), then the parameter
is optional.

I recommend keeping the default, and making the parameter optional.

Barbara

*****

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

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 20 Jul 2007 14:25:09 -0400

I'm probably opening a can of worms with this comment, but I'll make it
anyway...

There have been discussions elsewhere as to whether it's really
useful/meaningful to specify a desired response time, or whether it's
better to specify that the response is needed right away (presumably for
routing purposes) or the device can wait a little to get a more precise
location.

Should we have that conversation here, about this parameter?
Barbara

*****

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Jul 2007 14:31:29 -0400

I suspect that there will only be a small number of useful values in  
practice:

(1) immediately
(2) a few seconds, i.e., short enough for dispatch
(3) open ended, subject to some reasonable timeout (minutes), which  
is the case where the device is not in an emergency call

For (2), subscription, with updates, is probably a better approach. I  
don't know if specifying precise values is easier or harder than  
"immediately", "soon" or "whenever". The number of techniques not on  
the end system where this makes a difference is also pretty small.

Henning

On Jul 20, 2007, at 2:25 PM, Stark, Barbara wrote:

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Jul 2007 14:34:49 -0400

Hehe

As you know, I am in the binary "gimme what you got now, gotta route this
call" or "I need a good location, I'll wait for it" camp.  

I have a really hard time coming up with a use case where you have a value,
and not knowing anything about what the other end can do, I think a value is
pretty useless.

Please keep in mind that "right away" is order of milliseconds and "I'll
wait" can be 30 sec give or take for a typical assisted GPS start up, and a
couple of minutes for a cold start GPS.  Right away is protocol
request/response territory.  Anything that has tens of seconds or more in it
is an async event notification/call back kind of thing.

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Friday, July 20, 2007 2:25 PM
> To: Mary Barnes; [email-masked]
> Subject: [Geopriv] HELD comment on responseTime parameter
> 
> 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. GA623
> 
> 
> 
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 20 Jul 2007 15:35:50 -0400

This comment also affects the L7 LCP requirements, since that's where
some of the terminology comes from.

Access Provider is defined as "an organization". That's singular.
Specifically, one that provides physical connectivity.

L7 LCP never defined the term, but I guess it sort of implied the same
thing, by inheriting the term from geopriv requirements.

My problem is that the device will most likely talk to the LCS of an L3
provider (a.k.a. ISP), and not the physical access provider. If the two
are the same, then that's fine. But if they aren't, then saying the
device talks to the physical access provider LCS isn't correct. Anyway,
I think we've had this semantic discussion before, and we agree that
this is true, and that there can be multiple LCS, etc.

I recommend the following changes:
In 3 Terminology, first paragraph, replace "Access Provider (AP)" with
"Access Network".
Delete Access Network Provider definition.
Delete Access Provider definition.
Add: 
Access Network (no abbreviation needed): The network that provides
physical and Layer 1 through Layer 3 connectivity to customers / users.
Examples of physical connectivity include digital subscriber lines,
cable TV plants, Ethernet, leased lines or radio frequencies. This
network may include elements owned by different providers, since it is
not necessary for all layers of access to be provided by the same
organization.

In LCS definition, delete "Provider's".
Delete Location Generator definition. I couldn't find any use of this.
Delete Location Server definition. I couldn't find any use of this.

In 4 (Overview and Scope) first paragraph, 3rd sentence, change it to
"The LCS service allows Devices (and Targets) to retrieve LI." In the
diagram, delete "Provider".

I think if L7 LCP removed the word "Provider" from sections 1 through 3,
that it would also be good.

I realize this goes all the way back to geopriv requirements. However,
that was written before it was necessary to distinguish between L2 and
L3 providers (like L7 LCP does in its latter sections). I'd rather not
touch geopriv requirements. But given all the requirements in L7 LCP
about relationships between providers, and given that we're now starting
LIS to LIS requirements, I think that suggesting "Access Provider" is a
singular organization is dangerous. I'm okay with having a singular
access network, so long as we mention that it may be operated by
multiple providers.

----------------------------
Miscellaneous typos / editorial comments
1. 1 Introduction, 2nd sentence, change "such as such as" to "such as"
2. end of that same paragraph, include reference to L7 LCP ("[11]").
3. 4 Overview and Scope, 4th paragraph, change "this protocol" to "the
HELD protocol", just for clarity, in case other people miss the obvious
antecedent, like I did at first.

Barbara

*****

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 20 Jul 2007 22:11:23 -0500

I think I agree with this position.
Thanks Barbara.

Cheers
James

> Sent: Saturday, 21 July 2007 4:19 AM
> Subject: [Geopriv] HELD Comment on mandatory locationType
> 
> material from all computers. GA621
> 
> 
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 20 Jul 2007 22:17:09 -0500

I don't agree with this position for several reasons.

The first is that in the geopriv space we are not simply talking about
routing and I can wait applications, there may be a range of
applications that we have not yet considered. Placing an unnecessary
restriction of this type in the protocol may well stop it from being
useful in other applications later.

Secondly wireless networks deployed today may have several ways of
determining the location of device, and each one takes a different
amount of time. Moving this type parameter to being strictly to a binary
scheme means that an LCS can only ever support two such mechanisms since
if it has more than 2 it has no appreciative way of determining which of
longer period mechanisms to invoke.

I would like to see the parameter stay as it is.

Cheers
James

> Sent: Saturday, 21 July 2007 4:25 AM

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 21 Jul 2007 09:57:44 -0400

Please describe a realistic use case where there actual value in a variable,
especially with the client not understanding what the capabilities of the
server are.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Friday, July 20, 2007 11:17 PM
> To: Stark, Barbara; Mary Barnes; [email-masked]
> Subject: RE: [Geopriv] HELD comment on responseTime parameter
>

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 21 Jul 2007 10:08:16 -0400

A couple more things:

Suppose the server can supply a coarse location immediately, and a precise
location in 30 seconds.

What happens if the client says "give me best available in 29.9 seconds"?

My point is that unless there is intelligent negotiation of the value, the
client is particularly clueless of what kind of result its going to get, and
thus what it should ask for.  And, even if you had negotiation, the
complexity of the client is pretty high to reasonably deal with a range of
server capabilities.

Then, what makes you think that you know in advance how long you can wait?
Perhaps cancel actually is what you want.

Finally, you did not address the issue that if the values we are talking
about are seconds, request/response is the wrong paradigm.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 21 Jul 2007 09:08:22 -0500

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Sat 7/21/2007 8:57 AM
To: Winterbottom, James; 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Brian

> > material from all computers. GA623

Brian,

We have had this discussion before.
An application may well know how quickly it needs location, without having any idea how long the access network will take to obtain it.
Simply having arbitrary low, medium high for latency is not prescriptive and will run into problems when moving between different access networks unless you have international standard values for each of these. Providing a time means that this complexity is not required, and applications can decide how long they are prepared to wait.

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 21 Jul 2007 09:22:08 -0500

Brian,

My first response is that even you with your no-wait, wait description is qualifies its definition by specifying a time... ;)

My second response is that you are totally confusing the ability of the HELD client to support something, and the application using the HELD client.
I have absolutely no issues with an application knowing how long it is prepared to wait for a location. I also don't see all applications fitting into the now or 30 second buckets that you are prescribing. Specifying a time allows this to occur.

As for seconds I frequently have to wait seconds for certain web application responses, are you suggesting that these are all using the wrong paradigm too?
Please note that the semantic of this request is, I want location, please calculate it with in the next 22 seconds. It is not, give me a response in 22 seconds time. Again, I think you are confusing these two issues. There is a case for the former, which this parameter addresses, and there is a case for the latter which would use the subscribe-notify.

Cheers
James

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Sat 7/21/2007 9:08 AM
To: Winterbottom, James; 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter
 
A couple more things:

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 21 Jul 2007 11:39:37 -0500

Hi Brian,

I think the fact that you feel the need to quantify "right away" and
"I'll wait" is revealing in itself. Of course "right away" literally
means zero wait and "I'll wait" is any time up to infinity. The values
you "prescribe" are based on your here/now understanding and presumption
of specific applications.

Requesting location in a WCDMA UTRAN can involve relating the serving
cell directly to a nominal area of coverage (msec), putting the device
into soft handoff to collect a set of round-trip time measurements from
in-range base stations (a few seconds), or doing A-GPS (up to, say, 30
seconds). Each places different demands on network resources.

The cell-based location may be adequate for accurate PSAP routing 67%
while RTT may be accurate 99.9% of time. Other applications will
similarly be sensitive to accuracy variations. Tolerance for response
delays isn't something you can claim to be able to predict for all
applications today and forever.

It's no good saying that an application that asked for a four second
response might say "oh - if I'd known I could have had the result in
five seconds, I'd have been OK to wait." If it is OK to wait five
seconds, then it should request a response time of at least five
seconds.

As we've explained before, our experience has shown that the Low-delay
or Delay-tolerant choices that the 3GPP protocols provide have been
problematic. At least in that case there has been an accompanying
(scalar) accuracy requirement to go along with the QoS. The latter has
at least facilitated some ability to arbitrate between location
techniques and order of fallback. With just a binary response time
requirement, it would be impossible to do any arbitration.

If you assume you know everything now and force a binary choice into the
semantics, then you can't undo that if it's a mistake. If the semantics
support a scalar response time and it turns out that 100msec and 30sec
is all anyone ever needs then, at worst, that is what ends up being put
in all the HELD requests.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 21 July 2007 4:35 AM
To: 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Hehe

As you know, I am in the binary "gimme what you got now, gotta route
this
call" or "I need a good location, I'll wait for it" camp.  

I have a really hard time coming up with a use case where you have a
value,
and not knowing anything about what the other end can do, I think a
value is
pretty useless.

Please keep in mind that "right away" is order of milliseconds and "I'll
wait" can be 30 sec give or take for a typical assisted GPS start up,
and a
couple of minutes for a cold start GPS.  Right away is protocol
request/response territory.  Anything that has tens of seconds or more
in it
is an async event notification/call back kind of thing.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 21 Jul 2007 16:26:51 -0400

I'm sorry, but this still makes no sense to me. 

I'm having difficulty figuring out how any application can use any values
other than "now" and "when it's good", especially with no accuracy
parameters.  Whether "when it's good" is 5 seconds, 15 seconds, 30 seconds
or any other value, I still don't see how you can really use it.

I understand that the methods for measurement are varied, and have different
response times.  I don't see how a client of the protocol can make use of
that acknowledged fact.  All of the apps that use location that I can think
of only can use "now" or "when it's good", as long as they can give up on
the "when it's good".

If we were trying to more closely match what actually happens with
measurement based location determination, or which GPS is the easiest
example to work with, we would have the protocol deal with start up issues.
The characteristic of GPS is that there is a significant start up time, but
after that, location updates equivalent to "now" is what you get.

Most triangulation mechanisms have some kind of start up, most have updates
equivalent to "now", but some don't (some triangulation really is a
triggered measurement, which has finite, non trivial time to complete a
measurement).

When there is a delay for an accurate measurement, the server knows what the
delay is.  If we were trying to really get both sides to do something
reasonably optimal, we'd have the server tell the client what it can do, and
have the client react in some reasonable way.

When there is a startup issue, and sometimes when there is a significant
time to complete a measurement, there can be intermediate, less than full
accuracy results.  Again, if we were trying to make optimal applications,
the server would have some way to tell the client what it could do, and have
the client react.

No matter what the measurement methodology, there is very little variability
on the server side.  It's built to do what it does, and it can't actually
vary much.  Having the client tell the server what it wants is backwards:
the server can't actually react; all it can do is do what it does, and drop
some kind of response when the timer expires.  Actually, in nearly every
case, it can predict what happens, but that doesn't help the client any.

The client, if it really cares, could react to what the server can do, a lot
more usefully than having the server react to what the client is asking for.
If the server tells it that it has a startup problem, and will have accurate
results in 30 seconds, the client could display some useful feedback, as an
example. 

Finally, most measurement systems have a time/accuracy tradeoff, especially
if the target is not moving.  The longer you wait, the more accurate the
measurement.  If the measurement mechanism is triggered, you restart the
time/accuracy clock.  So, asking for a measurement with a timeout would not
allow you to use a triggered measurement with a time/accuracy tradeoff.  The
client doesn't understand that if it either lengthened the time, or
lengthened the time between requests, it would get more accuracy.  If we
were trying to get both sides to do something optimal, the server would tell
the client that retriggering resets the time/accuracy tradeoff, and it would
tell the client what the time/accuracy function looked like.

Let me also react to "web servers take seconds".  Sure.  But there are
humans involved.  Protocol mechanisms that take seconds are best done with
event notification or call back mechanisms.  If you don't do that, you have
to use threads or polling, or some other ugliness to not block on the
exchange.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Saturday, July 21, 2007 12:40 PM
> To: Brian Rosen; Stark, Barbara; Mary Barnes; [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 22 Jul 2007 01:12:38 -0500

All the client has to know is how long it is prepared to wait for a
result. That's it.

I don't see any new information in your post - a couple of things I
disagree with but none that are really relevant to how the delay
tolerance should be prescribed. I vote for a scalar parameter.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Sunday, 22 July 2007 6:27 AM
To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

I'm having difficulty figuring out how any application can use any
values
other than "now" and "when it's good", especially with no accuracy
parameters.  Whether "when it's good" is 5 seconds, 15 seconds, 30
seconds
or any other value, I still don't see how you can really use it.

I understand that the methods for measurement are varied, and have
different
response times.  I don't see how a client of the protocol can make use
of
that acknowledged fact.  All of the apps that use location that I can
think
of only can use "now" or "when it's good", as long as they can give up
on
the "when it's good".

If we were trying to more closely match what actually happens with
measurement based location determination, or which GPS is the easiest
example to work with, we would have the protocol deal with start up
issues.
The characteristic of GPS is that there is a significant start up time,
but
after that, location updates equivalent to "now" is what you get.

Most triangulation mechanisms have some kind of start up, most have
updates
equivalent to "now", but some don't (some triangulation really is a
triggered measurement, which has finite, non trivial time to complete a
measurement).

When there is a delay for an accurate measurement, the server knows what
the
delay is.  If we were trying to really get both sides to do something
reasonably optimal, we'd have the server tell the client what it can do,
and
have the client react in some reasonable way.

When there is a startup issue, and sometimes when there is a significant
time to complete a measurement, there can be intermediate, less than
full
accuracy results.  Again, if we were trying to make optimal
applications,
the server would have some way to tell the client what it could do, and
have
the client react.

No matter what the measurement methodology, there is very little
variability
on the server side.  It's built to do what it does, and it can't
actually
vary much.  Having the client tell the server what it wants is
backwards:
the server can't actually react; all it can do is do what it does, and
drop
some kind of response when the timer expires.  Actually, in nearly every
case, it can predict what happens, but that doesn't help the client any.

The client, if it really cares, could react to what the server can do, a
lot
more usefully than having the server react to what the client is asking
for.
If the server tells it that it has a startup problem, and will have
accurate
results in 30 seconds, the client could display some useful feedback, as
an
example. 

Finally, most measurement systems have a time/accuracy tradeoff,
especially
if the target is not moving.  The longer you wait, the more accurate the
measurement.  If the measurement mechanism is triggered, you restart the
time/accuracy clock.  So, asking for a measurement with a timeout would
not
allow you to use a triggered measurement with a time/accuracy tradeoff.
The
client doesn't understand that if it either lengthened the time, or
lengthened the time between requests, it would get more accuracy.  If we
were trying to get both sides to do something optimal, the server would
tell
the client that retriggering resets the time/accuracy tradeoff, and it
would
tell the client what the time/accuracy function looked like.

Let me also react to "web servers take seconds".  Sure.  But there are
humans involved.  Protocol mechanisms that take seconds are best done
with
event notification or call back mechanisms.  If you don't do that, you
have
to use threads or polling, or some other ugliness to not block on the
exchange.

Brian

> > The information transmitted is intended only for the person or
entity
> to
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 22 Jul 2007 16:53:54 -0400

Please supply a use case for an L7 Location Configuration Protocol that can
profitably use a scalar.

Brian

> Sent: Sunday, July 22, 2007 2:13 AM

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 22 Jul 2007 17:34:55 -0500

Client advises server that it can wait 5 seconds for a response to be
used in a routing application. Server invokes first higher level of
accuracy calculation (rather than fastest / least accurate). Client
receives more accurate location [than if it had asked for an immediate
response]. Routing application receives a more accurate location than it
may have otherwise. Routing accuracy for the application is therefore
improved.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, 23 July 2007 6:54 AM
To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Please supply a use case for an L7 Location Configuration Protocol that
can
profitably use a scalar.

Brian

> > > I'm probably opening a can of worms with this comment, but I'll
make
> > it
> > > better to specify that the response is needed right away
(presumably
> > for
> > > persons or entities other than the intended recipient is
prohibited.
> > If

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 22 Jul 2007 20:17:55 -0400

No, I want a use case: some application where the client has some notion of
how long it can wait expressed in some kind of scalar.

I can't think of an application where the client has some threshold of
waiting which it has regardless of what the server can do, and it can
usefully construct a value to put in a scalar.

Brian

> Sent: Sunday, July 22, 2007 6:35 PM

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 23 Jul 2007 01:09:18 -0500

Well, that's rubbish. If a VoIP phone sends a request for location, are
you suggesting it will be prepared to wait forever before attempting to
make the call anyway or cancelling the operation or whatever? Perhaps
you've never written client code. It just needs to provide the same, or
lower, time to the location server as the one associated with its
request timeout.

In any case, there's another approach that will give you your desired
semantics and still maintain what I consider to be the essential scalar
parameter.

A response value of zero is essentially meaningless - no result can be
returned in zero time. So, how about the value of zero be given special
semantics. This would be your "right away" semantics - that is, the
location server will return the fastest (and possibly least accurate)
location that it can muster and return that - however long it takes.

How to deal with your other semantic "take as long as you like but get
me the best, most accurate, location that you can muster" is a bit
different.

It's hard to see how to explicitly indicate that but, if the response
time parameter is made optional, then it could be the default semantic
in the case of the response time not being provided.

How does that sound as a compromise?

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, 23 July 2007 10:18 AM
To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

No, I want a use case: some application where the client has some notion
of
how long it can wait expressed in some kind of scalar.

Brian

> > triggered measurement, which has finite, non trivial time to
complete
> a
> > The client, if it really cares, could react to what the server can
do,
> a
> > results in 30 seconds, the client could display some useful
feedback,
> as
> > lengthened the time between requests, it would get more accuracy.
If
> we
> > > in-range base stations (a few seconds), or doing A-GPS (up to,
say,
> 30
> > > If you assume you know everything now and force a binary choice
into
> > > is all anyone ever needs then, at worst, that is what ends up
being
> > put
> > > > privileged material. Any review, retransmission, dissemination
or
> > > other
> > > > use of, or taking of any action in reliance upon this
information
> by

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 11:27:03 -0500

Hi Barbara,

Thanks for your comments. Responses embedded below [MB]. There are a few
questions embedded below soliciting additional feedback from WG/L7 LCP
doc editors. 

Mary

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 2:36 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: HELD Comment on terminology and semantics

This comment also affects the L7 LCP requirements, since that's where
some of the terminology comes from.
[MB] And, unfortunately, some of the unconsistencies in terminology also
come from RFC 3693, which I do agree from your later points, we can't
change that at this point, but it does add confusion to the overall
terminology problem (the terminology originally caused me alot of grief
when I tookover this document and it's the reason I added the notes
where the definitions/usage in this doc differ from those in the other
docs. [MB]

L7 LCP never defined the term, but I guess it sort of implied the same
thing, by inheriting the term from geopriv requirements.
[MB] I do agree that the L7 LCP Requirements doc (I'm assuming that's
what you're referring to)relied on the definition of Access Provider
defined in RFC 3693.   [/MB]

[MB] That suggestion sounds reasonable to me.  Does anyone have an issue
with this suggestion?
[/MB]

In LCS definition, delete "Provider's".
[MB] Per Hannes' comment, the LCS definition will be deleted from this
doc and we'll rely on the definition in the L7 LCP req doc. [/MB]

[MB] Agreed.[/MB]

[MB] Agreed. [/MB]

[MB] Agreed. [/MB]

I think if L7 LCP removed the word "Provider" from sections 1 through 3,
that it would also be good.
[MB] Hannes/Henning: What do you think? [MB]

[MB] I'll make all the above changes in the -02.[/MB]

Barbara

*****

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Jul 2007 14:51:06 -0400

I don't wish to be obstinate, or obstructionist.

I'm simply asking for a use case.  I can't think of one.

I get the notion that if you force the issue, the client eventually wants to
give up and get the best location it can.  I think it has GREAT difficulty
in coming up with a numeric limit which has time frames measured in seconds.
I don't know how a client would do that.  

I think the best way forward is to cut, not expand complexity.

Request timeouts are short in code; a point you wish to ignore.  They are
much shorter than 30 seconds.  Most are shorter than a second.  When you
need to wait longer than that, you need to do something complex, like create
a polling loop, or spin off a thread or something.  I know how to write this
kind of code.  Code doesn't block for 30 seconds.  

I don't want a protocol that takes 30 seconds to complete single
request/response cycle.  I don't think code is written that way.  I want an
event or call back mechanism for that.  If all I got was effectively, "now",
that is enough.  We need a mechanism that does event notification or call
back for updates.  Use that if "now" won't work.  In nearly every real
system, "now" always works; it's just that the location information may be
rough (like cell site/sector), the first time you request it.

I think we have two mechanisms: an LCP and a dereference mechanism.  The
dereference mechanism needs a notification or call back.  That is
sufficient.  I'd like to stop there, rather than have a value mechanism with
a call back or event other than dereference.

I propose to eliminate the parameter entirely.  You get an "immediate"
response, a value or a reference.

Brian

> Sent: Monday, July 23, 2007 2:09 AM

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Jul 2007 13:56:29 -0500

Brian,

You have repeatedly stated an arbitrary 30 second I will give up time.
I can see applications saying 20 second best you can give please.
Having the scalar allows you to still achieve what you want, it provides
flexibility for other applications developed by people with far more
imagine than you or I.

If the LIS/LCS knows when the client is likely to give up, then it has
the opportunity to forestall that and fallback. Without it the query
simply fails.

Cheers
James

> Sent: Tuesday, 24 July 2007 4:51 AM
> I get the notion that if you force the issue, the client eventually
wants
> a polling loop, or spin off a thread or something.  I know how to
write
> request/response cycle.  I don't think code is written that way.  I
want
> sufficient.  I'd like to stop there, rather than have a value
mechanism
> > > response]. Routing application receives a more accurate location
than
> > > > response times.  I don't see how a client of the protocol can
make
> > use
> > > > of
> > > > that acknowledged fact.  All of the apps that use location that
I
> > can
> > > > think
> > > > of only can use "now" or "when it's good", as long as they can
give
> > up
> > > > The characteristic of GPS is that there is a significant start
up
> > > time,
> > > > When there is a delay for an accurate measurement, the server
knows
> > > what
> > > > reasonably optimal, we'd have the server tell the client what it
can
> > > > the server would have some way to tell the client what it could
do,
> > > > the server can't actually react; all it can do is do what it
does,
> > and
> > > > drop
> > > > some kind of response when the timer expires.  Actually, in
nearly
> > > every
> > > > case, it can predict what happens, but that doesn't help the
client
> > > any.
> > > > if the target is not moving.  The longer you wait, the more
accurate
> > > the
> > > > measurement.  If the measurement mechanism is triggered, you
restart
> > > the
> > > > time/accuracy clock.  So, asking for a measurement with a
timeout
> > > > were trying to get both sides to do something optimal, the
server
> > > would
> > > > tell
> > > > the client that retriggering resets the time/accuracy tradeoff,
and
> > > > Let me also react to "web servers take seconds".  Sure.  But
there
> > are
> > > > event notification or call back mechanisms.  If you don't do
that,
> > you
> > > > have
> > > > to use threads or polling, or some other ugliness to not block
on
> > > > > I think the fact that you feel the need to quantify "right
away"
> > > > > means zero wait and "I'll wait" is any time up to infinity.
The
> > > > > cell directly to a nominal area of coverage (msec), putting
the
> > > device
> > > > > into soft handoff to collect a set of round-trip time
measurements
> > > > from
> > > > > The cell-based location may be adequate for accurate PSAP
routing
> > > 67%
> > > > > response might say "oh - if I'd known I could have had the
result
> > in
> > > > > (scalar) accuracy requirement to go along with the QoS. The
latter
> > > has
> > > > > support a scalar response time and it turns out that 100msec
and
> > > 30sec
> > > > > I have a really hard time coming up with a use case where you
have
> > a
> > > > > value,
> > > > > and not knowing anything about what the other end can do, I
think
> > a
> > > > > value is
> > > > > pretty useless.
> > > > >
> > > > > Please keep in mind that "right away" is order of milliseconds
and
> > > > "I'll
> > > > > wait" can be 30 sec give or take for a typical assisted GPS
start
> > > up,
> > > > > request/response territory.  Anything that has tens of seconds
or
> > > more
> > > > > > useful/meaningful to specify a desired response time, or
whether
> > > > it's
> > > > > > routing purposes) or the device can wait a little to get a
more
> > > > > precise
> > > > > > which it is addressed and may contain confidential,
proprietary,
> > > > > and/or
> > > > > > you received this in error, please contact the sender and
delete

---

From: "Richard Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 14:03:15 -0500

Maybe the disconnect is this: In other protocols, time-outs are fixed
in the standard, not set differently from one transaction to another.
For instance, RFC 3261 sets a whole host of timers to default values,
and says, essentially, "Don't deviate from these defaults unless you
have a really good reason."   I think that HTTP sets similar
time-outs.

The question is, why should HELD behave differently?

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Jul 2007 14:06:03 -0500

Brian,

Further to this.

> response, a value or a reference.

[AJW] This is extremely short-sighted and implies that I can never
request an accurate location from the local access network that requires
calculation except through a SIP subscription. Please read the charter,
we are not interested in only SIP solutions. I fundamentally oppose your
suggestion here, simply because you don't want it does not mean that
there is no valid use case and that the mechanism is not useful.

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Jul 2007 14:10:44 -0500

Hi Richard,

I think you are mixing transport timeouts with application timeouts.
If I bind an application protocol to a different transport I will still
want the application timeouts to be the same, and these may be shorter
than what the transport protocol allows as its maximum.

Cheers
James

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Tuesday, 24 July 2007 5:03 AM
> To: Winterbottom, James
> Cc: Brian Rosen; Dawson, Martin; Stark, Barbara; Mary Barnes;
> [email-masked]
> Subject: Re: [Geopriv] HELD comment on responseTime parameter
> 
> > > in coming up with a numeric limit which has time frames measured
in
> > > Request timeouts are short in code; a point you wish to ignore.
They
> > are
> > > much shorter than 30 seconds.  Most are shorter than a second.
When
> > you
> > > need to wait longer than that, you need to do something complex,
like
> > > create
> > > event or call back mechanism for that.  If all I got was
effectively,
> > > "now",
> > > that is enough.  We need a mechanism that does event notification
or
> > call
> > > system, "now" always works; it's just that the location
information
> > may be
> > > I think we have two mechanisms: an LCP and a dereference
mechanism.
> > > > Well, that's rubbish. If a VoIP phone sends a request for
location,
> > are
> > > > you suggesting it will be prepared to wait forever before
attempting
> > > > you've never written client code. It just needs to provide the
same,
> > > > A response value of zero is essentially meaningless - no result
can
> > be
> > > > How to deal with your other semantic "take as long as you like
but
> > get
> > > > No, I want a use case: some application where the client has
some
> > notion
> > > > I can't think of an application where the client has some
threshold
> > of
> > > > waiting which it has regardless of what the server can do, and
it
> > > > > Client advises server that it can wait 5 seconds for a
response to
> > be
> > > > > used in a routing application. Server invokes first higher
level
> > > > > Please supply a use case for an L7 Location Configuration
Protocol
> > > > that
> > > > > > All the client has to know is how long it is prepared to
wait
> > for a
> > > > > > I'm having difficulty figuring out how any application can
use
> > any
> > > > > > parameters.  Whether "when it's good" is 5 seconds, 15
seconds,
> > > > > > I understand that the methods for measurement are varied,
and
> > > > > > If we were trying to more closely match what actually
happens
> > with
> > > > > > measurement based location determination, or which GPS is
the
> > > > easiest
> > > > > > example to work with, we would have the protocol deal with
start
> > > > > > Most triangulation mechanisms have some kind of start up,
most
> > have
> > > > > > updates
> > > > > > equivalent to "now", but some don't (some triangulation
really
> > is a
> > > > > > time to complete a measurement, there can be intermediate,
less
> > > > > > The client, if it really cares, could react to what the
server
> > can
> > > > do,
> > > > > a
> > > > > > lot
> > > > > > more usefully than having the server react to what the
client is
> > > > > asking
> > > > > > for.
> > > > > > If the server tells it that it has a startup problem, and
will
> > > > > > allow you to use a triggered measurement with a
time/accuracy
> > > > > tradeoff.
> > > > > > The
> > > > > > client doesn't understand that if it either lengthened the
time,
> > > > > > humans involved.  Protocol mechanisms that take seconds are
best
> > > > done
> > > > > > > you "prescribe" are based on your here/now understanding
and
> > > > > > presumption
> > > > > > > Requesting location in a WCDMA UTRAN can involve relating
the
> > > > > serving
> > > > > > > while RTT may be accurate 99.9% of time. Other
applications
> > will
> > > > > > > similarly be sensitive to accuracy variations. Tolerance
for
> > > > > response
> > > > > > > delays isn't something you can claim to be able to predict
for
> > all
> > > > > > > It's no good saying that an application that asked for a
four
> > > > second
> > > > > > > five seconds, I'd have been OK to wait." If it is OK to
wait
> > five
> > > > > > > seconds, then it should request a response time of at
least
> > five
> > > > > > > seconds.
> > > > > > >
> > > > > > > As we've explained before, our experience has shown that
the
> > > > > Low-delay
> > > > > > > or Delay-tolerant choices that the 3GPP protocols provide
have
> > > > been
> > > > > > > techniques and order of fallback. With just a binary
response
> > time
> > > > > > > semantics, then you can't undo that if it's a mistake. If
the
> > > > > > semantics
> > > > > > > As you know, I am in the binary "gimme what you got now,
gotta
> > > > route
> > > > > > > > I'm probably opening a can of worms with this comment,
but
> > I'll
> > > > > > > > The information transmitted is intended only for the
person
> ------------------------
> ------------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 23 Jul 2007 14:13:14 -0500

Brian,

My use case is every application which involves making a request for
location. Every client will have a maximum time it is prepared to wait.
It knows that time itself - it can pass it to the application.

If a client says it can wait 5 seconds and the server only has a 200msec
technology and a 30 second technology, then the client will get a result
in 200msec. The response time is not governed totally by the response
time parameter as you seem to think.

I don't think your understanding of client implementation issues and
approaches is accurate at all.

Your approach eliminates, forever, any ability for a device to obtain an
accurate location by value from a HELD server. This is very unfair to
future users of the protocol.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 24 July 2007 4:51 AM
To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

I get the notion that if you force the issue, the client eventually
wants to
give up and get the best location it can.  I think it has GREAT
difficulty
in coming up with a numeric limit which has time frames measured in
seconds.
I don't know how a client would do that.  

Request timeouts are short in code; a point you wish to ignore.  They
are
much shorter than 30 seconds.  Most are shorter than a second.  When you
need to wait longer than that, you need to do something complex, like
create
a polling loop, or spin off a thread or something.  I know how to write
this
kind of code.  Code doesn't block for 30 seconds.  

I don't want a protocol that takes 30 seconds to complete single
request/response cycle.  I don't think code is written that way.  I want
an
event or call back mechanism for that.  If all I got was effectively,
"now",
that is enough.  We need a mechanism that does event notification or
call
back for updates.  Use that if "now" won't work.  In nearly every real
system, "now" always works; it's just that the location information may
be
rough (like cell site/sector), the first time you request it.

I think we have two mechanisms: an LCP and a dereference mechanism.  The
dereference mechanism needs a notification or call back.  That is
sufficient.  I'd like to stop there, rather than have a value mechanism
with
a call back or event other than dereference.

Brian

than
give
knows
can
do,
client
accurate
restart
and
measurements
routing
result
latter
have
think
and
start
or
whether
more
proprietary,
delete

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Jul 2007 15:15:46 -0400

If you want a programmatic way to get a value that can take multiple seconds
(5, 10, 15, 30, 60 or 180), then you need an event or call-back mechanism.

It doesn't have to be a SIP mechanism, but it has to be something that
doesn't cause a thread block for multiple seconds.  It's just good protocol
design.  You have a simple request/response where the response can be a very
long time.  That's bad design.

Brian

> Sent: Monday, July 23, 2007 3:06 PM
> To: Brian Rosen; Dawson, Martin; Stark, Barbara; Mary Barnes;
> [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Jul 2007 14:24:52 -0500

Well I guess as is so commonly the case I just don't agree with you.

I see a lot of value in this parameter and I also see that if we do as
you suggest we will be back in a year putting it back in again.

I think that Martin's compromise of suggesting we change the default
behaviour of the parameter, if it is not there or set to zero then you
get an immediate response satisfies your position. If people set it and
choose to use it, as I expect they will, then different types of
determination mechanisms can be invoked correctly.

Cheers
James

> Sent: Tuesday, 24 July 2007 5:16 AM
> To: Winterbottom, James; Dawson, Martin; 'Stark, Barbara'; 'Mary
Barnes';
> design.  You have a simple request/response where the response can be
a
> very

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 23 Jul 2007 14:39:12 -0500

Suffice to say, I disagree with this completely, and these sorts of
implementations are quite common without having to force SIP into the
picture. What is the client supposed to do with its time while it's
waiting for a notification? There's absolutely nothing achieved by
forcing this complexity on the protocols that can't be achieved by quite
common client programming techniques.

I honestly don't know why you have to make this difficult. I offered a
way to support your desired semantics. The cream, as they say, will rise
to the top eventually.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 24 July 2007 5:16 AM
To: Winterbottom, James; Dawson, Martin; 'Stark, Barbara'; 'Mary
Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

If you want a programmatic way to get a value that can take multiple
seconds
(5, 10, 15, 30, 60 or 180), then you need an event or call-back
mechanism.

It doesn't have to be a SIP mechanism, but it has to be something that
doesn't cause a thread block for multiple seconds.  It's just good
protocol
design.  You have a simple request/response where the response can be a
very
long time.  That's bad design.

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 23 Jul 2007 14:55:11 -0500

Hi Richard,

There definitely are protocols that allow the client to prescribe a
response time. With particular respect to the location domain, RRLP
allows the location server to tell the device how long it should spend
obtaining a GPS fix or taking EOTD measurements. At the RRLP layer, the
location server is the client peer and the device is the server. The
Quality of Position (QoP) parameter in SUPL includes a quantified value
for the desire response time.

When an application is using a lower layer network protocol then, yes,
it wants those lower layers to provide some standard level of
service/response/reliability. In the case of peer entities exchanging
application level information, something like a response time parameter
is quite reasonable.

If this is the basis for the disconnect, it is exactly that it is not
being recognized that this is an application and not a transport/session
layer consideration.

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, 24 July 2007 5:03 AM
To: Winterbottom, James
Cc: Brian Rosen; Dawson, Martin; Stark, Barbara; Mary Barnes;
[email-masked]

--Richard

They
like
effectively,
location,
attempting
same,
can
threshold
> > > > Client advises server that it can wait 5 seconds for a response
to
Protocol
seconds,
start
less
> > > > > more usefully than having the server react to what the client
is
time,
best
the
for
four
have
response
the
gotta
person

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 23 Jul 2007 16:19:43 -0400

Unfortunately, the devices I specify only "know" what I tell them. So if
I need for a client to know how long to wait for something, then I have
to define the algorithm, rules, and timeouts. I understand that there
exists some desire to keep HELD flexible in this area, and I'm not in a
position to say whether or not that's true. So, here is my suggestion:

Currently the responseTime is optional, with a default of "the most
precise LI it [the server] is capable of determining". I would like to
keep it as optional, with a default of "the quickest LI it is capable of
determining".

If we change it this way, then I get the following behaviors, with a
simple device rule (for my devices) of "don't specify responseTime":
1. If the server is doing location hiding, then it's always giving
either LbyR or LbyR + coarse LbyV. Both of these should be quick, and
neither should have a time dependency. So devices that don't specify
responseTime are fine.
2. If the network knows it's wireless (of some sort), and doesn't do
hiding, the server can still choose to send a LbyR. Then Brian can be
happy, because the reference can be of the subscribe/notify ilk.
3. If the network knows it's wired, and doesn't do hiding, it can send
the value. Whether or not the device specifies a responseTime, the value
will always be the same. So, the simple rule of "don't specify
responseTime" works. 
4. If a mobile device (built in radio, so it knows it's a mobile device)
gets a value, then the simple rule breaks down when the device wants its
precise location. This means that I'll probably specify something like
60 seconds (or 300 seconds ?) for a mobile device to use to get it's
precise location. It doesn't matter how big the number is, so long as
it's big enough to let the server do its thing. Since I get to recommend
server specs, in addition to device specs, I'll recommend servers on
wireless networks return LbyR. Then this case won't be prevalent.
5. If a device thinks it's fixed, but is actually mobile, and it gets a
value, then there's a real problem, because the device will be satisfied
with the "quick" response. This also leads me to recommend that servers
on wireless networks provide LbyR.

If we leave the default as is, then it makes my rules more difficult for
the case where the device is given a value; but only when launching an
emergency call. When launching an emergency call in this case, the
device would need to specify the responseTime, and have some default
time specified that would indicate to the server to give it the quickest
possible response. I prefer not to introduce the complexity at the time
of the call. 

So, I'm fine with the responseTime being a time, if we change the
default to "quickest".
I can achieve the same effect as Brian is proposing (which is simple),
but leave the responseTime as a time value (which provides flexibility
for whatever may come).
Barbara

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 3:13 PM
To: Brian Rosen; Stark, Barbara; Mary Barnes; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Brian,

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 24 July 2007 4:51 AM
To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Brian

than
give
knows
can
do,
client
accurate
restart
and
measurements
routing
result
latter
have
think
and
start
or
whether
more
proprietary,
delete

*****

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 23 Jul 2007 15:49:12 -0500

Hi Barbara,

I don't like to conflate the idea of doing LbyR with the idea of
expressing a response time. I don't think it should be necessary to
prescribe LbyR based on the type of access network. Some applications
will want location by value for an instantaneous fix of whatever
accuracy. This also shouldn't be conflated with location hiding. Perhaps
a network will only offer LbyR anyway, but that should also be an
independent decision.

Taking the examples that you described; if a device made a request with
a 10 second response time and it was on a wireline network with only one
possible result, then the result will come back immediately. If the
device makes the same request on a mobile network with three positioning
technologies (a .1 second, a 5 second, and a 30 second technology) then
the result will come back in five seconds. It will be more accurate than
the .1 second result - but it's not going to hang about for 10 seconds
for no good reason.

I think all you have to tell your device is how long it should be
prepared to wait for a response. The device doesn't have to care about
the algorithms and rules. The response time just gives the location
server the ability to provide an optimal result. The device didn't have
to know it was on a wireline network or wireless network. The speed with
which results come back is exactly the same as if it did - but it wasn't
necessary for the device to know anything a priori for that to happen.
In practice, how long the device is prepared to wait should depend on
the application as opposed to always being the same for every location
request the device makes.

As an aside, Brian's classic "WiFi access point in an RV" scenario has
an explicit real life example these days. I noticed when I picked up my
rental on Thursday that Avis now allow you to hire an Internet access
point for $11 a day. You can throw it in your car and use it while
driving, you can take it into the pub with you, and you can take it into
meetings with you. It's obviously just one of those router/gateways that
allows you to plug a 3G modem in (as opposed to a DSL or cable
connection) and I don't know which wireless carrier Avis are using
behind the box. However, it emphasises that a client device (my PDA or
laptop) cannot assume anything about the nature of the access network it
is really connected to. What looks like a pedestrian 802.11 access point
can actually be completely mobile wireless network.

http://www.geekytraveller.com/avis-offers-portable-wifi-with-car-rental/

Cheers,
Martin

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 3:13 PM
To: Brian Rosen; Stark, Barbara; Mary Barnes; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Brian,

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 24 July 2007 4:51 AM
To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Brian

than
give
knows
can
do,
client
accurate
restart
and
measurements
routing
result
latter
have
think
and
start
or
whether
more
proprietary,
delete

*****

material from all computers. GA625

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 16:01:03 -0500

Agreed.

Mary

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 1:19 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: HELD Comment on mandatory locationType

Barbara

*****

---

From: "Richard Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 16:18:32 -0500

Doesn't this then raise the question of whether time-out of requests
is a "transport layer" issue (where, from the perspective of HELD, the
transport layer includes HTTP and SIP).  If you're getting location
from a SIP subscription, we already know how to set the response time.
 I think there are mechanisms for varying the HTTP time-out as well.

Why do this at a higher layer as well?

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 23 Jul 2007 17:08:10 -0500

Because the application layer semantics are specifically for a client to
tell the location server how quickly it wants a location fix. It's a
layer violation to use HTTP timers for this. I don't know what the
default response time for HTTP is but based on how long browsers
typically hang around waiting for a response, it's a long time. I think
a location client wants immediate control over the location service
response time and not to rely on the artefacts of an underlying
transport protocol.

Cheers,
Martin 

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, 24 July 2007 7:19 AM
To: Winterbottom, James
Cc: Brian Rosen; Dawson, Martin; Stark, Barbara; Mary Barnes;
[email-masked]

--Richard

On 7/23/07, Winterbottom, James <[email-masked]> wrote:
> > > > back for updates.  Use that if "now" won't work.  In nearly
every
> real
> > > > > semantics and still maintain what I consider to be the
essential
> > > scalar
> > > > > returned in zero time. So, how about the value of zero be
given
> > > special
> > > > > semantics. This would be your "right away" semantics - that
is,
> > > > > > > or any other value, I still don't see how you can really
use
> it.
> > > > > > > after that, location updates equivalent to "now" is what
you
> > > get.
> > > > > > > delay is.  If we were trying to really get both sides to
do
> > > > > something
> > > > > > > When there is a startup issue, and sometimes when there is
a
> > > > > > significant
> > > > > > > vary much.  Having the client tell the server what it
wants
> > > > > > > > "I'll wait" is revealing in itself. Of course "right
away"
> > > > > literally
> > > > > > > > in-range base stations (a few seconds), or doing A-GPS
(up
> to,
> > > > > > > > is all anyone ever needs then, at worst, that is what
ends
> > > > > > > > I have a really hard time coming up with a use case
where
> you
> > > have
> > > > > a
> > > > > > > > value,
> > > > > > > > and not knowing anything about what the other end can
do,
> > > > > > > > > There have been discussions elsewhere as to whether
it's
> > > > > > > > > routing purposes) or the device can wait a little to
get
> > > > > > > > immediately and delete the original.  Any unauthorized
use

---

From: Richard Barnes <[email-masked]>
Date: Tue, 24 Jul 2007 10:44:36 -0500

- The HTTP timers say how quickly the client wants an HTTP response.
- HELD responses are in 1-1 correspondence with HTTP responses.
* Ergo, the HTTP timers say how quickly the client wants a HELD response.

It's a duplication of functionality to have a timer within HELD when 
there's already a semantically equivalent mechanism in HTTP.

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 12:34:25 -0500

I don't want to draw this out because I think there has been a decision
to move forward with. However, I think it's a classic misunderstanding
of layering to assume that a timer in a lower layer is the semantic
equivalent of one in an upper layer and therefore the application timer
is not necessary.

I would expect, for example, that the HTTP timer would be for
contingency purposes and would remain the same for each HTTP
transaction. Within the location request semantics I would expect the
location acquisition protocol to be used to vary the required response
time for the location request depending on the purpose that specific
request.

HELD is not bound exclusively to HTTP and should not describe
application level procedures which rely specifically on some function of
HTTP.

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 1:45 AM
To: Dawson, Martin
Cc: Richard Barnes; Winterbottom, James; [email-masked]; Mary Barnes
Subject: Re: [Geopriv] HELD comment on responseTime parameter

- The HTTP timers say how quickly the client wants an HTTP response.
- HELD responses are in 1-1 correspondence with HTTP responses.
* Ergo, the HTTP timers say how quickly the client wants a HELD
response.

--Richard

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 16:20:13 -0400

Hi Mary, Hi geopriv,

Please find below a few comments after reviewing this document. They are tagged as "Editorial" or "Technical".

>From a general point of view, I think the basic functions for location acquisition are well captured with this draft.

Since a lot of the comments have been provided already by other reviewers, my list is rather short.

Note well: My comments are influenced by the nature of my interests: Emergency services.

Section by section comments:

Abstract:
c1. <Editorial> The last sentence doesn't read right. Either add "the" before "session-layer" or an "s" at "layer". I would replace the semi-colon by a period after "layer".

Section 7 - Protocol Paramaters
c2. <Technical> Table 1: The "expires" parameter should be labeled "conditional" instead of "mandatory" as it is only relevant in presence of the LocationURI parameter. If accepted, the term "conditional" should be added to the paragraph just above the table.

Section 7.1 - "responseTime" Parameter
c3. <Editorial> 1st para., 1st sentence: Replace "attribute" by "parameter".

c4. <Editorial> "If this parameter is absent, then the LCS MUST return the most precise LI it is capable of determining". I find this statement a bit confusing. Should I read this as, when the parameter is absent, the LCS will provide the most precise LI available at this very moment (not waiting for any LI computing at all) so possibly a coarse location? This is what I want but I'm not sure the text exactly says that (it may be completely the reverse actually).

Section 7.2.1 - "exact" Attribute
My assumption here is that the device does not have prior knowledge of which application the LI will be eventually used for.

c5. <Technical> Should a statement be added to cover the following case: When only one specific LocationType is requested (exact=true), the LCS SHOULD return location information in THE form that is suited for routing and responding to an emergency call in its jurisdiction even if different than the one requested?

Alternatively, should a caveat be added to the use of this attribute stating it could impede the routing of emergency calls?

Section 7.3 - "code" Parameter
c6. <Editorial> 2nd par., 1st sentence: I suggest replacing "error" by "code". This would allow including "success" in the list of valid responses (success is not an error code).

The assumption for my comments in this section hereinafter is that all defined error codes will result in no LI being provided to the Device.

c7. <Technical> Should the timeout error code by accompanied with an "expected time" for a successful response?

What I would like to avoid is having a Device location-less when this information is required for emergency situations.

c8. <Technical> Considering comment #c5 above, would it be seen helpful to have the cannotProvideLiType error response by accompanied with a list of available LocationType(s)? At least, this would give a hint to the device as to what to do next.

Section 9 - HTTP Binding
c9. <Technical> "This binding MUST use TLS...".Shall I risk asking to soften this requirement a bit to a "RECOMMEND"? My motivation is that, under very specific implementation of trusted network nodes and private, secure network links, TLS may not be required. Consider an Enterprise running its LCS over its private LAN. Here is suggested wording: "This binding MUST use a secure mean of transporting data between the endpoint and the LCS. The use TLS is RECOMMENDED."

Section 10.2 - Transaction Layer Security
c10. <Technical> Same comment as #c9 above for the HTTP binding.

Section Appendix A - HELD Compliance to IETF LCP requirements
c11. <Editorial> The whole appendix seems to refer to an older version of the LCP requirements document (prior to -02). The requirements' text should be updated.

That's it.

Best regards!

Guy Caron

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : 12 juillet 2007 13:17
À : [email-masked]
Cc : [email-masked]
Objet : [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-01.txt 

	

Send a message to:
	[email-masked].
In the body type:

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 12:22:25 +0200

I'll add to the discussion that relying on long-delayed HTTP responses 
is unwise in the presence of NATs. I've seen hotel NATs that time out 
TCP state after 30 seconds of inactivity.

I think the semantics of this are sufficiently ill-defined that this 
seems like a good candidate for a protocol extension. It will only be 
relevant for some subset of location technologies in any event.

I hope we would agree that neither client nor server would have to 
insert or observe such a parameter.

It might also be more useful to have some indication in the protocol 
that says something along the lines of "this information is preliminary; 
if you ask again in a minute, I'll have better data available".

Like Brian, I have no clue what value a client can usefully specify, 
beyond "I need it NOW" (since I'm dialing 9-1-1 right now and just 
turned on the phone) and "give me the best you got, however long it 
takes" (since I'm just turning on the phone and want to do a pre-need 
LoST mapping).

If anything, a client cares about the available accuracy, as in "give me 
at least 100 m accuracy since anything less isn't useful to me" (and 
take whatever time you need). After all, timing out with continent-level 
accuracy after 10 seconds is not terribly useful for pizza delivery or 
emergency calls, particularly if the client has no clue whether waiting 
for 11 seconds will yield a street-precise location or not. It also 
doesn't tell the client whether asking again later will yield better 
accuracy or not.

Thus, we should think about how a client can ask for information that is 
useful to it. A timing parameter may not be that way. As noted, this can 
be done at a later stage.

Henning

Richard Barnes wrote:
>> From: Richard Barnes [mailto:[email-masked]] Sent: Tuesday, 
>> 24 July 2007 7:19 AM
>> To: Winterbottom, James
>> contain privileged, proprietary, or otherwise private information.  If 
>> you have received it in error, please notify the sender

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 30 Jul 2007 06:50:32 -0500

I think the point is still being missed - and the assumption seems to be
that this is a client-focussed parameter. It is not the client that
makes use of this information; it is the server. Particularly in
wireless access networks where a location server may have multiple
technologies available to it, there is a general need to trade off
response time and accuracy. Accept that there are "n" techniques and
that "n" can be more than two. The parameter allows the server to
provide an optimal accuracy in response to a location request by giving
it an understanding of how long the client is prepared to wait.

It's no good assuming that a response now with some (asynchronous?)
update later is adequate. In scenarios where a device wants a location
value so it can send it to an application for immediate processing by
that application, there is no use for "subsequent" values. That's why
I'm puzzled by the request for "use cases" for this parameter - it's
applicable to every use case for location requests. The location server
can't assume anything about what is going to be useful to the client
"later".

Not having a scalar response time criterion means that the server can
never optimize the accuracy using the most suitable available
technologies. How does anyone propose that a HELD server select the
optimal positioning technology for a one-off request without some
understanding of how long the client is prepared to wait?

Experience has shown that an accuracy requirement parameter is not so
useful. Applications generally want the most accurate location they can
get within the timeframe that they are prepared to wait. The accuracy is
actually part of the result - embodied in the provided uncertainty
information. There's no guarantee about how accurately an arbitrary
server can locate a target. Also, when it comes to civic location,
there's a semantic mismatch with respect to scalar accuracy.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, 30 July 2007 8:22 PM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [Geopriv] HELD comment on responseTime parameter

Henning

response.

If

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 19:14:29 +0200

I think the basic disconnect is that I'm assuming that we should design 
the protocol to be most useful to the client and that I cannot imagine 
how a client can usefully pick a time value beyond "immediately" 
(meaning within the 1-2 second post-dial delay margin available during a 
call setup) or "whenever" (within a reasonable time of, say, a minute or 
two). I know no client application that somehow can wait 10 seconds, but 
not 11 seconds, particularly if the answer it can get in 10 seconds is 
useless for its application. In that case, it has just "wasted" 10 
seconds and has to guess whether trying again with 11 or 15 or 20 
seconds will yield any improvement or whether this is pointless.

Post-dial applications need answers immediately, and dispatch 
applications probably want updates, so that they can provide better 
estimates after they have started the dispatch process. (However, for 
dispatch, I'm having a hard time envisioning that this really matters. 
The realistic time frame to determine the nature of the emergency is 
probably on the same order, a few minutes, as the maximum probable 
location determination time, unless we're talking about asking the 
caller to get out their chronometer and sextant.)

The pre-call case also has no natural time limit, beyond "as accurately 
as possible".

Since a client has no clue what the time-resolution function is, it 
essentially has to pick an arbitrary time value. It has no idea whether 
there are steps in that time-resolution function, so that waiting a 
second longer gets much better accuracy. It has no idea whether asking 
again with a slightly longer interval will improve the result.

I generally find "experience has shown" arguments of the 
argument-by-authority kind and thus not particularly helpful. We know 
that there are several discrete location resolutions that are useful, 
namely the "sufficient to do LoST routing" and "sufficient to do 
dispatch". A client doesn't need exactly N meters of accuracy.

The likely outcome will be that clients will specify 0 and some 
approximation of infinity as values, with the danger that requests will 
fail if 0 is taken as something other than "whatever you can do 
immediately". Or client implementors will "learn" that specifying 5 
seconds will get reasonable results most of the time in the network they 
tested with. None of this is useful.

I don't know of any incremental-resolution technique for civic 
locations, so I suspect it's more productive to focus on geo to keep the 
problem manageable.

The basic model for protocol design is not to have to prove why 
something is NOT useful, but that a particular mechanism is the least 
complicated and most appropriate solution for a clearly stated 
requirement. I know of no requirement that says that a client has a 
specific time limit beyond the "immediate" value; we do know that 
clients have different rough accuracy requirements.

Henning

---

From: "Stuard, Doug" <[email-masked]>
Date: Mon, 30 Jul 2007 15:06:17 -0400

For commercial applications, I don't disagree, as the client (user)
generally has little idea about what a reasonable cut off (i.e., the "I
give up") time is for a given request, or what the trade-offs are.
That's like trying to decide if you should take one more pull on the
slots in Vegas.

For emergency service applications however, the client ultimately is the
PSAP which IS knowledgeable about what a reasonable threshold is (the
famous 30 second window) and the accuracy that can be expected within
that threshold (This is where the "experience has shown" factor comes
in).  In addition, if the threshold time is exceeded, a re-bid can
effectively extend it if needed (and need is frequently situational and
not automatic). (Well, maybe - currently a re-bid re-starts the location
process rather than extending it.  Probably reasonable for tracking
moving targets - see below).

"As soon as possible" thus translates to "quick and accurate enough for
proper call routing", while  "As accurate as possible" translates to
"accurate enough for dispatch purposes - up to a point".  Waiting
another 2 minutes to decrease uncertainty from 150 meters to 10 meters
is past the point of diminishing returns, in my view.

While a client may specify "zero" at one end of the spectrum (and
actually get something in the order of seconds - certainly "pretty
quick" in human terms), I disagree that from a practical standpoint
"infinity" is the other end (whether in geological or human terms).
That would be the equivalent of "I'll call you back sometime".  The
outside limit is of course situational, ranging from 30 seconds for
emergency services to perhaps 2 or 3 minutes (and certainly within the
length of the typical telephone call) for commercial applications ("All
agents are busy helping other customers. Your expected wait time
is...").  

None of this applies to determining civic location, of course (it is
what it is), provided that validation, routing and display can be
provided for timely emergency dispatch.

Doug

> Sent: Monday, July 30, 2007 1:14 PM
> To: Dawson, Martin
> Cc: [email-masked]
> > I think the point is still being missed - and the assumption seems
to
> > get within the timeframe that they are prepared to wait. The
accuracy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 21:31:24 +0200

As far as I understand our discussions here, HELD is used by the end 
system ("phone") or possibly a local (ISP-run) SIP proxy, not, in 
general, the PSAP. (We've had long discussions about authentication and 
privacy related to that, which I'd rather not repeat.)

We seem to at least agree that it is useless for that end system client.

It is also not clear how the timing and rebid are related. This is 
another problem with the timing model, as it seems to imply some kind of 
back-end state maintenance as well as an implicit method selection. If 
this is to be used by experts in the PSAP, shouldn't they just ask for 
the location determination method directly and avoid the rather indirect 
method of getting a specific location determination method by specifying 
the "right" time-out?

If I ask at time 0 for location for terminal X, does this start some 
kind of background measurement process that I can sample later? (This is 
the re-bid model, in essence.) In other words, to take the GPS example, 
the short timeout request gives the initial, rough 2-satellite GPS fix, 
but it continues to run the GPS receiver, so that a later request 
provides the full N-satellite fix? If so, a "re-bid" is really a new 
request for the current location, i.e., another HELD request. It is not 
a "wait longer for answer" request.

Thus, I fail to see how the "re-bid" in a PSAP has anything to do with 
timers.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Jul 2007 16:37:16 -0400

Actually, no, no, no.

The PSAP is clueless about how long to wait.  The actual circumstance is
unbelievably bad: each carrier responds in a different time, and the PSAP
guesses how long it takes before they press the "rebid" key.  The PSAP wants
exactly what I proposed and Henning suggests: "now" for routing and "when
its ready" for dispatch.  The 30 seconds is the time the longest carrier
takes, not what the PSAP wants.  Current rebid is horribly broken because on
some systems if you rebid too early, it starts a measurement cycle over
again, effectively delaying when a location can be determined.

There is, of course, some absolute limit, after which dispatch must be
completed.  This time depends on how the call goes, and is not known in
advance.  For optimal use with a PSAP, you would like:
1. A near-immediate response for routing
2. A call back or event mechanism which gave you an accurate result when it
was ready, with a cancel-and-give-me-what-you-have-I-gotta-send-the-cops-now
3. A filtered update mechanism engaged when tracking the caller is needed
(happens rarely, but it happens).

Brian

> From: Stuard, Doug [mailto:[email-masked]]
> Sent: Monday, July 30, 2007 3:06 PM
> To: Henning Schulzrinne; Dawson, Martin
> Cc: [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 30 Jul 2007 17:32:01 -0500

So you would suggest that a client requesting location would timeout and
cancel the request if the response did not arrive in zero seconds?

My point is that clients, for any request use case, need to know how
long they are prepared to wait for a result. These semantics just
provide that information to the server. More information for the server
is better.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, 31 July 2007 3:14 AM
To: Dawson, Martin
Cc: Richard Barnes; [email-masked]
Subject: Re: [Geopriv] HELD comment on responseTime parameter

problem manageable.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 30 Jul 2007 17:44:39 -0500

The typical call flow for cellular has the MSC asking the location
server for a low-delay response. It wants the result quickly, first and
foremost, because it has to get on with routing the call (or if it does
cell-based routing, so that a location is available to the ALI as soon
as possible after the call is set up).

Based on this low-delay requirement, the location server has to invoke
an appropriate technology.

When a PSAP bids for an updated location, the request makes its way
through the network to the location server with a delay-tolerant QoS.
This tells the location server that it can spend more time getting a
more accurate location.

In both cases, it is the client (the MSC or the PSAP) which informs the
location server how long it is prepared to wait and, therefore, how long
the location server can dedicate to the location determination process.
None of this places an undue, or even surprising, demand on the client.

The problem, in 3GPP, has been that the simple low-delay and
delay-tolerant guidance do not allow the location server to be very
sophisticated in its choice of technologies. Different PSAPs can have
different policies with respect to how long they are prepared to wait.
Cellular carriers currently are forced into a "one size fits all" when
it comes to applying positioning methods to these PSAPs. A scalar
response parameter would actually allow PSAPs to make their own
judgements about performance trade-offs.

Just using low-delay and delay-tolerant don't actually make things
simpler - the location server has to be configured so that these
correspond to some hard time-limit. The nice fuzziness has to be thrown
out the window when it gets down to the hard facts of implementation.

You may regard the voice of experience as a mere rhetorical appeal to
authority but I'd also like to think that we are capable of learning
from the experience gained in other domains to make sure our
specifications are the best they can be.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, 31 July 2007 5:31 AM
To: Stuard, Doug
Cc: [email-masked]
Subject: Re: [Geopriv] HELD comment on responseTime parameter

the "right" time-out?

Henning

Stuard, Doug wrote:
>> (meaning within the 1-2 second post-dial delay margin available
during

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Jul 2007 20:04:36 -0400

I know, I'm feeding the troll.  I can't help myself.

Martin:  Please don't keep repeating this incorrect statement.  The PSAP
bids for location blindly; not having a clue what the server will do because
the current system is stupid.  The PSAP wants the location in zero seconds,
and, with current systems, it guesses how long to wait for the server to be
ready.  You are describing the situation completely opposite from reality.
The carriers each have some time period when accurate location is available,
they don't tell the PSAP, and it guesses, based on the carrier, when to ask
for location.  The guess is based on the call taker's experience as to the
soonest the location is available from that carrier, and has nothing
whatsoever to do with how long the PSAP can wait.

The PSAP itself doesn't ask for location for routing, but we all agree what
the routing element wants is "now".  We don't have to repeat that to each
other.

The PSAP wants location when it's ready.  It doesn't know when that it.  The
server does.

The reality is that the location technology has a reasonable upper end for
the accuracy required from cold start, and it's on the order of 30 seconds
presently.  For emergencies, there is no need to say that.  It's only
applicable for the first accurate fix in the emergency case.  If there is an
update after that, it's tracking, and they want updates based on movement
and not time.

The PSAP doesn't know, when it asks, how long it can wait.  That depends on
what the caller says.  If the caller says "bomb", the tolerance is around 1
second.  If the caller says "I lost my Mommy", it might be a few minutes.
Generally, it wants the location AS SOON AS IT CAN GET IT.  If you ask it,
it will say "zero seconds, please, or as soon as you can".  It does NOT have
a real upper limit when it starts the transaction.  There is no meaningful
variability among PSAPs; they all want it as soon as they can get it.  The
only difference between PSAPs today is that some have prevailed upon their
vendors to implement a per-carrier fixed delay for rebid, and some rely on
the skill of their call takers to do it.  None of them, not one that I know,
would stand up and tell you they were prepared to wait 10, 20, 30, 50 or 180
seconds.  That's not how it works.  That's not what they want.  They want it
as soon as they can get it.  Period.

If they had an upper limit, it would be when they start running to the
regulator complaining that the carrier didn't meet the need.

Brian

> Sent: Monday, July 30, 2007 6:45 PM
> To: Henning Schulzrinne; Stuard, Doug
> Cc: [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 30 Jul 2007 19:22:55 -0500

The cellular operators know that they have a fixed amount of time to
respond to the update request. It comes from the ALI and requests
absolutely positively do time out if the response doesn't come back in
the time configured for that PSAP. When timeouts happen, the cellular
operator gets into trouble.

Trying to argue this isn't real because the timeout wasn't explicitly
nominated by the PSAP operator is just being pedantic. I don't
understand how you can even imagine that there aren't timers involved in
the request chain.

It is absolutely the case that a location request gets to the location
server with a delay-tolerant QoS in the case of an update and it is
absolutely the case that the location server has to select a location
technology based on this.

You're living in a fuzzy conceptual world and I'm dealing with hard
implementation issues.

One of the first things that location server operators ask for when they
deal with a vendor is the "PDE selection algorithm". That is, explain
how your system trades off QoS requirements and tell me what control I
have over that. If we don't have support for response time in the HELD
request, I will have to tell operators in the future that they can't
control their PDE selection algorithm properly because the folk in
Geopriv just didn't think they should be able to and, no, I don't know
why it was such a big deal.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 31 July 2007 10:05 AM
To: Dawson, Martin; 'Henning Schulzrinne'; Stuard, Doug
Cc: [email-masked]
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Martin:  Please don't keep repeating this incorrect statement.  The PSAP
bids for location blindly; not having a clue what the server will do
because
the current system is stupid.  The PSAP wants the location in zero
seconds,
and, with current systems, it guesses how long to wait for the server to
be
ready.  You are describing the situation completely opposite from
reality.
The carriers each have some time period when accurate location is
available,
they don't tell the PSAP, and it guesses, based on the carrier, when to
ask
for location.  The guess is based on the call taker's experience as to
the
soonest the location is available from that carrier, and has nothing
whatsoever to do with how long the PSAP can wait.

The PSAP itself doesn't ask for location for routing, but we all agree
what
the routing element wants is "now".  We don't have to repeat that to
each
other.

The PSAP wants location when it's ready.  It doesn't know when that it.
The
server does.

The reality is that the location technology has a reasonable upper end
for
the accuracy required from cold start, and it's on the order of 30
seconds
presently.  For emergencies, there is no need to say that.  It's only
applicable for the first accurate fix in the emergency case.  If there
is an
update after that, it's tracking, and they want updates based on
movement
and not time.

The PSAP doesn't know, when it asks, how long it can wait.  That depends
on
what the caller says.  If the caller says "bomb", the tolerance is
around 1
second.  If the caller says "I lost my Mommy", it might be a few
minutes.
Generally, it wants the location AS SOON AS IT CAN GET IT.  If you ask
it,
it will say "zero seconds, please, or as soon as you can".  It does NOT
have
a real upper limit when it starts the transaction.  There is no
meaningful
variability among PSAPs; they all want it as soon as they can get it.
The
only difference between PSAPs today is that some have prevailed upon
their
vendors to implement a per-carrier fixed delay for rebid, and some rely
on
the skill of their call takers to do it.  None of them, not one that I
know,
would stand up and tell you they were prepared to wait 10, 20, 30, 50 or
180
seconds.  That's not how it works.  That's not what they want.  They
want it
as soon as they can get it.  Period.

Brian

> >> call setup) or "whenever" (within a reasonable time of, say, a
minute
> >> or
> >> two). I know no client application that somehow can wait 10
seconds,
> >> locations, so I suspect it's more productive to focus on geo to
keep
> >>> useful. Applications generally want the most accurate location
they

---

From: Shida Schubert <[email-masked]>
Date: Tue, 31 Jul 2007 13:48:19 -0700

I read the HELD document to be a location configuration protocol which 
is intended to
be used by the target of the location. In case of VoIP, it is generally 
the device the caller
uses and not by the consumer of the location.

 What PSAP uses as a consumer of the location as I understand is not 
HELD but rather
a dereference protocol currently discussed as an individual draft.

 If I understand you correctly, you are saying that HELD doesn't need a 
responseTime
but ability to indicate responseTime is necessary for PSAP in 
dereference protocol.

 Regards
  Shida

Stuard, Doug wrote:
>> I think the basic disconnect is that I'm assuming that we should
>>     
>
> design
>
>   
>> (meaning within the 1-2 second post-dial delay margin available during
>>     
>
>   
>> a
>>     
>
>   
>> call setup) or "whenever" (within a reasonable time of, say, a minute
>>     
>
>   
>> or
>>     
>
>   
>> two). I know no client application that somehow can wait 10 seconds,
>>     
>
>   
>> but
>>     
>
>   
>> The pre-call case also has no natural time limit, beyond "as
>>     
>
> accurately
>
>   
>> as possible".
>>     
>
>   
>
>   
>> essentially has to pick an arbitrary time value. It has no idea
>>     
>
> whether
>
>   
>> approximation of infinity as values, with the danger that requests
>>     
>
> will
>
>   
>> seconds will get reasonable results most of the time in the network
>>     
>
>   
>> they
>>     
>
>   
>> locations, so I suspect it's more productive to focus on geo to keep
>>     
>
>   
>> the
>>     
>
>   
>> problem manageable.
>>     
>
>   
>
>   
>>> provide an optimal accuracy in response to a location request by
>>>       
>
>   
>> giving
>>     
>
>   
>>> update later is adequate. In scenarios where a device wants a
>>>       
>
>   
>> location
>>     
>
>   
>>> value so it can send it to an application for immediate processing
>>>       
>
> by
>
>   
>>> that application, there is no use for "subsequent" values. That's
>>>       
>
> why
>
>   
>>> applicable to every use case for location requests. The location
>>>       
>
>   
>> server
>>     
>
>   
>>> Not having a scalar response time criterion means that the server
>>>       
>
> can
>
>   
>>> Experience has shown that an accuracy requirement parameter is not
>>>       
>
> so
>
>   
>>> useful. Applications generally want the most accurate location they
>>>       
>
>   
>> can
>>     
>
>

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 31 Jul 2007 14:20:42 -0700

Hi,

One important question inline...

On 7/21/07, Dawson, Martin <[email-masked]> wrote:
> five seconds, I'd have been OK to wait."

> If it is OK to wait five seconds, then it should request a response time of at least five
> seconds.

How does the client and/or application know that it is OK to wait 5
seconds?  Can you describe an example use case (a vignette) with a
sample time?

In the medical world, labs are often asked to provide results in
roughly these time scales:
STAT:  immediately.  drop everything.
ASAP: As Soon As Possible.  Do it now unless you are doing something STAT
Next Available: when you would normally get it done.
Double Check: Be extra thorough and rigorous. Take as long as you need.

I am wondering if this is more along the lines of what the client
wants to specify.

thanks,
-rohan

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 31 Jul 2007 18:12:10 -0500

Hi Rohan,

Per the key question:

I think the only entity that can possibly know how long it is OK to wait
is the client/application. The location server certainly doesn't know
what the context of the application is. All I'm asking is that the
client be able to inform the server of this so the server can optimize
the result for the client.

Some vinaigrettes :) :

1. A "local services" application running on a PDA is asked to provide
the nearest teller machines to the current location. It can provide
visual feedback to the user that it is determining their current
location. It thinks that a minute is a reasonable amount of time to ask
the user to wait in this context. The application sends the location
request to the LIS telling it that it is prepared to wait up to a minute
for the response. The LIS provides the optimal location value - which
may take considerably less than a minute.

2. A location-based interactive game wants an updated list of all fellow
team members in the current geographical vicinity. It's a tactical
message. The application thinks this needs to be accomplished within ten
seconds. It requests the game server to get all team members to update
their location. All team member application instances request a location
update with a five second response time. If no location is retrieved,
the application returns the last known location, suitably tagged as
such, for display at the requesting player's terminal.

3. A VoIP call is being placed that is subject to location based
routing. The call is urgent. The VoIP application requests the current
location from the LIS and tells it that it needs a location in 2 seconds
for incorporation in the SIP invite.

4. A pizza delivery application (having been accurately routed to) wants
a more accurate location for pizza delivery. The pizza dispatcher asks
the caller for their current accurate location. The caller consults the
auto-location determiner application on their PDA and tells it to see
what it can work out in the next 30 seconds. The LIS applies optimal
location determination technology given that time frame.

Now, to turn things around, I'd actually like an example of a
client/application that wouldn't apply some sort of timeout to the
request that it sends to a LIS. All I'm asking is that this particular
piece of information be passed on to the LIS to facilitate the location
determination process. We'd already agreed on some reasonable default
semantics where an application doesn't provide this guidance. The
fundamentals of the objection escape me.

Cheers,
Martin

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Wednesday, 1 August 2007 7:21 AM
To: Dawson, Martin
Cc: Brian Rosen; Stark, Barbara; Mary Barnes; [email-masked]
Subject: Re: [Geopriv] HELD comment on responseTime parameter

Hi,

ASAP: As Soon As Possible.  Do it now unless you are doing something
STAT

thanks,
-rohan
entity