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

From: Ted Hardie <[email-masked]>
Date: Mon, 16 May 2005 18:38:07 -0700

Andy, Hannes, and I put this together for discussion; sorry that we
did not make the week-prior deadline, but hopefully we can at
least have hallway discussion on some of the ideas.
			regards,
				Ted

>To: [email-masked]
>From: [email-masked]
>Date: Mon, 16 May 2005 15:38:39 -0400
>Subject: I-D ACTION:draft-hardie-ecrit-iris-00.txt
>X-BeenThere: [email-masked]
>Reply-To: [email-masked]
>List-Id: i-d-announce.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>	<mailto:[email-masked]?subject=unsubscribe>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>	<mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>X-QUALCOMM-AV: Sophos AV Testing
>
>
>
>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-00.txt
>	Pages		: 23
>	Date		: 2005-5-16
>
>This document describes an XML-based protocol for passing location
>    information to a server that returns emergency service contact URIs.
>    It is based on IRIS, the Internet Registry Information Service, and
>    starts from the premise that the search for emergency service
>    contacts can be modelled as a database search that uses geolocation
>    or civic location as input and returns one or more contact URIs as
>    output.  It is intended to fit within a larger framework of
>    standards. specifically, it presumes the existence of a URI scheme
>    appropriate for signaling 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-00.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-00.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-00.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.
>
>
>[The following attachment must be fetched by mail. Command-click the 
>URL below and send the resulting message to get the attachment.]
><mailto:[email-masked]?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-hardie-ecrit-iris-00.txt>
>[The following attachment must be fetched by ftp.  Command-click the 
>URL below to ask your ftp client to fetch it.]
><ftp://ftp.ietf.org/internet-drafts/draft-hardie-ecrit-iris-00.txt>
>_______________________________________________
>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

---

From: John Morris <[email-masked]>
Date: Mon, 16 May 2005 22:36:07 -0400

Ted,

One thought:  I can understand why you do not want to convey or imply 
a preference among multiple methods of contact (and thus multiple 
URIs).  Certainly, ideally, a PSAP could handle multiple contact 
methods equally well.  But what about scenarios where they cannot -- 
like today, some 911 calls end up going over the PSAP's 
administrative telephone line, which is a distance second choice 
compared to calls coming in "normally".  Is there possible value in 
(at the risk of adding complexity) allowing an optional 
<AltEmergencyContact> in addition to the <EmergencyContact> element 
(both of which could allow multiple URIs).  The Alt designation would 
strongly convey that the Alt URIs are greatly disfavored contact 
methods, but are still usable as a last resort.  With your approach, 
a PSAP would not (hypothetically) provide an e-mail URI because 
e-mails are really sub-optimal ways to initiate a 911 report.  With 
my suggestion, the PSAPs might provide 3 favored URIs, and a couple 
of disfavored ones like e-mail.  And then in some odd scenario 
someone who can really only send e-mail can still get through.

(Maybe e-mail is not the best example, but you get the idea -- 
perhaps a PSAP might say that any and all voice-based or TTY-based 
contact methods are greatly favored, but IM is also possible).  Just 
a thought.

John

At 6:38 PM -0700 5/16/05, Ted Hardie wrote:
>>of the message. You can also visit 
>>https://www1.ietf.org/mailman/listinfo/I-D-announce
>>[The following attachment must be fetched by mail. Command-click 
>>the URL below and send the resulting message to get the attachment.]
>>[The following attachment must be fetched by ftp.  Command-click 
>>the URL below to ask your ftp client to fetch it.]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 May 2005 08:17:07 -0400

There is a concept of "default route" in the current emergency calling
system in North America.  You use that route when your actual route fails
for some reason.  A typical one is that the source location data doesn't
yield a valid route, or there is some kind of equipment failure.

I think the idea that there is a default route function is very useful.

Your idea, an alternate route, is different, and may also be useful.  It
somewhat depends on how PSAPs are interconnected to various networks.  If
there actually are multiple network connections that have different
addressing (and possibly protocol) mechanisms, then it may be useful to
include them.

An example would be a PSTN (tel uri) number as opposed to a sip uri.  It may
be, for example, that the sip uri routes over the Internet, but the tel uri
routes over the PSTN to a private IP connection to the PSAP.  "Dialable"
telephone numbers for emergency calls are generally frowned upon, because of
abuse issues, but they may still be preferable to loss of connections when
some facilities fail.  As we know, while the core of the Internet is very
unlikely to fail even in major disasters, we do have problems with access
networks, and PSAPs are going to be on access networks.  Hopefully, they
will be engineered to be highly reliable, but alternate routes may still be
useful.

If you got both a default route and an alternate route, you would probably
use the alternate route first, and then the default route.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Morris
> Sent: Monday, May 16, 2005 10:36 PM
> To: Ted Hardie
> Cc: [email-masked]
> Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-00.txt
> 
> Ted,
>