Subject: [Geopriv] ResponseTime

From: Robert Sparks <[email-masked]>
Date: Mon, 27 Aug 2007 11:05:08 -0500

All -

Lets push to close on the responseTime question.

To do this, I'm going to need to hear from more of the group than  
just the folks that were active in the discussion earlier in the month.

So far, I've seen a good argument that a server can have different  
technologies available for determining location and would benefit  
from knowing something about how long a client is willing to wait in  
order to choose which one to focus on. There has been a question  
about an implicit time/accuracy tradeoff here and a suggestion that  
we should explore a more explicit separation of indicating those things.

I've also seen a good argument that it is unclear how a client  
implementation is going to provide values that would be useful to the  
server. Without more clarity around this point, I see discomfort from  
several people that the proposed mechanism is an opportunity for  
"Unintended Consequences" to rear its head.

On rereading the threads, I strongly suspect that there are a set of  
assumptions going into arguing for this parameter that haven't been  
made explicit yet, and I'd like to try a round of teasing those out  
to see if it closes the gap in the discussion.

Lets start with these two statements (which I _think_ the folks  
pushing for the parameter are assuming are true - correct what I have  
wrong please):

1) The clients will provide a useful indication of responseTime from  
the server's point of view.
2) Different clients (or different applications at the same client)  
will provide different enough values to make the same server choose  
different location technologies in servicing the query.

I can see the parameter helping a system work as long as the service  
has some way to tell the client what to ask for (and I recognize that  
means the client has to know what service it's invoking).

James  (or anyone else who has deployed or is developing a deployment  
of something like this) - do you expect to have some influence in a  
deployment over what the clients include in this parameter? Are you  
expecting to have a relationship with the vendors providing clients  
that lets you hand them values to hardcode,
or give you a configuration interface you can use as a service  
provider? Or are you expecting that to be entirely outside your control?

RjS

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: [email-masked]
Date: Mon, 27 Aug 2007 14:38:59 -0400

Hi,

> ... need to hear from more of the group than 
> just the folks that were active in the discussion earlier in the month

I have stayed mostly out of the debate thus far, so here goes. 

I would support response time parameter ONLY as an optional extension. 
This for the following reasons: 

o I do not see value in it for the most part; I expect most applications 
(including ECS) simply don't need it or it would bring fairly minimal 
value added.   (I can certainly see some special cases / applications 
where it might be helpful, hence do see value as optional extension for 
those.) 

o It seems very difficult to make such a parameter specific enough to get 
the proposed value out of it in any consistent way, 

o MOST IMPORTANT I desperately want endpoints needing to support HELD for 
ECS purposes to have an absolutely ruthlessly simple subset of the 
functionality that they must implement.  The subset must be both small 
(footprint) and very easy to implement correctly.  Endpoints that want to 
do more than ECS can add to the simple subset by using extended options, 
but those that do only the ECS part need to be very constrained.  The 
value added bar needs to be set very high for the core subset.  The value 
of response time parameter in ECS does not make that grade for me. 

Just to be clear on that last point, I'm not all that concerned about the 
protocol itself (pretty easy) but more so about the implications to the 
rest of the implementation: What to do if response does not come back in 
requested time ... what to do if not at requested accuracy .. what if .. 
what if ....  And also I have the general concern of "feature creep", of 
which this is one potential example. 

-- Peter
.

Robert Sparks <[email-masked]>
27.08.07 12:05
 
        To:     GEOPRIV <[email-masked]>
        cc: 
        Subject:        [Geopriv] ResponseTime

All -

RjS

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 27 Aug 2007 14:41:11 -0500

Hi Robert,

As with MLP applications today, or SET client implementations in
handsets for SUPL today, I totally expect that the response time will be
exposed to the applications via the client API. If the device had no
idea what the application was that was requesting location then, I
agree, it couldn't make a sensible guess about the required response
time.

The API would have the same default semantics with respect to this
parameter as is defined for the protocol itself. It doesn't have to be
mandatory but it's darn useful if the application can provide it and
it's to the benefit of the application to be able to.

Cheers,
Martin

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Tuesday, 28 August 2007 2:05 AM
To: GEOPRIV
Subject: [Geopriv] ResponseTime

All -

RjS

------------------------------------------------------------------------------------------------
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: "Stark, Barbara" <[email-masked]>
Date: Mon, 27 Aug 2007 16:30:29 -0400

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

________________________________

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

Hi, 

o It seems very difficult to make such a parameter specific enough to
get the proposed value out of it in any consistent way, 

o MOST IMPORTANT I desperately want endpoints needing to support HELD
for ECS purposes to have an absolutely ruthlessly simple subset of the
functionality that they must implement.  The subset must be both small
(footprint) and very easy to implement correctly.  Endpoints that want
to do more than ECS can add to the simple subset by using extended
options, but those that do only the ECS part need to be very
constrained.  The value added bar needs to be set very high for the core
subset.  The value of response time parameter in ECS does not make that
grade for me.   

Just to be clear on that last point, I'm not all that concerned about
the protocol itself (pretty easy) but more so about the implications to
the rest of the implementation: What to do if response does not come
back in requested time ... what to do if not at requested accuracy ..
what if .. what if ....  And also I have the general concern of "feature
creep", of which this is one potential example.   

-- Peter 
. 

27.08.07 12:05 

All -

RjS

*****

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 27 Aug 2007 15:45:48 -0500

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

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

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

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

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

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

Cheers,

Martin

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

Barbara

Hi, 

-- Peter 
. 

27.08.07 12:05 

All -

RjS

*****

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

---

From: "Stuard, Doug" <[email-masked]>
Date: Mon, 27 Aug 2007 17:12:52 -0400

Given the practical limits stated, option i) is good

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

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

