Subject: [Ecrit] What does LoST return for a polygon?

From: Richard Barnes <[email-masked]>
Date: Mon, 17 Dec 2007 16:47:34 -0500

I'm bothered by the following text in draft-ietf-ecrit-lost-06:

"
    When clients place a <Polygon>, <Circle>, <Ellipse> or <ArcBand>
    element within the <location> element then it indicates that the
    query is about any point contained in the given area; it is left to
    the server to select an appropriate matching algorithm, such as using
    computing the centroid.
"

The case that worries me is when I have an imprecise location that 
crosses service boundaries, and the LoST server chooses the wrong one. 
I don't have anything else to try, since the LoST server didn't tell me 
any other possibilities.

In addition, I don't think this behavior is compatible with the "return 
all possible results" philosophy in the draft-ietf-mapping-arch-03. 
Even though that was said in the context of multiple service boundaries 
overlapping a single point, the same logic would seem to apply to a 
single location that spans multiple service boundaries.

Can we change this to say that the server MUST return all appropriate 
<mapping> elements when the polygon extends over multiple service areas?

--RB

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Dec 2007 17:14:23 -0800

At 4:47 PM -0500 12/17/07, Richard Barnes wrote:
>The case that worries me is when I have an imprecise location that crosses service boundaries, and the LoST server chooses the wrong one. I don't have anything else to try, since the LoST server didn't tell me any other possibilities.

>In addition, I don't think this behavior is compatible with the "return all possible results" philosophy in the draft-ietf-mapping-arch-03. Even though that was said in the context of multiple service boundaries overlapping a single point, the same logic would seem to apply to a single location that spans multiple service boundaries.

I don't think this is the same context, honestly.  This fits in within a previous
design decision, that the URIs returned should be deterministic; the end user
shouldn't have to try them each in turn.  If I get a URI that returns me to
a PSAP/ESRP that happens to be across the state line from where I am
(in the real corner case that the selected point in the arc band would return
the wrong ESRP with state-level ESRPs),  the call takers will have to determine where I
really am.  Once that determination is made, they will need to forward me to the right
PSAP/ESRP or do a LoST lookup on my behalf to provide me a way to do it.  

But *someone* would have to do the real location determination anyway; giving
me a list of potential match URIs doesn't help that.  I still have to call and
tell someone where I am before getting any further.  This just gives me a second
URI to try after getting through that point with the first; assuming the first one
is a valid URI *at all*, that's not really an advantage as the call taker interaction
will get me further than a blind drop to the second item on the list will.  It also
avoids the whole issue of how to order the list, something which is rife with
potential issues.

I oppose this change.
				Ted

>Can we change this to say that the server MUST return all appropriate <mapping> elements when the polygon extends over multiple service areas?
>
>--RB

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Dec 2007 20:34:13 -0500

I agree with Ted.

This occurs today, given that sector-based routing may well span  
multiple PSAPs. In practice, what should happen is that the location  
fix gets more precise by the time the call gets answered, and the call  
taker can then transfer the call automatically to the right place,  
doing another LoST dip. If you get location fixes that routinely span  
multiple jurisdictions by significant amounts, I have a hard time  
seeing how this location accuracy can be useful for dispatch. It's  
certainly not FCC-compliant.

Henning

On Dec 17, 2007, at 8:14 PM, Ted Hardie wrote:

>> crosses service boundaries, and the LoST server chooses the wrong  
>> one. I don't have anything else to try, since the LoST server  
>> didn't tell me any other possibilities.
>
>> In addition, I don't think this behavior is compatible with the  
>> "return all possible results" philosophy in the draft-ietf-mapping- 
>> arch-03. Even though that was said in the context of multiple  
>> service boundaries overlapping a single point, the same logic would  
>> seem to apply to a single location that spans multiple service  
>> boundaries.
>
>> Can we change this to say that the server MUST return all  
>> appropriate <mapping> elements when the polygon extends over  
>> multiple service areas?
>>
>> --RB
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Dec 2007 08:43:44 -0500

Yeah, they are right.

Once you call a PSAP, you don't hang up and try another one if you got the
wrong one.  They transfer you to the right one.

So, you want the best guess from the information given.  The LoST server is
in the best position to determine that, and the answer it gets is where you
send the call.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, December 17, 2007 8:34 PM
> To: Ted Hardie
> Cc: ECRIT
> Subject: [Ecrit] Re: What does LoST return for a polygon?
> 
> I agree with Ted.
>