Subject: [Geopriv] HELD ResponseTime parameter with value emergencyRouting

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Jun 2009 20:42:17 -0400

In NENA, there is a discussion on the best form (shape) to send to the
LoST server when the shape is a cell sector.  The discussion itself is
pretty specific to NENA, although it involves the fact that it might be
necessary for the LIS to choose the shape of the response for emergency
routing that might be different than it would return for other purposes.

Martin Thompson is worried about something that I seek advice on.

The wording choice for ResponseTime in HELD is:
6.1.  "responseTime" Parameter

   The "responseTime" attribute MAY be included in a location request
   message.  The "responseTime" attribute includes a time value
   indicating to the LIS how long the Device is prepared to wait for a
   response or a purpose for which the Device needs the location.

   In the case of emergency services, the purpose of obtaining the LI
   could be either for routing a call to the appropriate PSAP or
   indicating the location to which responders should be dispatched.
   The values defined for the purpose, "emergencyRouting" and
   "emergencyDispatch", will likely be governed by jurisdictional
   policies, and should be configurable on the LIS.

Please note the construction of the last sentence of the first paragraph
about "purpose".

I claim that it is perfectly reasonable to expect the LIS to construct a
PIDF suitable for the purpose of emergency routing when it encounters
the emergencyRouting value in responseTime, and the fact that it is in
the "responseTime" parameter doesn't limit the LIS from sending an
appropriate PIDF content as well as within an appropriate time limit.
The LIS knows the purpose, and can reasonably be expected to respond
appropriately in both time and content.  Otherwise, we would need
another parameter to ask for the right content, which is silly.

I have been okay with the current wording because I believed that the
LIS could use the emergencyRouting (or emergencyDispatch for that
matter) as an all purpose "purpose" (as it were) and wasn't hung up on
the fact that it's in the responseTime parameter.

Am I wrong?

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 2 Jun 2009 20:01:32 -0500

The problem here is that Brian seems able to interpret this text to attach additional meaning to the emergencyRouting and emergencyDispatch tags.  I had thought that the text was clear enough, but it seems that Brian has been harbouring an alternative interpretation for a while now.

We discussed the option of a separate service indicator.  In fact, I was in favour of such, but this approach was chosen - I thought - because we only wanted to address the _response time_ problem in relation to emergency services.

The dogmatic position is that response time is response time and it doesn't say anything about anything else.

Conflation of semantics is bad engineering.

--Martin

p.s. Wow, two misspellings of my name in less than 2 minutes.  I agree with Marc, but not you.  You get the response.  Marc does seem to be talking to someone else entirely though...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rosen, Brian
> Sent: Wednesday, 3 June 2009 10:42 AM
> To: [email-masked]
> Subject: [Geopriv] HELD ResponseTime parameter with value
> emergencyRouting
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Jun 2009 20:19:50 -0500

My feelings are that is you want to constrain shapes based on service
type then you can write an HELD extension that introduces a new
attribute that can be include din the location request. You can then
have an IANA registry for the service tags, or, more sensibly, you can
resuse the IANA service URN registry that LoST has set up and send these
values to the LIS.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Thomson, Martin
> Sent: Wednesday, 3 June 2009 11:02 AM
> To: Rosen, Brian; [email-masked]
> Subject: Re: [Geopriv] HELD ResponseTime parameter with
> valueemergencyRouting
> 
> The problem here is that Brian seems able to interpret this text to
attach
> additional meaning to the emergencyRouting and emergencyDispatch tags.
I
> had thought that the text was clear enough, but it seems that Brian
has
> been harbouring an alternative interpretation for a while now.
> 
> We discussed the option of a separate service indicator.  In fact, I
was
> in favour of such, but this approach was chosen - I thought - because
we
> only wanted to address the _response time_ problem in relation to
> emergency services.
> 
> The dogmatic position is that response time is response time and it
> doesn't say anything about anything else.
> 
> p.s. Wow, two misspellings of my name in less than 2 minutes.  I agree
> with Marc, but not you.  You get the response.  Marc does seem to be
> talking to someone else entirely though...
> 
> > I claim that it is perfectly reasonable to expect the LIS to
construct
> > a
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 21:26:12 -0400