Doug

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

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

Cheers,

Martin

Barbara

Hi, 

-- Peter 
. 

27.08.07 12:05 

All -

RjS

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

*****

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 27 Aug 2007 14:21:28 -0700

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

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

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

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

	Doug

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

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

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

	Cheers,

	Martin

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

	Barbara

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

	Hi, 

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

27.08.07 12:05 

	
	
	All -

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

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

	On rereading the threads, I strongly suspect that there are a
set of  
	assumptions going into arguing for this parameter that haven't
been  
	made explicit yet, and I'd like to try a round of teasing those
out  
	to see if it closes the gap in the discussion.

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

	

	*****

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

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

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 27 Aug 2007 14:25:47 -0700

Ugh, the example should have been '30 seconds' rather than '60 seconds',
i.e., 
 
30 : 50 (means provide a location inside a radius of 50m within 30
seconds)
 
-roger.

	From: Roger Marshall [mailto:[email-masked]] 
	Sent: Monday, August 27, 2007 2:21 PM
	To: Stuard, Doug; Dawson, Martin; Stark, Barbara;
[email-masked]; Robert Sparks
	Cc: GEOPRIV
	Subject: RE: [Geopriv] ResponseTime

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

	-roger marshall.

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

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

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

		Doug

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

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

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

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

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

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

		Cheers,

		Martin

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

		Barbara

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

27.08.07 12:05 

		
		
		All -

		To do this, I'm going to need to hear from more of the
group than  
		just the folks that were active in the discussion
earlier in the month.
		
		So far, I've seen a good argument that a server can have
different  
		technologies available for determining location and
would benefit  
		from knowing something about how long a client is
willing to wait in  
		order to choose which one to focus on. There has been a
question  
		about an implicit time/accuracy tradeoff here and a
suggestion that  
		we should explore a more explicit separation of
indicating those things.
		
		I've also seen a good argument that it is unclear how a
client  
		implementation is going to provide values that would be
useful to the  
		server. Without more clarity around this point, I see
discomfort from  
		several people that the proposed mechanism is an
opportunity for  
		"Unintended Consequences" to rear its head.
		
		On rereading the threads, I strongly suspect that there
are a set of  
		assumptions going into arguing for this parameter that
haven't been  
		made explicit yet, and I'd like to try a round of
teasing those out  
		to see if it closes the gap in the discussion.
		
		Lets start with these two statements (which I _think_
the folks  
		pushing for the parameter are assuming are true -
correct what I have  
		wrong please):
		
		1) The clients will provide a useful indication of
responseTime from  
		the server's point of view.
		2) Different clients (or different applications at the
same client)  
		will provide different enough values to make the same
server choose  
		different location technologies in servicing the query.
		
		I can see the parameter helping a system work as long as
the service  
		has some way to tell the client what to ask for (and I
recognize that  
		means the client has to know what service it's
invoking).
		
		James  (or anyone else who has deployed or is developing
a deployment  
		of something like this) - do you expect to have some
influence in a  
		deployment over what the clients include in this
parameter? Are you  
		expecting to have a relationship with the vendors
providing clients  
		that lets you hand them values to hardcode,
		or give you a configuration interface you can use as a
