Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-barnes-ecrit-rough-loc-00]

From: Richard Barnes <[email-masked]>
Date: Tue, 15 Apr 2008 11:29:34 -0400

Hi Karl Heinz,

Thanks for your comments, and I apologize for the delayed response.

> I read your draft and I have a question on section 4.1.: If I
> understand you correctly, a client using HELD would perform a HELD
> request, and would get back location by value and by reference at
> once. The value is imprecise, the reference can be dereferenced to
> precise location by the PSAP.

Yes, that is what we intended it to mean.

> What if the HELD request is with locationtype civic and exact=true ?
> The LIS is not allowed to hand out a URI any more, and the client
> cannot know that the value it gets is imprecise. Or would you suggest
> that this type of query fails, and the client would have to request a
> locationURI in a separate request, dereference the URI in the next
> step to get imprecise location?

That's a good point, and I think the request failing is the correct
behavior.  If a client cannot support location-by-reference (i.e., if it
can only support civic or geo), then it is incompatible with this
solution.  If the client CAN use an LbyR, then it should re-query.

--Richard

> 
> 
> cheers
> karl heinz
> 
> 
> On Mon, Feb 18, 2008 at 4:47 PM, Richard Barnes <[email-masked]> wrote:
>> We have posted a draft that explains how imprecise location can be used
>>  for emergency context resolution within the ECRIT framework.
>>  Specifically, we describe how a location provider can determine when a
>>  position is sufficiently precise for emergency call routing, and how
>>  emergency and non-emergency services are delivered in this context.
>>
>>  While this document may enable a solution to the location-hiding
>>  problem, it can also be useful when a location provider is using
>>  positioning mechanisms that are capable of returning location at various
>>  granularities, with finer-grained location taking more time or resources
>>  to compute.
>>
>>  --Richard
>>
>>
>>
>>  -------- Original Message --------
>>  Subject: New Version Notification for draft-barnes-ecrit-rough-loc-00
>>  Date: Mon, 18 Feb 2008 07:35:55 -0800 (PST)
>>  From: IETF I-D Submission Tool <[email-masked]>
>>  To: [email-masked]
>>  CC: [email-masked]
>>
>>
>>  A new version of I-D, draft-barnes-ecrit-rough-loc-00.txt has been
>>  successfuly submitted by Richard Barnes and posted to the IETF repository.
>>
>>  Filename:        draft-barnes-ecrit-rough-loc
>>  Revision:        00
>>  Title:           Using Imprecise Location for Emergency Context Resolution
>>  Creation_date:   2008-02-18
>>  WG ID:           Independent Submission
>>  Number_of_pages: 12
>>
>>  Abstract:
>>  Emergency calling works best when precise location is available for
>>  emergency call routing.  However, there are situations in which a
>>  location provider is unable or unwilling to provide precise location,
>>  yet still wishes to enable subscribers to make emergency calls.  This
>>  document describes the level of location accuracy that providers must
>>  provide to enable emergency call routing.  In addition, we descibe
>>  how emergency services and non-emergency services can be invoked by
>>  an endpoint that does not have access to its precise location.
>>
>>
>>
>>
>>  The IETF Secretariat.
>>
>>
>>
>>
>>
>>  _______________________________________________
>>  Ecrit mailing list
>>  [email-masked]
>>  http://www.ietf.org/mailman/listinfo/ecrit
>>
> 

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 Apr 2008 17:05:51 -0500

Hi Richard,

Just a comment below.

[AJW] I am assuming that in this case the end-point (I am going to use this term in place of client) has set the responseTime to a value of emergencyRouting.
      In which case the LIS already knows the intended application for the location information, so the LIS will return location information in the form suitable
      for that application, be that a literal location or a location URI. If the device is using HELD, then it had better be prepared to accept and deal with a location URI or it isn't HELD compliant. I also think that the use case is a little moot as presented, as the end-point probably doesn't have authorization to dereference the URI, oris the suggestion that the LIS provides different grades of location information depending on who is asking?

Cheers
James

------------------------------------------------------------------------------------------------
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: Richard Barnes <[email-masked]>
Date: Tue, 15 Apr 2008 18:39:44 -0400

James,

Couple of responses, both to you and myself.

> behavior.  If a client cannot support location-by-reference (i.e., if
> it can only support civic or geo), then it is incompatible with this 

[RLB]
I misspoke (mis-wrote?) here; this statement is not quite accurate.  As 
James points out, the HELD server can still return the imprecise value, 
and the call will route correctly; the call just won't carry location. 
So when endpoints don't support LbyR, they get degraded service.  As 
Karl Heinz points out, there's no clear indicator in this case that the 
location is imprecise, but presumably that can be inferred by examining 
the location and the region it covers.
[/RLB]

> [AJW] I am assuming that in this case the end-point (I am going to
> use this term in place of client) has set the responseTime to a value
> of emergencyRouting. In which case the LIS already knows the intended
> application for the location information, so the LIS will return
> location information in the form suitable for that application, be
> that a literal location or a location URI.

[RLB]
That's true (see above).  However, it's worth noting that in that case, 
the access controls for the location URI MUST allow the client to 
dereference it to obtain a coarse location.
[/RLB]

> If the device is using
> HELD, then it had better be prepared to accept and deal with a
> location URI or it isn't HELD compliant. 

[RLB]
I don't see how this follows.  Otherwise, why does HELD allow me to set 
<locationType exact="true">geodetic civic</locationType>?
[/RLB]

> I also think that the use
> case is a little moot as presented, as the end-point probably doesn't
> have authorization to dereference the URI, oris the suggestion that
> the LIS provides different grades of location information depending
> on who is asking?

[RLB]
Here's the real requirement: In order to ensure that the endpoint has 
access to routing-grade location, the LIS MUST provide either 
routing-grade LbyV (plus an optional LbyR), or an LbyR that the endpoint 
can dereference to a routing-grade LbyV.  The choice between these two 
can be left to the LIS without affecting interoperability; if the client 
doesn't get an LbyV, then he just tries to dereference the LbyR.
[/RLB]

Cheers,
--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 16 Apr 2008 00:52:04 -0500

One more below.

[RLB]

[AJW]I think that this is only true if you start with the premise that the end-point must have location.
     A location URI and a destination URI achieves the same result without providing location to the end-point.
     I will however concede that this does not provide you with a coarse location solution... *8)
[/AJW]

---

From: Richard Barnes <[email-masked]>
Date: Wed, 16 Apr 2008 09:28:07 -0400

> [RLB] Here's the real requirement: In order to ensure that the
> endpoint has access to routing-grade location, the LIS MUST provide
> either routing-grade LbyV (plus an optional LbyR), or an LbyR that
> the endpoint can dereference to a routing-grade LbyV.  The choice
> between these two can be left to the LIS without affecting
> interoperability; if the client doesn't get an LbyV, then he just
> tries to dereference the LbyR. [/RLB]
> 
> [AJW]I think that this is only true if you start with the premise
> that the end-point must have location. A location URI and a
> destination URI achieves the same result without providing location
> to the end-point. I will however concede that this does not provide
> you with a coarse location solution... *8) [/AJW]

[RLB]
Exactly.  This document is describing a partcular solution, the "coarse 
location" solution.  In the context of that solution, the LIS MUST 
provide coarse location to the endpoint, whether by value or by reference.
[/RLB]