On the other hand, a HELD request places no constraints on what shape 
the LIS returns, so in principle, a LIS could use the responseTime 
parameter as an input.  This could happen even in non-emergency cases, 
e.g., if it would return a sector for a fast lookup and an error ellipse 
with A-GPS.

The risk that goes along with this is that the endpoint might use the 
location for non-emergency services, and thus obtain a lower quality of 
service is the location is less precise/accurate.

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 2 Jun 2009 20:39:06 -0500

This risk is precisely why James' suggestion is actually quite useful.

Assuming that responseTime only pertains to response time, it might be reasonable for a client to make certain assumptions about the two emergency tags and use them accordingly.  

I know that already emergencyRouting is used to mean "just long enough to get basic location".  Nothing prevents a similar assumption about emergencyDispatch (i.e. "just long enough to get really good location").

Nothing in the contract states that doing this risks degraded service.  An explicit service tag would provide an explicit indication to the client that the LIS might have done something special to the result for that service.  The semantics could state that the location is (potentially) only useful for that service.

--Martin

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Wednesday, 3 June 2009 11:26 AM
> To: Thomson, Martin
> Cc: Rosen, Brian; [email-masked]
> Subject: Re: [Geopriv] HELD ResponseTime parameter with value
> emergencyRouting
> 
> attach additional meaning to the emergencyRouting and emergencyDispatch
> tags.  I had thought that the text was clear enough, but it seems that
> Brian has been harbouring an alternative interpretation for a while
> now.
> >
> was in favour of such, but this approach was chosen - I thought -
> because we only wanted to address the _response time_ problem in
> relation to emergency services.
> >
> > p.s. Wow, two misspellings of my name in less than 2 minutes.  I
> agree with Marc, but not you.  You get the response.  Marc does seem to
> be talking to someone else entirely though...
> >

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 21:42:58 -0400

I don't see much applicability to this outside the generic  emergency 
services case (i.e., urn:service:sos), so my inclination would be to 
avoid going down that path.

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 2 Jun 2009 21:30:50 -0500

The NENA discussion hinged around the question of whether the routing
service (LoST) should apply weighted routing to the location offered by
the device - and let's assume the relevant use case is that the network
LIS provided this location in, say, a cellular network. Proponents of
weighted routing pointed out that the uncertainty around a cell may
overlap two or more routing boundaries and that the optimal approach is
to determine which routing area the largest proportion (weight) of the
uncertainy falls into. 

Those opposed to this approach said that, in fact, the location should
just be provided as point - ignoring the fact that uncertainty is
associated with it. And this proposal was made on the basis that *the
LIS should ensure that the point provided falls into the correct
(optimal?) routing area before providing it to the client*

This sentiment is reflected in the following from Brian's post on this

> PIDF suitable for the purpose of emergency routing when it encounters
the
> emergencyRouting value in responseTime

The real kicker in this is that the LIS *has to perform actual routing
analysis before providing the location*. The inevitable consequence of
this is that the LIS has to have some sort of access to the routing
boundary information in order to do this - don't forget a cellular
location can't be stored in the LIS before hand; it's generated
dynamically. So now, the LoST data, including multiple adjacent boundary
information, also has to live in the LIS or be otherwise accessible to
it.

Now - if this is a reasonable expectation, and I'm not saying it isn't,
then it must raise the question of why use LoST at all to do the PSAP
URI lookup, why not have the LIS deliver it directly since it's already
had to perform routing? I don't buy an interoperability argument against
this. An optional extension in the HELD response could contain the PSAP
URI. Any device not supporting it can fall back to looking for LoST. It
means that broadband providers could start providing ECRIT emergency
call routing without the public LoST deployment/management problem
having to be solved. Public network operators already do this routing
analysis for the PSTN including cellular; it's not a new ask.

Cheers,
Martin

-----Original Message-----

Am I wrong?

Brian

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 23:08:45 -0400

