Re: Comments on RFC2806bis

Sorry for the delay in responding to these comments. I've updated the 
draft and will submit it shortly. Until it appears in the archives, you 
can find it at 
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-03.txt
and
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-03.ps 
(with changebars for non-trivial changes).

[email protected] wrote:

> 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".

Added.

> 
> 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."

Noted.

> 
> 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."

Added your wording and cleaned up the BNF. Lawrence, please indicate 
whether restriction to local digits is acceptable and if not, how this 
related to E.164.

> 
> 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".

Gone.

> 
> 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".

Cut-and-paste... Gone.

> 
> 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.

The whole paragraph seems to be more confusing than helpful, so I 
ditched it.

> 
> 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.

Same remnant of the old draft. History.

> 
> 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).

Rephrased.

> 
> 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?)

I changed the reference.

> 
> References: FED-STD-1037C should be replaced by ANSI T1.523-2001, 
> Telecommunications Glossary, which replaced it.
> 
> Mike Pierce
> _______________________________________________
> IPTEL mailing list
> [email protected]
> http://lists.bell-labs.com/mailman/listinfo/iptel