service  
		provider? Or are you expecting that to be entirely
outside your control?
		
		RjS

		

		*****

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

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 27 Aug 2007 20:53:13 -0500

I don't believe that time vs accuracy can be profiled well in this fashion.
You don't actually know in many cases how accurate the result is going to be until you have started the location calculation.

Take cell-based location for example; I can go from femtocells with a few metre uncertainty to CDMA boomer cells with 200km radius.
Both fall in the 0 or sub-second time category, they could also fall into all of the categories you describe below for accuracy.

So I can have 0 : 2
And a 0 : 200,000

Since no device knows the kind of cell it is attached to every device is going to pick the first one,  2 metre accuracy in no time, and some are going to be sorely disappointed. If you specified a wait time of two seconds only, then those connected to a femtocell are happy, they have almost no wait time. Those connected to the boomer cell wait 2 seconds and get a 50 metre accuracy result. Since they were prepared to wait anyway, they are happy too, because 50m is way better than 200km.

The reality is that specifying the accuracy component becomes moot once you know how long the application is prepared to wait. The same is not true in the reverse direction. Indeed there is no general accuracy to wait-time profile that can be provided ahead of time, for any given wireless network this is a non-deterministic problem.

The LIS will pick the most accurate determination technique available in the time requested, and input to this decision may actually be acquired at the time the request is received. For example if you are connected to a femtocell then I am probably not going to bother to invoke anything else, if you are connected to a standard cell then I might. The point and type of access is important to the LIS here for determination, but it is likely completely unknown to the end-point and in many cases can't be known.

Providing a time addresses these concerns in a deterministic manner that will work across all networks since the time is what the application is tolerant to, and the worst case is known. 

I have a need for a responseTime parameter. I am prepared to accept that others only want ASAP, and that others still claim they will want AGAP. I remain sceptical about the last one because this is normally qualified with a comment such as "within a reasonable time frame". However, just because I can't see it, doesn't make it so.

Given my description of profiling above, would people be prepared to accept the following:

1) No responseTime provided, you get AGAP, however long that takes.
2) responseTime = 0, you get ASAP
3) responseTime >0, you get best in time provided.

If people want other things, then they can profile those in HELD extensions.
This meets Peter's previous concern, if he wants minimal wired-client support, his HELD client says responseTime=0.

Cheers
James

________________________________________
From: Roger Marshall [mailto:[email-masked]] 
Sent: Tuesday, 28 August 2007 7:21 AM
To: Stuard, Doug; Dawson, Martin; Stark, Barbara; [email-masked]; Robert Sparks
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime

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

________________________________________

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 00:53:24 -0500

Though, of course, that would be a best-fit approach. A best-basis approach would not take current practical limits into consideration. Why rule out the "I'll wait as long as it takes even if it's forever" use case unnecessarily?

I'd actually prefer ii) to be the default.

Cheers,
Martin

________________________________________
From: Stuard, Doug 
Sent: Tuesday, 28 August 2007 7:13 AM
To: Dawson, Martin; Stark, Barbara; [email-masked]; Robert Sparks
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime

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

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

Doug

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

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

i) As fast as possible at whatever accuracy that results in.
ii) Take as long as you like until you think it's as accurate as you can get it.

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

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

Cheers,
Martin

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

Hi, 

I would support response time parameter ONLY as an optional extension.  This for the following reasons: 

o I do not see value in it for the most part; I expect most applications (including ECS) simply don't need it or it would bring fairly minimal value added.   (I can certainly see some special cases / applications where it might be helpful, hence do see value as optional extension for those.)   

o It seems very difficult to make such a parameter specific enough to get the proposed value out of it in any consistent way, 

o MOST IMPORTANT I desperately want endpoints needing to support HELD for ECS purposes to have an absolutely ruthlessly simple subset of the functionality that they must implement.  The subset must be both small (footprint) and very easy to implement correctly.  Endpoints that want to do more than ECS can add to the simple subset by using extended options, but those that do only the ECS part need to be very constrained.  The value added bar needs to be set very high for the core subset.  The value of response time parameter in ECS does not make that grade for me.   

Just to be clear on that last point, I'm not all that concerned about the protocol itself (pretty easy) but more so about the implications to the rest of the implementation: What to do if response does not come back in requested time ... what to do if not at requested accuracy .. what if .. what if ....  And also I have the general concern of "feature creep", of which this is one potential example.   

-- Peter 
. 

All -

RjS