Martin,

It actually isn't that onerous for the LIS to check whether a given 
location is 'good enough for routing'.  Basically, it involves a lot of 
LoST queries to collect service boundaries for the relevant areas, some 
off-line computations, then only a polygon-in-polygon check at query 
time.  We describe an algorithm in draft-barnes-ecrit-rough-loc:
<http://tools.ietf.org/html/draft-barnes-ecrit-rough-loc#section-3>
Picking a service region (as I think your quote from Brian suggests a 
LIS would do) is then just a matter of intersecting the two polygons.

That said, it seems to me that whether the LIS applies such an algorithm 
is still a matter of local policy, with no protocol changes necessary.

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Jun 2009 22:32:52 -0500

Hi Richard,

That said, if the LIS has to get this information anyway and then do the
polygon-in-polygon check, it may as well return the resulting
destination URIs as well and do away with having to have 2 protocols
supported by the end-point when one will do.

At what point do we stop?

Cheers
James

Behalf
> Of Richard Barnes
> Sent: Wednesday, 3 June 2009 1:09 PM
> To: Dawson, Martin
> Cc: [email-masked]; Rosen, Brian
> Subject: Re: [Geopriv] HELD ResponseTime parameter withvalue
> emergencyRouting
> 
> Martin,
> 
construct
> > I claim that it is perfectly reasonable to expect the LIS to
construct a
> ------------------------
> ------------------------

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 23:39:56 -0400

It's just clean protocol design to keep these two functions (location 
and location-based routing) separate in general.  Some jurisdictions may 
require a local LIS to perform some emergency-related functions, but 
this need not be the case.  A client should be able to use a LIS of 
either type without having to modify its behavior.

You could also view this as preserving the simplicity of the LIS, except 
when regulators require it to be more complicated.

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Jun 2009 22:51:08 -0500

If the regulators do require this, then I think the option should also
exist for the LIS to simply return the destination URIs. This also
addresses the issues of what happens if LoST servers take a long time to
publically rollout.

Cheers
James

> Sent: Wednesday, 3 June 2009 1:40 PM
> To: Winterbottom, James
> Cc: Dawson, Martin; [email-masked]; Rosen, Brian
> >> location is 'good enough for routing'.  Basically, it involves a
lot
> > of
> >>> service (LoST) should apply weighted routing to the location
offered
> > by
> >>> overlap two or more routing boundaries and that the optimal
approach
> > is
> >>> analysis before providing the location*. The inevitable
consequence
> > of
> >>> information, also has to live in the LIS or be otherwise
accessible
> > to
> >>> URI. Any device not supporting it can fall back to looking for
LoST.
> > It
> >>> LoST server when the shape is a cell sector.  The discussion
itself
> > is
> >>> pretty specific to NENA, although it involves the fact that it
might
> > be
> >>>    indicating to the LIS how long the Device is prepared to wait
for
> >>> the emergencyRouting value in responseTime, and the fact that it
is
> > in
> >>> matter) as an all purpose "purpose" (as it were) and wasn't hung
up
> > on

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 2 Jun 2009 23:40:52 -0500

It wasn't the fact that it was onerous.  I could care less either way.  I'm talking about providing unexpected results.  

HELD defines a contract and emergencyRouting and emergencyDispatch are (to me*) clearly related to response time alone.  Altering the semantics of these unilaterally has consequences.

Local policy can be invoked on a lot of things, but only within the bounds of reasonableness - if the location is still usable and accurate, then that's OK, but that's not the story I'm hearing on the NENA list.

--Martin

* sure, we can (and maybe should) discuss whether greater clarity is needed...

> Behalf Of Richard Barnes

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 2 Jun 2009 23:46:29 -0500

Hi Richard,

I think your document doesn't address the particular use case. Or maybe
it does - and I need to spend more than two minutes reading it.

I think there are assumptions that a) the LIS actually knows the
location with sufficient accuracy to unambiguously select the right
routing boundary and b) the LIS has access to all the relevant routing
boundaries in an a priori fashion.

In the use case under discussion, the LIS is providing an initial coarse
location fix - e.g. it does a cell/timing measurement and gets, say, a
1500m radius of uncertainty. No time to integrate multiple uplink timing
measurements, no time to indulge in AGPS procedures.

Given that area of uncertainty could encompass an arbitrary number of
routing area boundaries - particularly if you include the "holes" in
routing boundaries consideration, there is no practical way to identify
every possible routing region from LoST queries without, for example,
iterating through a grid of points encompassed by the area of
uncertainy.

In any case, this is just a back door way to provision LoST into the
LIS. There are much more optimal ways to do that than using the actual
LoST protocol.

It's no good dismissing this as an optional optimization. Of course it
is. However, the proposition in the NENA discussion was that LoST
queries only ever get done using a point argument. This forces the
situation where the LIS is the only place that can do the optimization.
This in turn begs the question of what value, beyond making the
emergency call initiation more complex than it has to be, the LoST
interaction adds. If LoST stays in the picture and its role is routing,
and it is, then it should be the node that retains the optimization
option.

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, 3 June 2009 1:09 PM
To: Dawson, Martin
Cc: Rosen, Brian; [email-masked]
Subject: Re: [Geopriv] HELD ResponseTime parameter with value
emergencyRouting

Martin,

--Richard

construct

---

From: Richard Barnes <[email-masked]>
Date: Wed, 03 Jun 2009 01:05:06 -0400

Martin,

I think we're in violent agreement.  The only expectation that the 
client can have by setting the responseTime parameter is that the LIS 
will respond in a time frame that matches it.

As long as a LIS can meet that expectation, though, it's free to do what 
it wants, according to the protocol.  Including returning a geography of 
its choosing (even in Martian coordinates!).

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 3 Jun 2009 10:30:53 -0400

I agree with this.  We're discussing what I think is North American specific
behavior, and not something appropriate for IETF standardization.  We're
implementing a process that exists now, that PSAPs want to keep, at least
for now, which is that the initial routing decision where there is a large,
known in advance area, like a traditional cell site or sector, is not
algorithmic, but made by people in a meeting, taking a number of factors
into account.

Again, very specific to NENA, we have a desire to make ALL actual routing
decisions in the LoST server, primarily so that, in disaster situations, we
have ONE place to change routing, and not several places. 

The notion that a cell site is represented by a point or a civic location
decided in advance by the operator and the affected PSAPs, in a meeting, is
what we do today, is reasonable, and is not in violation of the current HELD
text.  If some day the PSAPs wish the site to be represented by a shape, and
use the routing algorithm in the LoST server to choose a route based on that
shape, they can have the LIS operator change.  

Brian

> Sent: Wednesday, June 03, 2009 1:05 AM
> To: Thomson, Martin
> Cc: [email-masked]; Dawson, Martin; Rosen, Brian
> > It wasn't the fact that it was onerous.  I could care less either
> way.  I'm talking about providing unexpected results.
> >
> > HELD defines a contract and emergencyRouting and emergencyDispatch
> are (to me*) clearly related to response time alone.  Altering the
> semantics of these unilaterally has consequences.
> >
> > Local policy can be invoked on a lot of things, but only within the
> bounds of reasonableness - if the location is still usable and
> accurate, then that's OK, but that's not the story I'm hearing on the
> NENA list.
> >
> > --Martin
> >
> >>> -------------------------------------------------------------------
> --
> >> ---------------------------
> >>> -------------------------------------------------------------------
> --
> >> ---------------------------
> >>> [mf2]
> >>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 3 Jun 2009 20:24:44 -0500

Sorry Richard, Brian, I do not agree, despite whatever you perceive.

The point that I make is that a value of emergencyRouting in responseTime is not proof positive that the request being made is for the sole purpose of routing an emergency call.  Therefore, it would be misguided for an authority to mandate specific emergency behaviour in relation to a request just because this parameter is used.

