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

[Henning Schulzrinne <[e-mail]>]

> 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 
number or a domain name.

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

I appreciate suggestions for further clarifying these words.


> 
> 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 
+1-212-939, I only have myself to blame. Similarly, for a domain name.


> 
> 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 
it can be made less ambiguous.

> 
> 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
- give up and send back a 404 or whatever

> 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 
collisions, as everybody will pick "vpn" or "local" or other such strings.

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


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


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

Already does, except more specifically.

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

> 
> 
> Mike Pierce
> Artel
> 



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