Subject: RE: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 5 Jul 2005 09:53:29 -0400

Richard,

Did not understand your comment reference 911 emergency access number
and NYPD response contact.  Yes, 911 is the designated emergency number,
but depending on location the call gets routed to different PSAPs.  I
don't know the specifics of NY City or what the example is trying to
show.  But, it is certainly plausible that a call to 911 could get
routed to the NYPD if they were operating the PSAP.  So, I would expect
a query to a database might return a specific address.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Stastny Richard
> Sent: Sunday, July 03, 2005 10:14 AM
> To: Andrew Newton; [email-masked]
> Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt 
> 
> Hi all,
>  
> nice draft ;-)
>  
> Thanks for incorporating many potential emergency services 
> (sos identifiers), but I fear that this list will be open ended.
> So why not add a service discovery query type as I already 
> proposed to Hennings draft "FindEconServiceTypes" to discover 
> the service types available at a given location.
>  
> next:issue: I am not able to completely understand the 
> following paragraph in section 3.3.1
>    "The primary information relayed in this result are URIs 
> to be used to
>    make contact with emergency services.  This result may contain
>    multiple URIs.  These URIs are not provided in preference 
> order, and
>    clients MUST NOT attach preference to any URI based upon 
> its position
>    in the list.  Server MUST NOT provide more than one URI of 
> the scheme
>    in a result (e.g. two "sip:" URIs are not allowed).  The purpose of
>    providing multiple URIs is to offer multiple methods of contact."
>  
> Is it now one or more URIs?
> IMHO what you may mean here is that for one service type not 
> more than one URI may be given, but more then one service 
> types may be replied for a query. See also the dicussion with 
> Henning on LUMP, where one queries for "ecc" and gets back a 
> list of "fire", "police", etc.
>  
> In any case, what is missing in the resulttype 
> "emergencyContactType" is the "serviceType"
> which is more important then the "Displayname"
>  
> Talking about a hierarchy of emergency services as prposed by 
> Henning in LUMP e.g. emergency,police and your proposal with 
> a flat structure e.g. "ecc," "fire", "rescue"
> and also looking at the example you give by querying in the 
> U.S. for "police" and getting back the "NYPD"
>  
> I have a serious problem here:
>  
> Either the example is not well choosen or there is a 
> potential (legal or scope) problem lurking here.
>  
> We are talking withn ECRIT about "emergency services"
> What an "emergency service" or an "emergency number" is, is 
> very well defined in national laws and/or ordinances.
>  
> I always thought (please correct me if I am wrong) that in 
> the U.S. there is only ONE emergency number, namely "911", 
> e.g. in the U.K there is "999"
>  
> So basically if I query for "police" or any other service 
> type in the US, I have to get back an "ecc" service type and 
> not the "NYPD".
>  
> Now in some European countries (a.g in Austria) the situation 
> IS different. Service type "ecc"=112 AND e.g. "police"=133 
> CO-EXIST in parallel (by law), which is BTW also a problem 
> with Hennings hierachical approach, because there exists in 
> addition to emergency and emergency.police also an 
> emergency.emergency (or emergency.ecc)
>  
> If you wanted to describe in your a example the possibility 
> to call the police in ADDITION with a NON-EMERGENCY call, 
> this may be useful, because also in Austria there exists the 
> possibility to call the e.g. local police station direct, if 
> you have a non-emergency request. It could be useful to 
> provide also a mapping for this, but IMHO then the whole 
> issue has a potential to get out of hand.
>  
> In any case, an additional indicator if the URI provided is 
> an emergency URI or not is required.
>  
> regards
> Richard
> 
> ________________________________
> 
> Von: [email-masked] im Auftrag von Andrew Newton
> Gesendet: Do 30.06.2005 15:06
> An: [email-masked]'
> Betreff: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt 
> 
> 
> 
> Hannes, Ted, and I have put together another version of our 
> ecrit- iris draft.  This is an XML-based interface capable of 
> using UDP for fast exchanges and DNS SRV records for 
> load-balancing and robustness.
> 
> We made the following changes:
>    o Added a validation flag so that the query interface may 
> be used for address validation.
>    o Updated the list of sos identifiers based on Richard's email.
>    o Beefed up the introductory section for readability 
> (though more of that will have to be done).
> 
> -andy
> 
> Begin forwarded message:
> 
> > From: [email-masked]
> > Date: June 28, 2005 3:50:02 PM EDT
> > To: [email-masked]
> > Subject: I-D ACTION:draft-hardie-ecrit-iris-01.txt
> > Reply-To: [email-masked]
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> >
> >
> >     Title        : An IRIS schema for Emergency Service contact URIs
> >     Author(s)    : T. Hardie, et al.
> >     Filename    : draft-hardie-ecrit-iris-01.txt
> >     Pages        : 25
> >     Date        : 2005-6-28
> >
> > This document describes an XML-based protocol for passing location
> >    information to a server that returns emergency service contact 
> > URIs.
> >    It is intended to fit within a larger framework of standards.
> >    Specifically, it presumes the existence of a URI scheme 
> appropriate
> >    for signalling that emergency service is required and 
> > distinguishing
> >    among emergency services if appropriate.  It also 
> presumes that an
> >    entity requesting this response will be able to handle the URIs
> >    returned as input to appropriate handlers.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a 
> message to 
> > [email-masked] with the word unsubscribe in 
> the body of 
> > the message.
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> > username "anonymous" and a password of your e-mail address. After 
> > logging in, type "cd internet-drafts" and then
> >     "get draft-hardie-ecrit-iris-01.txt".
> >
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >     [email-masked].
> > In the body type:
> >     "FILE /internet-drafts/draft-hardie-ecrit-iris-01.txt".
> >
> > NOTE:    The mail server at ietf.org can return the document in
> >     MIME-encoded form by using the "mpack" utility.  To use this
> >     feature, insert the command "ENCODING mime" before the "FILE"
> >     command.  To decode the response(s), you will need "munpack" or
> >     a MIME-compliant mail reader.  Different MIME-compliant mail 
> > readers
> >     exhibit different behavior, especially when dealing with
> >     "multipart" MIME messages (i.e. documents which have been split
> >     up into multiple messages), so check your local documentation on
> >     how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > Content-Type: text/plain
> > Content-ID: <[email-masked]>
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
> >
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> 
> _______________________________________________
> 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: "Stastny Richard" <[email-masked]>
Date: Wed, 6 Jul 2005 13:08:33 +0200

Andy wrote:

> > I do not think that the round trips are a problem, because
> > service discovery should take place at connect time and
> > not at the time you make an emergency call. Do not
> > forget that there may also be a emergency service
> > reachability indicator. This would also happen at
> > connect time.
> 
> What do you mean by "connect time"?  Is this when a device acquires
> an IP address on a network?
> And what is the reachability indicator?

Yes
Sorry for being unprecise here:

The basic idea is that when the device acquires the IP address
(and also get eventually its location) to contact the mapping
database to retrieve the services available and also tries to
contact (silently) the PSAP or ESRP to provide the end-user
or device with an indication that the emergency service is reachable
This is one of the original requirements (I forgot which number)

This also needs to be discussed in Paris also, because
this has to be repeated every time the device updates its 
location (or after a certain time-out)

> 
> > So we have three issues here:
> >
> > 1. Access to emergency numbers (ECRIT)
> > 2. Access to police, etc in non-emergency cases (ECRIT?)
> > 3. Access to other non-e.164 numbers (short codes) (IPTEL?, ENUM?)
> 
> This sounds like a discussion topic for Paris.

Agreed, the problem here is that IPTEL wnts to close down
Maybe a potential new WG on VoIP peering.

-Richard