Subject: [Ecrit] introduction section (<draft-schulzrinne-ecrit-requirements-01.txt>)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 9 Aug 2005 11:16:20 +0200

hi all, 

please find my comments below (#). 

i think the introduction is too long and repeats requirements. 

1.  Introduction

   Users of telephone-like services expect to be able to call for
   emergency help, such as police, the fire department or an ambulance,
   regardless of where they are, what (if any) service provider they are
   using and what kind of device they are using.  Unfortunately, the
   mechanisms for emergency calls that have evolved in the public
   circuit-switched telephone network (PSTN) are not quite appropriate
   for evolving IP-based voice, text and real-time multimedia
   communications.  This document outlines the key requirements that end
   systems and network elements such as SIP proxies need to satisfy in
   order to provide emergency call services that offer at least the same
   functionality as existing PSTN services, with the goal of making
   emergency calling more robust, cheaper to implement and multimedia-
   capable.

   In the future, users of other real-time and near real-time services
   may also expect to be able to summon emergency help.  For example,
   instant messaging (IM) users may want to use such services.  IM is
   particularly helpful for hearing-disabled users (RFC 3351 [4]) and in
   cases where bandwidth is scarce.

   This document only focuses on end-to-end IP-based calls, i.e., where
   the emergency call originates from an IP end system, (Internet
   device), and terminates to an IP-capable PSAP, done entirely over an
   IP network.

# ------ i would shorten the following paragraphs below by just saying
something like. 
Section 2 defines terminology, Section 3 lists high-level requirements,
etc... 

   This document identifies functional and security issues for
#                                          ^^^^^^^^^^^^^^^^
#  in fact this document does not specify security requirements. 

   determining the correct emergency identifier, for identifying the
   appropriate PSAP (emergency address) and for identifying the caller
   and its current location.

   Emergency calls need to be identified (Section 6).  Emergency
   identifiers are used by the emergency caller to declare a call to be
   an emergency call.  The device MUST recognize the emergency
   identifiers used and convert them to an emergency address to guide
   the call to a PSAP.  The emergency address MUST be a predefined
   "sip", "sips" or "tel" URI scheme.

   Emergency calls need to be routed to the appropriate PSAP (ref.
   Section 6).  Several terms are used for causing the call signaling to
   reach the geographically appropriate PSAP.  This has been referred to
   as call routing, (PSAP) lookup or location mapping, all capturing
   aspects of the problem.

   Emergency calls need to identify who placed the call (Section 7).  In
   most jurisdictions, callers do not have a choice as to whether they
   want to reveal their location or identity; such disclosure is

Schulzrinne & Marshall    Expires November 2, 2005              [Page 3]

Internet-Draft             ECRIT requirements                   May 2005

   typically mandated by law.

   Emergency calls need to identify the location from which the call is
   initiated (Section 5).  The caller location needs to be identified
   for two purposes, namely to route the call to the appropriate PSAP
   and to display the caller location to the call taker to simplify
   dispatching emergency assistance to the correct location.

   Emergency calls may not be subject to access restrictions placed on
   non-emergency calls.  Also, some call features may interfere with
   emergency calls, particularly if triggered accidentally (Section 7).

---

ciao
hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Aug 2005 05:38:01 -0400

I agree that this can be shortened, but would like suggesting keeping 
text that allows the reader to identify how our overall sequence of 
steps work. This is far from obvious to most "bystanders" and we don't 
have another document to point to. Below, I trimmed stuff I think is 
unncessary details and did some re-ordering.

>    This document identifies functional and security issues for

[should be in section order]

>    an emergency call.  
>    Section 6).  

>    Emergency calls need to identify who placed the call (Section 7).