Subject: Re: [Sipping] Comments on tel:uri

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Oct 2002 11:52:41 -0400

Catching up on old email... Thanks, Mike, for the extensive comments. I 
removed items that I just fixed without requiring further comment. To 
keep the message at reasonable length, I'm splitting up my responses.

[email-masked] wrote:
> 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.

Future parameters could also be textual. It seems that the CI/CS 
question for URIs is a perennial topic of discussion, made more 
"interesting" by the fact that the tel URI can show up in the user 
portion of the SIP URI, which is CS.

SIP URIs have become mainly CI, so I'll adjust accordingly, noting that 
parameters and values should use lower-case because of the usage in 
other protocols.

Regarding a previous email: Given the comparison issues when it appears 
in the SIP user portion, is there anything lost by restricting the order 
of parameters?

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

In general, ABNF is a poor vehicle for conveying semantic information. 
Since a parser can't, in general, decide whether a number is valid or 
not, I'm not sure it's worth the extra complexity, but I'll follow the 
suggestion for now.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Oct 2002 14:07:53 -0400

Working through the comments...

[email-masked] wrote on June 20:

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

Noted.

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

Made MUST strength.

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

I would put this somewhat differently: for many organizations, this is 
no problem, as they know precisely which numbers they own. (E.g., 
Columbia University owns all of +1 212 854, so they can safely use 
this.) Which cases did you have in mind where an organization might lack 
such certainty?

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

Added, more or less.

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

It says a "global number is identified by a +". Logically, that does not 
mean that no other identifiers can begin with a "+". (Clearly, it would 
be a bad idea if within the same field a "+" would mean the same thing, 
something else would, but that's not the case here.) Indeed, the context 
paragraph calls them "global prefixes".

I think any other character would be needlessly confusing. The "+" sign 
signals what should be used and strongly discourages people from 
inserting some random local digits.

There does not appear to be ambiguity in this context as to what is 
meant here.

I added the statement that leading digits must be 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.

Why not? There are quite a few 0800 numbers that are valid in multiple 
(European) countries, and increasingly so.

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

I don't understand this comment. The number, once qualified with +1 
context, is valid just about anywhere in the +1 area. (I seem to 
remember that there's now a law and FCC reg on the books that makes it 
mandatory anywhere in the US.) Clearly, the actual location reached may 
differ depending on where I'm calling from, but that's no different when 
I call Domino's Pizza for a pizza emergency.

I don't think tel URIs have any notion that they are sufficient to 
determine the physical location of the callee.

 From a purely practical standpoint, this appears useful. Plus, even if 
911 is not available locally, there does not appear to be any realistic 
short-hand to describe the region.

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

Noted.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Oct 2002 15:56:25 -0400

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

Neither solution seems great. Practically speaking, many web page 
authors will use the first form, regardless of what the spec says, since 
the fine points of E.164 and international dialing will be lost on them. 
Clearly, the second form is valid.

This gets even more complicated in that with many of today's VoIP 
services, I can indeed dial this number from outside the US.

A pragmatic choice would be to realize that we can never guarantee that 
all tel: URIs are indeed valid numbers. Thus, I would argue that the 
context-qualified form is the desirable one, but that in the spirit of 
"be liberal of what you accept", the tel:+1-800 form (and similar 
versions elsewhere) also be recognized.

Other suggestions are welcome.

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

Deleted.

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

Gone.

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

Any IBMers on the list should speak up. My understanding is that IBM has 
internal numbers ("tie line" is the name you find on their business 
cards) have nothing to do with their externally-reachable numbers.

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

Changed.

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

Gone.

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

Changed.

> Mike Pierce
> Artel