Subject: [Ecrit] Finishing the ECRIT Requirements Work

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 23 Jul 2006 13:47:28 +0200

Hi all,

based on the WGLC comments of the ECRIT requirements draft we concluded 
that the document is as good as finished. I reviewed the document again 
and found a few minor bugs that got introduced with a recent terminology 
alignment with the Service URN draft. Some of you might recall that we 
had a severe terminology problem with the terms dial strings, emergency 
identifiers, etc. The requirements draft contains the updated 
terminology but the text in Section 6 seems to suffer from a few 
cut-and-paste errors.

Hence, I have a few simple text replacement suggestions:

Change from:

"
    Id1.  Emergency service identifier support: The mapping protocol MUST
       be able to return one or multiple emergency service identifiers in
       response to a query.

       Motivation: Since there is a need for any device or network
       element to recognize an emergency call throughout the call setup,
       there is also a need to have the mapping protocol provide support
       for such an identifier.  This is regardless of the device location
       or the ASP/VSP used.  An example of this kind of identifier might
       be the emergency service URN, 'urn:service:sos'.

"

to:

"
    Id1.  Emergency dial string support: The mapping protocol MUST
       be able to return one or multiple emergency dial strings in
       response to a query.

       Motivation: Since there is a need for any device or network
       element to recognize an emergency call throughout the call setup,
       there is also a need to have the mapping protocol provide support
       for dial strings.  '911' is an example of such an emergency dial
       string.

"

If we make this change then we can also delete requirement Id1 since it 
is then covered by Id4.

Change from:

"
Motivation: Any signaling protocol requires the use of some
       identifier to indicate the called party, and the user terminal may
       lack the capability to determine the actual emergency address
       (PSAP URI).
"

to:

"
Motivation: Any signaling protocol requires the use of some
       identifier to indicate the called party, and the user terminal may
       lack the capability to determine the actual emergency identifier.
"

Requirement Id4 and Id9 needs to be merged. Id9 is a subset of Id4.
You might want to reuse the motiviation text from Id9 in Id4.

Minor issue in Section 7:

Change from:

"
A proposed mapping protocol is outlined in the document
    I-D.hardie-ecrit-lost [9].
"

to:

"
A proposed mapping protocol is outlined in [9].
"

Ciao
Hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Jul 2006 10:24:14 -0400

See inline.

On Jul 23, 2006, at 7:47 AM, Hannes Tschofenig wrote:

> If we make this change then we can also delete requirement Id1  
> since it is then covered by Id4.
>

This is probably lost in the history of the draft somewhere, but I'm  
guessing that this actually refers to the ability to return multiple  
PSAP URLs.

I have to admit that, on re-reading, I find that the various  
identifier definitions in the draft are less than crisp and easy to  
distinguish, as the word "identifier" is used rather liberally. I  
think this needs to be cleaned up since the terminology section is  
probably the part that other documents should refer to, long after  
the requirements themselves have become uninteresting.

I think we should define these terms:

service number: The service number is a string of digits used to  
reach the service. It is the number typically dialed on devices  
directly connected to the PSTN and the number reserved by national or  
regional numbering authorities. The service number may depend on the  
location of the caller. For example, the general emergency service  
number in the United States is 112 and the poison control service  
number is 18002221222. In most cases, the service number and dial  
string are the same; they may differ in some private phone networks.  
A service number may be carried in tel URLs, along with a context  
identifier [RFC].

service dial string: The service dial string identifies the string of  
digits that a caller must dial to reach a particular (emergency)  
service. In devices directly connected to the PSTN, the service dial  
string is the same as the service number and may thus depend on the  
location of the caller. However, in private phone networks, such as  
in PBXs, the service dial string may contain a prefix to reach an  
outside line. For example, in a hotel, the dial string for emergency  
services in the United States might be 9911. Service dial strings are  
outside the scope of this document.

service identifier: The service identifier describes the emergency  
service independent of the user interface mechanism, the signaling  
protocol that is used to reach the service and the caller's  
geographic location. It is a protocol constant and used within the  
mapping and signaling protocols. An example is the service URN [].

service URL: The service URL is a routable URL that contains the  
address of the PSAP or other emergency service. It depends on the  
specific signaling or data transport protocol used to reach the  
emergency service. Examples include SIP, XMPP and mailto URLs.

We could also add a table to make this clearer:

           depends on location?   depends on protocol?  user- 
visible?     example protocol usage
service number:        yes               no                 
yes           tel URL
service dial string:   yes               no                 
yes           SIP dial string
service identifier:    no                no               
unlikely        LoST, SIP
service URL:           no                yes              
unlikely        SIP request URI

--- end text ---

For concreteness, we could also replace each "service" with  
"emergency service".

Note that this reflects the discussion we had in the context of the  
LoST draft. The requirements draft defines, but never uses, the term  
ESI. I would drop this term as it just adds confusion.

> You might want to reuse the motiviation text from Id9 in Id4.

I think we should simply have one requirement for each identifier  
noted above, in the same order.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Jul 2006 09:51:01 +0200

Hi Henning,

The most important question:
Who is going to make the draft update and when can be group read the 
final result?

Please find my comments inline:

Henning Schulzrinne wrote:
>> If we make this change then we can also delete requirement Id1  since 
>> it is then covered by Id4.
>>
> 

Currently the requirement for multiple PSAP URIs is covered by Ma7.

> 
> I have to admit that, on re-reading, I find that the various  identifier 
> definitions in the draft are less than crisp and easy to  distinguish, 
> as the word "identifier" is used rather liberally. I  think this needs 
> to be cleaned up since the terminology section is  probably the part 
> that other documents should refer to, long after  the requirements 
> themselves have become uninteresting.

I agree.

> service number: The service number is a string of digits used to  reach 
> the service. It is the number typically dialed on devices  directly 
> connected to the PSTN and the number reserved by national or  regional 
> numbering authorities. The service number may depend on the  location of 
> the caller. For example, the general emergency service  number in the 
> United States is 112 and the poison control service  number is 
> 18002221222. In most cases, the service number and dial  string are the 
> same; they may differ in some private phone networks.  A service number 
> may be carried in tel URLs, along with a context  identifier [RFC].
> 
> location of the caller. However, in private phone networks, such as  in 
> PBXs, the service dial string may contain a prefix to reach an  outside 
> line. For example, in a hotel, the dial string for emergency  services 
> in the United States might be 9911. Service dial strings are  outside 
> the scope of this document.
> 
> protocol that is used to reach the service and the caller's  geographic 
> location. It is a protocol constant and used within the  mapping and 
> signaling protocols. An example is the service URN [].
> 
> For concreteness, we could also replace each "service" with  "emergency 
> service".

I am fine with the terms. They are a generalized from of the 'emergency 
dial string' and 'emergency identifier' that are already in the draft.

> ESI. I would drop this term as it just adds confusion.

Fine with me.

> I think we should simply have one requirement for each identifier  noted 
> above, in the same order.
I would like to see the text first.

Ciao
Hannes