Subject: Re: [Sipping] proposals for 2806bis

From: [email-masked]
Date: Tue, 4 Jun 2002 17:21:38 EDT

In a message dated 6/3/02 8:26:24 PM Eastern Daylight Time, [email-masked] 
writes:

> Hi Mike, Folks,
> In answer to Mike Pierce's comments on the 2806bis-04 draft:
>   It must be me. I'll try again.
> Please give the line numbers within the draft that you believe state:
> * that concatenation between the phone number and the context is EVER 
> intended.
> * that it is EVER intended to split an E.164 number between a context 
> and a local number (your case 1).
> 
Sorry, my copy of the draft which I downloaded from IETF doesn't have "line 
numbers". I know some viewers add in numbers, but I'll just try to use the 
good old fashion way to reference the parts.

The first paragraph of Section 5.1 states "All phone numbers SHOULD be 
written in the international form unless they cannot be written as such." 
(One must presume that "international" means the same as "global (E.164)" in 
the previous sentence.) Since this is a "SHOULD", it clearly means that it is 
possible, and not contrary to this specification, to write such a phone 
number in something other than the international form. The only way to do 
this, that I know of, is to include both the local-number part and the 
global-number-part separately, with the global-number-part in the 
phone-context. I hope this doesn't mean that just the local part without 
anything else is allowed. For example, the representation could be:

tel:817-4795;phone-context=+1-410
or as you indicated in your example at the end of the e-mail:
3666;phone-context=+44179483

If this form is not possible, then it should be stated that it is not. I 
suggested changing the "SHOULD" in Section 5.1 to "MUST". This change would 
resolve most of my comments.

If the form in the above example is possible, then it should also be clear 
that the two parts would have to be concatenated to form a useful, routable, 
E.164 number.

> 
> As I don't understand your lack of uniqueness concerns clearly, could 
> 

I demonstrated how the exact same coding of the tel:uri could be used for two 
different destinations. There is nothing in the draft or the process (e.g., 
IANA registration) that prevents this lack of uniqueness. I could give other 
examples.

> From your comments it appears your worry is with E.164 stub numbers, 
> but I feel fairly sure that OfTel would state that +44 1794 had 
> better be unique to Romsey. In any case, if my node is aware that it 
> is connected via a line to the Romsey Exchange (and so has an E.164 
> stub of +441794) then it can use this number. If it isn't, then it 
> can't. Where is the lack of uniqueness?
> 

Yes, stubs of E.164 numbers could be used and guaranteed to be unique if the 
process is defined for this, for example, having the local telephone company 
who "administers" the number set assign "stubs" to be used in "phone-context" 
for private numbers. But nothing is said about this, and honestly, with 
recent activities for local number portability and local competition, I'm 
afraid that even that possibility (assigning number blocks) is getting more 
complicated.
 
> Your Minnesotan example URI suggests that, in this small town, one 
> can dial 911 and will get through to a valid local number. I have not 
> been there so I can't say for sure, but I had thought that 911 is 
> ALWAYS treated as a call to the Emergency Services.
> 

Years ago, I think you could dial 3 (or maybe 4) digits. (I remember when you 
couldn't dial at all!) Not anymore. 7-digit dialing is required for all local 
calls in that town. And no, 911 is not always treated as a call to Emergency. 
There are still some areas of the US that don't use it.
 
> My equivalent Romsey example would be 3666;phone-context=+44179483. 
> This will work only if my E.164 stub number is in the range for Roke 
> Manor. Don't try this at home, kids as it only works at Roke.
> 
> 
> BTW, isn't gateway routing a TRIP problem?
> 

Yes, I suppose gateway routing is a TRIP problem, but it seems that we need 
to do everything possible to ensure that the tel:uri is useable for other, 
known purposes. One of these would be for the gateway to be able to convert 
the tel:uri to an E.164 number for forwarding through ISUP.

> atb,
>    Lawrence
> -- 
> [email-masked]: +44 1794 833666::<my opinions>:
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 05 Jun 2002 15:37:23 -0400

> written in the international form unless they cannot be written as 
> such." (One must presume that "international" means the same as "global 
> (E.164)" in the previous sentence.) Since this is a "SHOULD", it clearly 

I've gone through and made all references "global", although the 
equivalence was indicated by () on first mention.

> means that it is possible, and not contrary to this specification, to 
> write such a phone number in something other than the international 
> form. The only way to do this, that I know of, is to include both the 
> local-number part and the global-number-part separately, with the 
> global-number-part in the phone-context. I hope this doesn't mean that 
> just the local part without anything else is allowed. For example, the 

A local number needs a context that indicates where it is valid. It does 
not need an indication as to how to turn it into a global number, as 
that may not be possible.

> representation could be:
> suggested changing the "SHOULD" in Section 5.1 to "MUST". This change 
> would resolve most of my comments.

I'm afraid we must be completely talking past each other. Local number 
(with finite scope of validity) appear to necssary, so I can't see how 
they can be made global (i.e., of the + variety).

> 
> If the form in the above example is possible, then it should also be 
> clear that the two parts would have to be concatenated to form a useful, 
> routable, E.164 number.

No, you completely misunderstand. Let me repeat once again: "The context 
is a label." A label identifies something. It does not tell you how to 
turn it into something else. No more, no loss. We could've used the 
administrator's social security number, his DNA fingerprint or his 
retina scan, if this were convenient or feasible.

> I demonstrated how the exact same coding of the tel:uri could be used 
> for two different destinations. There is nothing in the draft or the 
> process (e.g., IANA registration) that prevents this lack of uniqueness. 
> I could give other examples.

No. Whoever is responsible for the local number needs to pick an 
identifier, having one of the two forms shown. The identifier needs to 
be conveyed to all clients that need to know the number. Everybody else 
will not recognize the prefix and just refuse to do anything with it.

As Lawreence and others have tried to point, this is not a problem in 
practice. Somebody at Columbia University needs to decide that local 
Columbia numbers get the context label columbia.edu or +1-212-854 
(either would work, since the University owns both identifiers, i.e., 
all numbers starting with +1-212-854 and nobody else who's not malicious 
or confused would label their local numbers with either identifier.)

This avoids having to register things with IANA. (Indeed, IANA 
registration wouldn't help as there's no guarantee that two 
organizations that used to be separate aren't merged or vice versa.)

> Yes, stubs of E.164 numbers could be used and guaranteed to be unique if 
> the process is defined for this, for example, having the local telephone 
> company who "administers" the number set assign "stubs" to be used in 
> "phone-context" for private numbers. But nothing is said about this, and 
> honestly, with recent activities for local number portability and local 
> competition, I'm afraid that even that possibility (assigning number 
> blocks) is getting more complicated.

I don't see the problem. An organization knows precisely which numbers 
it has assigned to it, without the help of the FCC, Oftel or a psychic. 
I've added some more examples to the draft to make this clearer.

"For a local
number valid within a PBX, the organization can choose any number under
its control to identify the context. For example,
a context consisting of any of the organization's
global number may be suitable, or a substring that is completely
occupied by the organization.  For example, +49-6151-16 would be a
suitable prefix for the TU Darmstadt, as it uses all numbers starting
with those digits."

Columbia, to pick up the example, would be rather upset and make a call 
or two to the PUC if Verizon were to somehow assign a number in the 
212-854 range to some random Joe.  Columbia could pick +1-212-854, 
+1-212-854-0000, or +1-212-854-7000 (the main switchboard) and any other 
number that it owns, all of which would be perfectly ok, but it better 
pick one of them. Thus, this is, at best, a local problem within 
Columbia to agree on that identifier. This is no more difficult than 
preventing three people from independently requesting Enterprise ID's 
from IANA (and far less likely to be mistyped later).

> Years ago, I think you could dial 3 (or maybe 4) digits. (I remember 
> when you couldn't dial at all!) Not anymore. 7-digit dialing is required 
> for all local calls in that town. And no, 911 is not always treated as a 
> call to Emergency. There are still some areas of the US that don't use it.

As far as I know, 911 is reserved as a national emergency number in the 
US, by federal statute. While it does not work everywhere, it cannot be 
assigned to anything else. (Doing so would be stupid beyond belief; 
imagine dialing 911 and finding that it rings some deserted outhouse 
somewhere.)

> other, known purposes. One of these would be for the gateway to be able 
> to convert the tel:uri to an E.164 number for forwarding through ISUP.

This is not possible. See the IBM "tie line" example or the 911 example. 
For numbers where this is possible, the number should be written as 
E.164 to begin with; there's nothing to be gained by writing it as a 
local number + context.

In summary: I've added words or rephrased words stating that
- MUST use E.164 unless the number isn't representable as such;

- MUST use phone-context if it's a local number;

- emphasized in a few places that a phone-context can NOT be used create 
an E.164 number except by coincidence; (although, in that case, this 
violates rule 1, since the number should've been written as E.164 to 
begin with);

- added that each organization has numerous choices as to how to tag 
their context, including all numbers and prefixes that it controls.

If somebody wants to write a draft that describes how to turn random 
local numbers into E.164 numbers, they are invited to do so. It's a 
different draft (and may well be filed in the same patent department 
that handles perpetuum mobiles).

Henning

_______________________________________________
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: Lawrence Conroy <[email-masked]>
Date: Wed, 5 Jun 2002 23:38:02 +0100

In response to Mike Pierce's further comments:
>(One must presume that "international" means the same as "global (E.164)"
>in the previous sentence.) Since this is a "SHOULD", it clearly means
>that it is possible, and not contrary to this specification, to write
>such a phone number in something other than the international form.

lwc sez:
SHOULD implies a possible alternative.

Please read E.164 if you have problems with the words Global and
International. From your ISUP comments, one must presume that you
know this already. You will also be aware of Local and National.

>The only way to do this, that I know of, is to include both the
>global-number-part in the phone-context.

lwc sez:
I do not understand how you get from the sentence you quote to this
conclusion.
What you are doing is to take an E.164 number, split it into two parts,
and spread the parts across the context and local-phone-part portions of
the URI. That may work, but not always. The context is not a part of the
number, its a context in which the number is valid (as stated in the draft).

>I hope this doesn't mean that just the local part without anything else
>is allowed. For example, the representation could be:

lwc sez:
Unless the calling context is guaranteed to be within the context in which
the tel: URI destination is specified, there MUST be a phone-context to
indicate the expected context.
If some private context CAN be guaranteed to be common to caller and
destination, then the phone-context might be discarded. Thus, what you
hope doesn't might exist, but only in specific cases. In general, there
MUST be an explicit context.

>If this form is not possible, then it should be stated that it is not.

You can't mean a local number with a phone context - the document states
(the obvious) that it is possible. If you mean a local number without a
qualifying context, then the document does exclude this ("such numbers
need to be represented with a context").

>I suggested changing the "SHOULD" in Section 5.1 to "MUST". This change

As you are aware, this suggestion would be at the cost of removing all
non-E.164 International numbers and a significant chunk of utility that
is already implemented by several groups. We can and do use it, so this
change is unnecessary.

>clear that the two parts would have to be concatenated to form a useful,

lwc sez:
This does not follow from the document, or from your statements. It may be
the case that a local number with qualifying context CAN be mapped to an
E.164 number by concatenation.
It is perfectly possible to route a call to my extension (3666) within the
context of Roke Manor; colleagues do it all the time. It's also possible
for someone to use the E.164 number format - it happens to be a DDI number
where the extension number is identical to the leaf portion of the
equivalent E.164 number.

This need not be the case, however. I have seen cases where private
networks have been combined (on Company takeover, or on a company being
allocated a larger but different DDI number range) and where the extension
numbers have NOT been changed. As a result, "brute force" concatenation
will not succeed.

It doesn't always work (as described in the last two lines of section
5.1.3). If you still want to do this, it's your problem.

all the best,
    Lawrence