--Martin

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 4 June 2009 12:31 AM
> To: 'Richard Barnes'; Thomson, Martin
> Subject: RE: [Geopriv] HELD ResponseTime parameter withvalue
> emergencyRouting
> 
> > > * sure, we can (and maybe should) discuss whether greater clarity
> is
> > needed...
> > >
> > >> Picking a service region (as I think your quote from Brian
> suggests
> > a
> > >>> LIS provided this location in, say, a cellular network.
> Proponents
> > of
> > >>> to determine which routing area the largest proportion (weight)
> of
> > >> the
> > >>> uncertainy falls into.
> > >>>
> > >>> this. An optional extension in the HELD response could contain
> the
> > >> PSAP
> > >>> In NENA, there is a discussion on the best form (shape) to send
> to
> > >> the
> > >>>    In the case of emergency services, the purpose of obtaining
> the
> > LI

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Jun 2009 09:04:03 -0400

That would be up to the LIS operator.  

I don't think that will be a problem.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, June 03, 2009 9:25 PM
> To: Brian Rosen; Richard Barnes
> The point that I make is that a value of emergencyRouting in
> responseTime is not proof positive that the request being made is for
> the sole purpose of routing an emergency call.  Therefore, it would be
> misguided for an authority to mandate specific emergency behaviour in
> relation to a request just because this parameter is used.
> 
> --Martin
> 
> > what we do today, is reasonable, and is not in violation of the
> current
> > HELD
> > use the routing algorithm in the LoST server to choose a route based
> on
> > that
> > > it wants, according to the protocol.  Including returning a
> geography
> > > of
> > > >> LoST queries to collect service boundaries for the relevant
> areas,
> > > some
> > > >> <http://tools.ietf.org/html/draft-barnes-ecrit-rough-
> loc#section-
> > 3>
> > > >>> associated with it. And this proposal was made on the basis
> that
> > > *the
> > > >>> This sentiment is reflected in the following from Brian's post
> on
> > > >> this
> > > >>> thread:
> > > >>>
> > > >>> Now - if this is a reasonable expectation, and I'm not saying
> it
> > > >> isn't,
> > > >>> then it must raise the question of why use LoST at all to do
> the
> > > PSAP
> > > >>> had to perform routing? I don't buy an interoperability
> argument
> > > >> against
> > > >>> From: [email-masked] [mailto:geopriv-
> [email-masked]]
> > On
> > > >>> Behalf Of Rosen, Brian
> > > >>> I have been okay with the current wording because I believed
> that
> > > the
> > > >>> ---------------------------------------------------------------
> --
> > --
> > > --
> > > >>> ---------------------------------------------------------------
> --
> > --
> > > --

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 4 Jun 2009 18:13:43 -0500

Hi Brian,

I think that it WILL be a problem.

Any modification or adjustment of location by the emergency authority degrades the quality of the location.  Hiding aside, the result that is provided by a LIS is the best available within the allotted time.  Anything else is worse.

Without proof positive that the request is intended for emergency use, an emergency authority that instructs the network operator to modify location will impose the negative consequences of that modification on non-emergency uses.

By taking this position, you force users of location into meta-reasoning.  This reasoning goes: "I think that my emergency authority has a mandate that dictates modification of location information.  Therefore I cannot use emergencyDispatch to request location for anything other than emergency calling because it might be altered somehow."  That extends to implementers having to avoid emergencyDispatch for all non-emergency cases because some jurisdiction, somewhere, might have such a mandate.

That's a dishonest way of forcing the interpretation you desire.

--Martin

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, 4 June 2009 11:04 PM
> To: Thomson, Martin; Brian Rosen; Richard Barnes
> Cc: [email-masked]; Dawson, Martin
> > > for now, which is that the initial routing decision where there is
> a
> > > large,
> > > > As long as a LIS can meet that expectation, though, it's free to
> do
> > > > what
> > > > >>> the device - and let's assume the relevant use case is that
> the
> > > > >> network
> > > > >>> weighted routing pointed out that the uncertainty around a
> cell
> > > may
> > > > >>> Those opposed to this approach said that, in fact, the
> location
> > > > >> should
> > > > >>> just be provided as point - ignoring the fact that
> uncertainty
> > is
> > > > >>> The real kicker in this is that the LIS *has to perform
> actual
> > > > >> routing
> > > > >>> dynamically. So now, the LoST data, including multiple
> adjacent
> > > > >> boundary
> > > > >>> URI lookup, why not have the LIS deliver it directly since
> it's
> > > > >> already
> > > > >>> routing that might be different than it would return for
> other
> > > > >> purposes.
> > > > >>>
> > > > >>> Please note the construction of the last sentence of the
> first
> > > > >> paragraph
> > > > >>> about "purpose".
> > > > >>>
> > > > >>> the "responseTime" parameter doesn't limit the LIS from
> sending
> > > an
> > > > >>> appropriate PIDF content as well as within an appropriate
> time
> > > > limit.
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > [mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 7 Jun 2009 23:15:38 -0400

Nah, it's much more useful than you think.  I suspect that 99.99% of the time, when you say "responseTime=emergencyRoute", you want EXACTLY what I'm proposing, even if it's not an emergency.

But it doesn't matter.  The text is good enough.  The PSAPs and the LIS operators can work it out.

Brian

> Sent: Thursday, June 04, 2009 7:14 PM
> To: Rosen, Brian; Brian Rosen; Richard Barnes
> Any modification or adjustment of location by the emergency authority
> degrades the quality of the location.  Hiding aside, the result that is
> provided by a LIS is the best available within the allotted time.
> Anything else is worse.
> 
> Without proof positive that the request is intended for emergency use,
> an emergency authority that instructs the network operator to modify
> location will impose the negative consequences of that modification on
> non-emergency uses.
> 
> By taking this position, you force users of location into meta-
> reasoning.  This reasoning goes: "I think that my emergency authority
> has a mandate that dictates modification of location information.
> Therefore I cannot use emergencyDispatch to request location for
> anything other than emergency calling because it might be altered
> somehow."  That extends to implementers having to avoid
> emergencyDispatch for all non-emergency cases because some
> jurisdiction, somewhere, might have such a mandate.
> 
> > > > I agree with this.  We're discussing what I think is North
> American
> > > > specific
> > > > implementing a process that exists now, that PSAPs want to keep,
> at
> > > > least
> > > > > client can have by setting the responseTime parameter is that
> the
> > > LIS
> > > > > > Local policy can be invoked on a lot of things, but only
> within
> > > the
> > > > > accurate, then that's OK, but that's not the story I'm hearing
> on
> > > the
> > > > > NENA list.
> > > > > >
> > > > > > --Martin
> > > > > >
> > > > > >> It actually isn't that onerous for the LIS to check whether
> a
> > > > given
> > > > > >> location is 'good enough for routing'.  Basically, it
> involves
> > a
> > > > lot
> > > > > of
> > > > > >> off-line computations, then only a polygon-in-polygon check
> at
> > > > query
> > > > > >> That said, it seems to me that whether the LIS applies such
> an
> > > > > >> algorithm
> > > > > >>> The NENA discussion hinged around the question of whether
> the
> > > > > routing
> > > > > >>> having to be solved. Public network operators already do
> this
> > > > > routing
> > > > > >>> necessary for the LIS to choose the shape of the response
> for
> > > > > >> emergency
> > > > > >>> Martin Thompson is worried about something that I seek
> advice
> > > on.
> > > > > >>>
> > > > > >>>    The "responseTime" attribute MAY be included in a
> location
> > > > > request
> > > > > >>>    could be either for routing a call to the appropriate
> PSAP
> > > or
> > > > > >>> the emergencyRouting value in responseTime, and the fact
> that
> > > it
> > > > is
> > > > > >> in
> > > > > >>> The LIS knows the purpose, and can reasonably be expected
> to
> > > > > respond
> > > > > >>> appropriately in both time and content.  Otherwise, we
> would
> > > need
> > > > > >>> LIS could use the emergencyRouting (or emergencyDispatch
> for
> > > that
> > > > > >>> -----------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > >>> -----------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --