I had volunteered to review the draft-antti-rfc2806-bis-08 draft.
My review is included in this email. The comments are mostly editorial and of clarification in nature. I'm using the text version for page numbers, not the
PDF. Most of them are in the Introduction section. I have not found any major
problems.
----------
1) (Editorial) Title: I believe the title should be "The tel URI for Telephone
Numbers" instead of "The tel URI for Telephone Calls" since a URI does not
imply that there is a call.
Section 2 "Introduction"
2) Page 2 (Minor)
The first paragraph gives the definition of a public telephone number,
instead of the definition of a telephone number. This is because it was
taken from E.164 which only discusses public telephone numbers. Since this
internet draft discusses both publice E.164 numbers and private numbers
(encoded in the "local" format in this internet draft), we should reword the
first paragraph as follows:
This document defines the URI scheme "tel". The "tel" URI describes
resources identified by telephone numbers. A telephone number is a
string of decimal digits that uniquely indicates the network termination
point. The number contains the information necessary to route the call
to this termination point.
3) Page 2 (Minor)
In the second paragraph, the term "circuit switched" should be replaced
by "telephone": a private telephone network can use circuit-switched
technology, or IP technology on a LAN. Similarly, the phrase
"or a landline circuit" should be replaced by "or a fixed wired terminal".
Add the following to the last sentence ", or to a telephone number resource".
4) Page 2 (Minor)
Add the following to the third paragraph "Furthermore, it does not refer to
a specific physical device, only to a telephone number".
5) Page 2 (Minor)
In the description of the Address-of-record or identifier, change the second
sentence to the following: "These numbers follow the rules in E.164 [4] for
public numbers. Private numbers follow the rules of the owner of the private
numbering plan."
6) Page 3 (Editorial)
In the first paragraph after the description of the dial string, change the
phrase "that the telephone number as identifier" to "the telephone number
identifier"
7) Page 3 (Minor)
In the second to last paragraph (begining with "There are at least", there
is a discussion on the use of dialers in telephony networks. This assumes
analog interfaces. In ISDN interfaces, typically, there is no "dialer".
A URI could be algorithmically converted to a qualified number (e.g., an E.164
number) to used directly by the PSTN. This would be typical for a PBX interface.
8) Page 3 (Minor)
Last paragraph says that reaching a PBX with a URI is not possible. This is
not the case as there is a description later on in the document describing
how to use the extension and isdn-subaddress to achieve this (both can
be used).
9) Page 4
Section 2.1 "Resolution" is empty.
Section 3
10) Page 4
The second descriptor in the context definition should be removed as agreed in
the meeting in San Francisco.
Section 5
11) Page 6 (Editorial)
Change "Their" to "their" in section 5 title.
12) Page 7
Section 5.1.2 does not describe what to do with non-numeric DTMF digits (A, B
C and D). This is NOT the same as the ISUP BCD-encoded A-F digits. Those
digits are defined in ITU-T Q.23. I would imagine that we want to prohibit
their use in a URI.
13) Page 7 (Minor)
Add the following to the last sentence of the first paragraph of 5.1.4 "unless
there is no way to represent the number with a global number". This will
cover the cases of private numbers.
14) Page 8 (Minor)
Remove the last paragraph (or at least the 2 contexes).
Annex A
15) Page 13 (Editorial)
Remove "While" at the end of the first paragraph.
16) Page 14 (Editorial)
Correct reference to "refsec:intro" (whatever that means).
17) Page 16
We should add a reference to RFC3261 section 19.1.6 to describe the
relationship between SIP URIs and Tel URIs.
18) Page 15 (Minor)
The description of Proxy translation encourages people to use URIs
like "sip:1234@foobar.com" and let the proxy "deal" with it. I tought
this is exactly what we did NOT want to encourage people to do since
it assumes a uniform dialing plan accross a whole proxy. This would force
the service providers to deploy as many proxies as there are
dialing plans which is very undesireable.
Rather, I would encourage people to use a phone-context (in a tel URI
or prefereably a SIP URI) that identifies the dialing context
explicitely. For example, it could be as follows: tel:1234;phone-context=
munich.example.com (or sip:1234;phone-context=munich.example.com@example.com;
user=phone).
With this approach, the service provider could assign a phone-context per
dialing plan and not require one proxy per dialing plan. A large number
of phones could be deployed, for example, in the Munich office by having
all the phones preconfigured with the phone-context=munich.example.com (of
course it could also be manually configured).
I fear that if we leave it as is, the phone manufactures will take the easy
way out and NOT allow for configuration of the phone-context which will
not make for easy deployment, especially when multiple regional offices with
different dialing plans are supported.
Informative References
19) Reference 9 and 10 are out-of-date: they should be February 2001. Additionaly
the title of reference 9 has changed slightly to "Notation for national and
international phone numbers, e-mail addresses and web addresses"
----
François AUDET, Nortel Networks
Tel: +1 408 495 3756