Subject: [IPTEL] Comments on RFC2806bis

From: [email-masked]
Date: Mon, 4 Mar 2002 17:47:50 EST

To all,

The latest draft of the revision to rfc2806 in draft-antti-rfc2806bis-02 
really looks good. I have the following comments on some of the text:

2. In the 7th paragraph (beginning "The approach pursued...") Extensions of a 
PBX can be specified if they are a part of the global number (i.e., when DID 
is used). Propose that the words "when direct inward dialing is not used" be 
added after "PBX".

5.1.2 Maybe it would be helpful to emphasize that, while the uri format does 
not support alphabetic characters, it is expected that the user agent would 
support entry of such characters by the user and translation based on some 
standard.

The mapping of alphabetic characters to numeric digits is in fact 
standardized in E.161 as well as in American National Standard T1.703-1995 
(R1999). However, it is still a good idea to not use this mapping as a basis 
for the uri. It is suggested that this final sentence be: "The URI format 
does not support this since the mapping of alphabetic characters to nurmeric 
digits is not completely uniform internationally, although there are 
standards addressing this mapping."

It is unclear why the second paragraph states that "F is currently not used." 
and "These do not designate the fourth column of the DTMF tone matrix." The 
term "Terminal number" is not the usual one used. These statements lead to 
confusion. In fact, ISUP defines the additional six values as "code 11, code 
12, ST, and 3 spares", not A-F. It uses the "1111" or "F" value. As shown in 
the ABNF, the digits of the global-number are limited to 0-9. While the 
digits of the local-number are shown as HEXDIGIT, it is unknown where this 
would be used for a tel:uri. It is suggested that this paragraph be reworded 
to: "Since called and calling party numbers are encoded in BCD in ISUP, this 
allows for six additional values per digit, sometimes represented as the HEX 
characters A through F. However, in accordance with E.164, they may not be 
included in global numbers. Their use in local numbers is not defined, but is 
not prohibited."

5.1.3 In the first paragraph, the phrase "if the client is properly 
configured" should be deleted. International numbers themselves are 
unambiguous. It is unrelated to the "configuration" of "the client".

In the second paragraph, it is unclear why the second sentence states that 
"some numbers may work from several networks but not from the whole world; 
these SHOULD be written in international form". Since it follows the first 
sentence, it is presumed to be referring to "local numbers". It is impossible 
to write a local number (which does not work everywhere) in "international 
form".

7.3 3rd paragraph: It is unknown why "/" is mentioned here as a possible 
character separator. In fact, in E.123, the "/" means something else. This 
mention here may confuse people.

7.4 While this section is interesting, it has nothing to do with the subject 
of the document and should be deleted. It might confuse someone into thinking 
that it has some impact on the uri.

7.5 To avoid confusion, the number 00123456789 in the example should not be 
referred to as a "local phone number". This sentence should say: "Tel URIs 
should, in general, not contain the local dialing prefixes such as the "00" 
in 00123456789..."

It might also be helpful here to mention that, according to E.164, the "+" in 
the writing of the international number actually means that an international 
prefix is required ("00" in this example).

8. The last example in this section should show a valid E.164 number with a 
valid US area code, even though the number/letters displayed may contain 
extraneous characters to spell a word, as is the common practice (at least in 
the US). I would expect that an implementation might discard a uri that it 
knows to be incorrect, such as one beginning with +1 that is not followed by 
exactly 10 digits. (Not required to do this, but it might.) The example 
should be:

    a href="tel:+17034383785">1-703-IETF-RULZ-OK</a

(Of course, the above needs the angle brackets at the beginning and end. Does 
anyone know how to get AOL to stop turning my examples of html into hidden 
HTML tags?)

References: FED-STD-1037C should be replaced by ANSI T1.523-2001, 
Telecommunications Glossary, which replaced it.

Mike Pierce
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel