Re: [Sipping] Comments (2) on draft-antti-rfc2806bis

[[e-mail]]

In a message dated 5/31/02 12:01:38 PM Eastern Daylight Time, 
[e-mail] writes:


> > The "context" is described as being used for three very different purposes:
> 
> I'm afraid I don't follow. Where do you get this from? It's defined for 
> exactly one purpose, as I had tried to explain in private email: to 
> label where the local-number part is valid by using a globally unique 
> identifier. The globally unique identifier can take two forms: an E.164 
> 

This is the fundamental problem I'm trying to describe. While the context is 
defined for "exactly one purpose", the text represents three specific uses of 
it which have different characteristics, especially concerning the ability to 
concatenate to form a dialable E.164 number. If used to carry an actual E.164 
number, it would be necessary for some entity to do this concatenation. It 
should be able to do this based on some explict indication in the header that 
indicates that it will work.

As noted below, there is nothing in the draft that guarantees uniqueness of 
the identifier. While your statement above is that the "globally unique 
identifier" can take the form of an E.164 number, the draft doesn't describe 
it that way. It describes it as being a "global number prefix (e.g., '+33')", 
that is, only a part of an E.164 number. In fact, if the context were limited 
to being a full E.164 number, some of the concerns I have expressed would be 
alleviated.


> > 
> > 1. as a part of an international number, in which the full E.164 number 
> > is split between the "global-number-part" in the "context" and the 
> > "local-number-part". The two parts can be concatenated together to 
> > construct the real E.164 number. (However, the text also says that this 
> > form "SHOULD" not be used for international numbers.)
> 
> Where is this from? I don't see this in the text that I wrote... It says 
> explicitly
> 
> "The global number prefix does not imply that adding it to the number
> will generate a valid E.164 number.  (For example, ``911'' should be
> labeled with the context ``+1'', but ``+1-911'' is not a valid E.164
> 

This last paragraph (about 911) relates to what I described below as case 3.

The case 1. above of using the context as a part of an actual E.164 number is 
clearly allowed by the statement in Section 5.1. The only way for an entity 
to use it would be to know that the two parts together exactly form a full 
E.164 number.


> 

As I suggested, this ambiguity can be removed by requiring international 
numbers to be represented in their full format (no context).


> 
> > 
> > 2. with a private number, in which the context is simply used as an 
> > "identifier" for the private network or dialing plan. In this case, the 
> > context may not represent actual digits which may be dialed 
> > internationally, and the two parts in the tel:uri can not be 
> > concatenated to form a useful number. There is nothing that guarantees 
> > uniqueness in the "context" used by different networks.
> 
> As the draft points out, the "guarantee" is that anybody labeling a 
> local number should only be done with a label that is under the 
> administrative control of the one assigning the label. If I "own" 
> +1-212-939 (the Columbia CS department), I can stick that label on the 
> number. If I'm at Stanford and still label a local number with 
> 

The point is that it is very hard to say that anyone "owns" a particular 
string of  numbers, so you can never guarantee uniqueness using some 
undefined subset of the full E.164 number. They aren't assigned like domain 
names. They are assigned in various ranges, typically 100's and 1000's groups.

> 
> > 
> > 3. with a locally dialable number like 911 or 112 which is not a part of 
> > the international dialing plan, in which the context is some undefined 
> > set of digits, shown in the example as the country code ("1" for the 
> > US). Again, the parts can not be concatenated to form a useful number.
> 
> Indeed. The draft says that explicitly. See quote above. I'm really 
> confused where you get this notion that the draft advocates that the 
> context is anything but a label. Please cite existing draft text so that 
> 

If you eliminate the possibility of using the context to carry the first 
bunch of digits of an E.164 number, then you could really say that it is just 
a "label". As long as it can contain part of a dialable E.164 address, then I 
don't see that it is just a "label". Beginning the context with "+1" further 
confuses the issue, since that has traditionally been used to begin a 
dialable string (where the "+" is to be replaced with the local 
"international access code").


> > 
> > In all three cases, the context is coded as "+" followed by a string of 
> > digits.
> > 
> > Section 19.1.6 of 2543bis describes how the tel:url (from the 1st 
> > version in RFC 2806) can be converted into a SIP URL This certainly 
> > needs to be updated for the update of 2806, but the current definition 
> > in 2806bis will prevent any straightforward conversion, since nothing in 
> > the tel:uri would indicate which of the three cases above is being used. 
> 
> There are no three cases. There is one case. There can't be a 
> conversion. The whole point of '2806bis' is that we realized that 
> providing a recipe for converting a local number into a dialstring is an 
> exercise in futility. You either
> - know the context of the number and thus can do the translation,
> - know who knows the context of the number and route the SIP request 
> there in the hope that you're right
> 

But with a simple coding of the context, it could be possible for other 
entities such as gateways to know whether of not they can form a 
dialable/routable number from the information they have. Right now, they 
could never do it with certainty. Yes, you're correct, converting a local 
number to a dial string is difficult, but that shouldn't prevent converting 
part of an E.164 number.

Does this mean that this section of 2543bis will be removed to not suggest a 
translation from tel:uri to SIP:url can ever take place?


> > The procedures in draft-ietf-sipping-e164 would have difficulty since 
> > they would not be able to accurately form an E.164 address from the 
> > tel:uri. Further, the conversion required in draft-ietf-sipping-isup 
> > could not be done accurately. Any other use of the tel:uri would need to 
> > understand the three applications of the context described above.
> 
> Again, there are no three applications. There is exactly one.
> 
> > 
> > The basic problem occurs because of the attempt to use part of an E.164 
> > number as a private network identifier, while labeling it (with the "+") 
> > as actually being a part of an international number. In many cases, 
> > there is no E.164 number or part of one that would be appropriate to 
> > identify a network. What number would be appropriate to identify the 
> > world-wide DoD network? If a private network identifier is needed, then 
> > one should be defined. (I don't know if one has been proposed before.)
> 
> Indeed. That's why they would use mil.net, for example. As long as 
> whoever assigns mil.net to the DOD network has the authority to make 
> sure that nobody within DOD uses it to mean something different, there 
> is no problem.
> > 
> > This contradiction can be resolved in several ways:
> > 
> > 1. Make the use of the full E.164 number format a MUST when dealing with 
> > an international dialable number. The context would then only be used to 
> > identify a private network and should be formatted without the leading 
> > "+". It could contain any desired character string.
> 
> As discussed in earlier messages, one of the problems with 2806 was that 
> assigning random strings as an identifier is likely to lead to 
> 

That's why if you want an identification scheme for private networks that is 
guaranteed to be unique, then you have to create one. You can't just let each 
network pick some undefined, leading digits of an E.164 phone number and 
expect that uniqueness will be guaranteed.


> > 
> > or
> > 
> > 2. Make a clear distinction in the context between its use to carry the 
> > leading digits of the international number and its use for a "network 
> > identifier", for example, "+" to indicate international number and no 
> > "+" to indicate private string.
> 
> It's an identifier. I welcome text to amplify this point. The BNF labels 
> things syntactically, and the syntax should be the same. The meaning is not.
> 
> > 
> > A further difficulty is the use of a context with locally dialed numbers 
> > such as 911 which are not a part of the internatonal dialing scheme, 
> > although the use of the context beginning with "+" implies that they 
> > are. The examples show +1-911, although there is no known use for this 
> > combination. It is not dialable and, in fact, 911 isn't valid everywhere 
> 
> If you read the sentence in the draft, it says that
> 
>    ``+1-911'' is not a valid E.164
> 
> Again, I welcome words that further make this point.
> 
> > within world-zone 1. A SIP client or other device elsewhere in the 
> > network would not necessarily know which specific combinations were 
> > dialable. If such numbers as 911 are to be coded in a tel:uli, it is 
> > necessary to explicitly identify them as not being dialable 
> > internationally, which means they can not be used to form an E.164 
> > number. The current definition of the tel:uri does not provide this 
> > capability. This can be resolved by never including a context with these 
> > numbers or by using an explicit coding such as:
> >     ";phone-context=local".
> 
> I disagree. The whole point of labeling is to identify the validity range.
> 
> tel:911;phone-context=+1
> 
> says unambiguously that unless you are in the +1 "zone" by prefix-match, 
> the number is not valid. (It may be valid, but whoever created the URL 
> doesn't know or doesn't want it to be considered valid anywhere else.)
> 

But, it doesn't say that if you are in +1 "zone" that 911 is valid (although 
one could interpret it that way). Handling of any tel:911 uri should be 
possible without a  context.

Let me pose an example of the ambiguity. A tel:url is as follows:

tel:911;phone-context=[phone]

There is no way to determine whether this is intended to be the E.164 number 
for [phone] or if it is intended to be a "911" call in the small town 
in Minnesota whose the assigned number range is 507-728-8000 to -8999. (These 
are real examples of the dialing plan.)

>>  
> > Interworking with ISUP is required. The current draft-ietf-sipping-isup 
> > contains a very unsatisfactory description in Section 11 of the 
> > conversion from a non-international form of tel:url to ISUP. It will 
> > need to be updated to describe the conversion between the new tel:uri 
> > and the Called Party Number parameter (and other IAM parameters which 
> > carry telephone numbers). This will be greatly simplified if the tel:uri 
> > definition is patterned after what ITU-T and other telephony standards 
> > have already done for ISUP. The equivalent thing in ISUP is the Called 
> > Party Number which contains two fields (see Section 11 of 
> > draft-ietf-sipping-isup-01 for a summary):
> > 
> > - "Nature of Address indicator". The important values supported in ITU-T 
> > include: subscriber number, national number, international number, 
> > network specific number. Additional values with network routing numbers 
> > prepended are also defined. The tel:uri must explicitly identify each of 
> > these cases or must explicitly say that they are not used within SIP.
> 
> This is already defined:
> 
> - national number: no + prefix, ;phone-context=whatever-country
> - international number: + prefix, no context
> - network-specific number: no + prefix ;phone-context=network-identifier
> - routing number: see Yu draft (;rn)
> 
> I don't know what the difference between a subscriber and national 
> 

"Subscriber" is a local number - usually 7 digits in the US, "National" is 
with "area code". The distiction is really going away.


> 
> > - "Numbering Plan indicator". The values supported in the US are: 
> > unknown, ISDN numbering plan (E.164), and Private numbering plan. The 
> > tel:uri must explicitly identify these formats.
> 
> 

Sorry, my main point, which I'll stand behind, is that the current syntax and 
spec. does not provide an explicit identification of E.164 and private 
numbers. Take the following tel:uri:

tel:1700;phone-context=+1-703-620

There is nothing here to indicate whether this represents the E.164 number 
[phone] (my company's main number) or it is room number 700 (possibly 
dialed internally as 1700) at the Sheraton whose main number happens to be 
[phone]. The Sheraton could easily pick context=+1-703-620 if they 
wanted.


> - unknown is useless
> - ISDN -> + prefix
> - private: identified by ;phone-context
> 
> > 
> > 
> > Mike Pierce
> > Artel
> > 
> 
>