Subject: [Iptel] Comments on 2806bis-08 (tel:uri)

From: [email-masked]
Date: Fri, 2 May 2003 15:26:23 EDT

I believe there is one major issue remaining unresolved in this draft 
concerning the representation of "service codes" with a context.

"Service codes" in this sense must include every dialable string which is not 
part of an E.164 number nor part of a local dial plan within a unique context 
such as a PBX. Most discussion has focused on numbers such as 911 in the US 
and various emergency numbers around the world. However, there are many other 
numbers that might fit in this category that need to be coded into the 
tel:uri in this manner, including "0" and various #xx and *xx codes.

As presented in San Francisco and stated in the draft, the intention of the 
tel:uri is that the combination of the local number and the context becomes 
globally unique. The representation of an E.164 number and the representation 
of a local number with a unique context certainly achieves this. However, the 
representation of a service code, such as 911, with a context that simply 
identifies the country, does not provide a "unique" identification. While 911 
means "route to the emergency center" in (most of) the US, it means 
completely different destinations depending on where dialed. Many other such 
service codes, such as 811, are not even standard across the US, so, while it 
might mean "route to telephone company business office" in many places, it 
could mean something completely different in other areas or within another 
local exchange carrier's network in the same area.

This is especially confusing, since the leading "+" is defined in 5.1.3 as 
being the leading character of a globally unique number, which "Must be 
comprised with the country code and national [significant] numbers as 
specified in E.164". Confusion is also caused by attempting to consider such 
"service codes" as "local numbers".

Since these "service codes" are not part of the E.164 plan and are generally 
only meaningful in relation to the physical location of the dialer (or their 
perceived service point), it would never be correct to code them with 
something that comes from the E.164 dial plan, that is, the country code. In 
fact, the only thing that would make the representation unique and truely 
meaningfull would be an identification of the actual location, but that is 
clearly beyond the intention (or possibility) of the tel:uri.

In order to resolve this dilemma, it appears that the only solution is to 
provide an explicit way to indicate that the string of digits included in 
"local-number" has no known context, for example, by including:

"phone-context = none"

I suspect that simply leaving out the phone-context in this case would not be 
a good idea.

I would code this as:

subscriber = global-number / local-number / service-code
service-code = local-number-digits *par "phone-context = none" *par

Mike Pierce

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 02 May 2003 15:57:36 -0400

Comments inline.

[email-masked] wrote:

> 911, with a context that simply identifies the country, does not provide 
> a "unique" identification. While 911 means "route to the emergency 
> center" in (most of) the US, it means completely different destinations 
> depending on where dialed. Many other such service codes, such as 811, 

911 and 811 are very different in this context. 911 is *logically* the 
same wherever it is dialed within +1. This is no different than dialing 
some 800# for a chain store and being connected to the local branch, 
based on the calling number. (We had this discussion before the last 
meeting, I believe.)

Thus, the problem exists only for numbers that indeed mean something 
different depending on where the call is being placed. As discussed in 
the 800# context, it does *not* matter if the number is not universally 
reachable (many 800# are only reachable within a certain geographic 
area). Thus, the only case that's left is the case where some number 
means "road service" in CA and "phone repair" in NY. I don't know 
whether 811 falls into this category; according to 
http://www.nanpa.com/number_resource_info/n11_codes.html, 811 seems to 
have a well-recognized meaning ('business office'), but is not 
FCC-recognized.

Beyond the N11 numbers and the various *99=highway patrol numbers, there 
are also vertical service codes 
(http://www.nanpa.com/number_resource_info/vertical_service.html). 
Examples include *66 and *72. These aren't really identifiers for 
telephone subscribers, so my inclination would be to explicitly declare 
them out of scope. I can see no useful application in the context of a 
URN such as the tel: schema.

Thus, after winnowing down 'service codes' to the subclass of "numbers 
that identify subscribers/PSTN endpoints and mean different things in 
different places", Mike's concern remains.

> Since these "service codes" are not part of the E.164 plan and are 
> generally only meaningful in relation to the physical location of the 
> dialer (or their perceived service point), it would never be correct to 
> code them with something that comes from the E.164 dial plan, that is, 
> the country code. In fact, the only thing that would make the 
> representation unique and truely meaningfull would be an identification 
> of the actual location, but that is clearly beyond the intention (or 
> possibility) of the tel:uri.

I disagree. This only has to be precise enough to avoid 
misunderstandings. Thus, tagging this with ones own phone number, for 
example, would be sufficient.

> 
> In order to resolve this dilemma, it appears that the only solution is 
> to provide an explicit way to indicate that the string of digits 
> included in "local-number" has no known context, for example, by including:
> 
> "phone-context = none"
> 
> I suspect that simply leaving out the phone-context in this case would 
> not be a good idea.

I don't like this idea since it removes the uniqueness property which is 
central to tel URIs and their URNness. If the unique identifier can't be 
made to work (I believe it can), I would much rather tell people that 
they should not use tel: for service numbers of the small class 
described above and then use something like

sip:[email-masked]

which is unambiguous, since it means "direct call to whatever *77 means 
for the carrier mygateway.com".

Henning

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel