Subject: [Sipping] Comments on tel:uri

From: [email-masked]
Date: Thu, 20 Jun 2002 14:16:22 EDT

To all.

Comments on draft-antti-rfc2806bis-05:

Section 3

The statement that URI comparisons are case-sensitive (except the scheme and 
parameter names) seems incorrect. In the ABNF, the only thing which can be 
alphabetic besides these two things is the domain, for which the comparison 
should also be case-insensitive.

Section 4 ABNF

Since Section 5.1 now states that "Local numbers MUST be tagged with a 
phone-context", the square brackets should be removed from "context" in 
"local-number".

The meaning of "global-number-part" is not clear since it is used for two 
distinct purposes. When used in the "global-number", it must be a full, valid 
E.164 number. When used in the "descriptor" in the "context" it is expected 
to be only the first part of an E.164 number, but, in fact, could be 
something else, even though it begins with a "+". The ABNF should show these 
two cases differently, perhaps as follows:

global-number = e164-number [isdn-subaddress]
e164-number = "+" 4*phonedigit ; must be a valid E.164 number, 4-15 digits
descriptor = domainname / global-number-part
global-number-part = "+" 1*phonedigit ; may be leading digits of E.164 number

(See comment below about use of "+" in the descriptor to distinguish between 
a number and a domain.)

Section 5.1.3

In the first paragraph, it should be considered whether the definition of 
"global (international) number" should also include the notion that it is 
"dialable" from international origination points (see comment below regarding 
toll-free numbers).

In the third paragraph, the first sentence which states "The phone-context 
parameter can be used to unambiguously identify..." should be reworded, since 
other places state that it MUST be used with the local number and other 
statements presume that it always "unambiguously" identifies the context. It 
should say: "The phone-context parameter MUST be used with the local context 
and SHOULD be chosen to unambiguously identify the local context ..."

Something additional should be said about how contexts should be selected to 
help ensure that they are unambiguous. Currently, there is no known way to 
guarantee uniqueness, short of an international assignment authority such as 
IANA. The 7th paragraph states that an organization "can choose any number 
under its control", but, in general, this is not sufficient to guarantee 
uniqueness, since it is not always clear what prefix numbers are "under the 
control" of  an organization. The following sentences may help: "When a 
global number prefix is used as the context, it SHOULD be chosen in a way 
that ensures that it is unique. The user SHOULD make sure that all possible 
E.164 numbers beginning with the chosen prefix are under their control and 
are considered to be within the context being represented. It is not required 
that all E.164 numbers within the context actually begin with the chosen 
prefix."

The third paragraph goes on to assume that the context is the "prefix" of an 
international number and it is coded beginning with "+", but it also states 
that it "does NOT in any way indicate a prefix that turns the local number 
into a global number". There is no statement that the leading digits of a 
valid E.164 number MUST be used for the context. The requirements for forming 
a context are very confusing. If the context does not have to be an E.164 
number, then it should not start with "+". If it can be any string of numbers 
and the user is only recommended to pick the leading digits of some E.164 
number that they are assigned, then it should be described as such. If it 
MUST be the leading digits of a valid E.164 number assigned to that user, 
then it should state this.

In any of these cases, it is not appropriate to begin the context with "+", 
since this contradicts the statement in the 1st paragraph about the use of 
"+" to identify a global number which "MUST be composed with a country code 
and national number as specified in E.123 an E.164." If "+" is being used in 
this case only as a way to distinguish between a number and a domainname, 
this should be made clear (or another character used).

The 7th paragraph gives an example of specifying two context values together 
using different global prefixes (US and Germany). While such coding is 
possible, there is no known use for this capability in any application of the 
tel:uri within call setup or call control signaling in general. Based on the 
definition of "context", it should only support inclusion of a single global 
prefix.

In the 8th paragraph, the statement that 911 "should" be labeled with the 
context "+1" should be modified. How it is labeled will depend on other 
descriptions of this service. For example, it may be necessary to use the 
originating phone number or a designation of the emergency service area as 
the context to allow other functions related to 911 service. At the minimum, 
the word "should" needs to be changed to "may" in the example.

The final sentence in Section 5.1.3 should be reworded to say: "As noted 
earlier, numbers which can be represented as valid E.164 numbers MUST NOT be 
represented as local numbers plus a phone-context."

There is no indication of how to code numbers which are in the global number 
format but which can not be dialed internationally, such as the toll-free 
numbers in most countries. For example, an 800 number in the US could be 
coded as either:

tel:+1-800-456-6789
or
tel:800-456-6789; phone-context=+1

The statement in the 1st paragraph of Section 5.1 could be interpreted to 
mean that the first form above must be used. However, one could interpret 
other statements to indicate that it should be represented in the second 
form, since it is not dialable internationally. It is not clear how this 
should be resolved.

Section 5.2

It is not clear what it means to say that the isdn-subaddress parameter is 
"mandatory" and "a client MUST reject the URI if it cannot interpret ISDN 
subaddresses". The ABNF shows it correctly as an optional part of the 
tel:uri. The statement probably means that "interpretation of the parameter, 
if present, is mandatory". However, this is not always correct. In ISDN, the 
network equipment never interprets the subaddress, and it is ignored by a 
destination terminal which does not itself have a subaddress assigned. This 
statement of procedures should be deleted from the tel:uri draft, since it 
would be the subject of specific procedures or services which use the 
tel:uri. For example, a client that is providing a gateway function to ISUP 
may be required to convert the tel:uri in SIP to the Called Party ID in ISUP 
including the subaddress, but it would never be required to interpret the 
subaddress.

Section 6

In the 1st example, the phrase "capable of receiving voice calls" should be 
deleted, since this information is not included in or implied by the tel:uri 
as it was in the original RFC 2806.

In the 3rd example, it is unknown what the phrase "IBM tie line numbering 
system" refers to. In fact, the example seems to be one of a private network 
with its own internal numbering system which is different from the "public" 
E.164 numbering, although the extension numbers (final 4 digits) are often 
the same. It is not a "tie-line" system.

It is suggested that the statement in the 3rd example should read: "The URI 
describes a local phone number that is valid within a private network which 
uses 7-digit internal dialing in which the first three digits (863) are not 
the same as the "exchange code" portion (784) of the E.164 number. In these 
cases, the final four digits of the internal number are usually the same as 
the final four digits of the E.164 number used to reach the same subscriber. 
In order to uniquely represent this context, the network administrator has 
chosen the global number prefix of 1-914-784 since it is known that all E.164 
numbers beginning with these leading digits are within the context."

Section 7.4

The example of an E.164 number should be modified to show a valid number (10 
digits in the world zone 1). It would be better to correct this to show a 
number like +17032345678.

The final paragraph about overlap makes sense (requiring conversion from 
overlap to en-bloc before constructing the tel:uri), but it appears to 
contradict the current draft for overlap which seems to depend on using the 
tel:uri to send partial numbers in the INVITE. If that plan for overlap 
progresses, then it is necessary to include appropriate coding in the 
tel:uri. This requires the tel:uri to include explicit coding to indicate 
whether the number included is or is not a complete number. Using ISUP as a 
guide, this could be a distinct terminator character in the phonedigit 
string. In any case, this paragraph should be deleted.

Section 8

The 2nd example (of an HTML page presumable accessible internationally) would 
lead to confusion if used as shown. It is suggested that the example be 
enhanced to show:

Telephone (if dialing in Finland): <a href="tel:+3583551234567">(0555) 
123-4567</a>

Mike Pierce
Artel