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

From: "Stastny Richard" <[email-masked]>
Date: Sun, 3 Jul 2005 16:14:28 +0200

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jul 2005 09:40:06 -0400

Hi Richard,

Thanks for reading the draft. Based on your feedback, I can already  
see changes we need to make.  Many of the concerns you raise are not  
specific to ECON or LUMP, but are general issues that need to be  
resolved by this working group.  My comments are in-line:

> nice draft ;-)

Thanks.

> (sos identifiers), but I fear that this list will be open ended.

We added the new identifiers because they did not seem to have  
immediate overlap with the existing ones.  That doesn't mean it is  
the final list.  We should strive for a comprehensive and unambiguous  
list that is as universal as possible for the purposes of  
internationalization (or more specifically, having those identifiers  
localized by the client).

> available at a given location.

As I see it, the problem with this type of query is that it adds  
latency and can lead to internationalization problems.  Is this use  
case for such a query?

1  User -> Service :: Find location map for service XXX.
2  Service -> User :: Service XXX is unknown.
3  User -> Service :: What are the service types supported?
4  Service -> User :: Here is the list?
5  User -> Service :: Find location map for service YYY.

That is a lot of round trips and there is still the potential that  
the user won't understand a thing on the list (if it isn't in their  
language).

> Is it now one or more URIs?

This relates to URI scheme types, such as sip: vs. xmpp: etc...

> a list of "fire", "police", etc.

This sounds like a reasonable restriction.

> which is more important then the "Displayname"

That is an excellent suggestion.  The purpose of the display name is  
for user feedback.  Even if they don't really understand it, when the  
UI updates with the display name it gives feedback and suggestion  
that a phase of the emergency signaling/calling process has completed.

> in the U.S. for "police" and getting back the "NYPD"

I don't think we (the co-authors of the draft) have any rigid opinion  
about this being flat or hierarchical.  If a hierarchical structure  
works, then that is fine.  We are concerned with adding latency, too  
much complexity (not to imply that you get this with hierarchy), and  
user experience (e.g. internationalization).

> also an emergency.emergency (or emergency.ecc)

In a hierarchical approach, would wild card semantics help?  Such as:

    emergency.*         meaning "I have an emergency and want anybody  
to respond"
    emergency.police    meaning "I have an emergency and need the  
police"

> the whole issue has a potential to get out of hand.

With regard to getting out-of-hand, I tend to agree.  And do we  
really want to provide a use case for people with non-emergencies  
using a resource needed for emergencies?

> URI provided is an emergency URI or not

In the case above where you have outlined that non-emergency URIs can  
be returned, I would agree.  But if the service is specifically  
limited to emergencies, then wouldn't it be reasonable to assume that  
all URIs are for emergencies?

Thanks for reading the draft.

-andy