Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 3 Jan 2006 11:35:38 -0500

This statement is rather cryptic and should be rewritten.

I could take this to mean that, while call routing has been designed to
give priority to emergency calls in call processing, there is no
priority given to processing of location lookups of emergency versus
Starbucks.

Or is it just saying, if the functional element is not labeled
"emergency", it is not guaranteed to work?

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Andrew Newton
> Sent: Thursday, December 29, 2005 9:25 AM
> To: Roger Marshall
> Cc: [email-masked]
> Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components
> 
> 
> On Dec 28, 2005, at 7:20 PM, Roger Marshall wrote:
> 
> > Andy:
> >
> > Issue 10:  Design of Non-Emergency Components
> > (http://www.ietf-ecrit.org:8080/ecrit-req/issue10)
> >
> > "There are no requirements regarding the resilience of the 
> emergency 
> > call routing process as it relates to inputs that have not been 
> > designed for the purpose of emergency call routing."
> >
> > I'm not exactly sure what this issue is getting at... a couple of 
> > thoughts, 1. are we talking about resilience against inadvertant or 
> > on-purpose mis-use, (in which case it seems like a security 
> concern), 
> > or 2. do you mean, that the MP should be resilient in order 
> to support 
> > other types of use, besides just emergency use?
> 
> I think I just need to completely restate the concern.
> 
> Location information services and sighting services will be 
> present in the network for more than just emergency services, 
> such as the much talked about "Where is the nearest 
> Starbucks?" service. While the mapping service may only be 
> used and present for emergency call routing, these location 
> information services it relies upon have multiple uses. 
> Therefore, the  mapping protocol should not require addresses 
> in these services to be contorted or transmogrified in any  
> way that would reasonably conflict with these other services.   
> Thinking this through, perhaps this only applies to civic 
> addresses as geo-spatial addresses can be algorithmically 
> converted from one format to another.
> 
> -andy
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: Andrew Newton <[email-masked]>
Date: Wed, 4 Jan 2006 09:12:30 -0500

> "emergency", it is not guaranteed to work?

I wasn't trying to say that at all.

Essentially, there are databases of civic addresses within location  
information servers.  These databases may be used for multiple  
purposes and multiple applications.  The mapping protocol should not  
require that data within these databases be transformed or modified  
in any unusual or unreasonable way just so the mapping protocol may  
use the data.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Jan 2006 09:35:09 -0500

I am full agreement with this, and it's pretty important.  What is
interesting is that it represents a change from what is now done.
In North America, and in some other areas, the form of address used in the
emergency system is DIFFERENT from the form commonly used for other
purposes.  There are mostly historical reasons for much of the differences.
We have had quite a bit of resistance within the NENA community for the idea
that if we are to have a really effective system for all kinds of new
services based on IP, then the location information must be useful beyond
just emergency calls.  Location is commercially valuable, but only if the
information is not obscured in some way.  The current systems do.

We've started making this transition in the NENA i2 standard.  Location as
used within the IP world is a new form that is closer to common usage.  We
have translation to the existing form because we can't change out the
current systems wholesale (in fact i2 is designed to not require any changes
at the PSAP).

I do have to point out that you can't equate this with postal addresses; the
address for postal delivery is NOT always the address for dispatch of
emergency responders.  The database SHOULD be able to store enough data so
that translations are possible, because when you ask someone for a location,
they often respond with a postal address.  Specifically, for North America,
we need to have the jurisdictional community name (actual city/town/...),
which may be different from the post office name.  The database should store
both.  The mapping protocol only needs the jurisdictional community name.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Newton
Sent: Wednesday, January 04, 2006 9:12 AM
To: Michael Hammer (mhammer)
Cc: [email-masked]
Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components

-andy