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

From: [email-masked]
Date: Fri, 31 May 2002 10:33:47 EDT

To all,

In reviewing the descriptions in the draft concerning the use of the 
"context", I find a number of difficulties in its definition and implied 
usage.

The "context" is described as being used for three very different purposes:

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

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.

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.

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

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

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.

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.

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

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

Mike Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 31 May 2002 12:00:41 -0400

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

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

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

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

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

> 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 

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

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

> Artel

_______________________________________________
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: Fri, 31 May 2002 18:00:01 +0100

At 10:33 am -0400 31/5/02, [email-masked] wrote:
>"context", I find a number of difficulties in its definition and 
>implied usage.
>
>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.)
>
>"identifier" for the private network or dialing plan. In this case, 
>the context may not represent actual digits which may be dialed 
>concatenated to form a useful number. There is nothing that 
>guarantees uniqueness in the "context" used by different networks.
>
>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.
>
>In all three cases, the context is coded as "+" followed by a string 
>of digits.
>
To which I reply:
  Hi To Mike Pierce, folks,
   what version of the draft are you looking at, Mike?
In draft 2806bis-04.txt, lines 206/207 (ABNF) show the syntax for the 
phone-context.
How does this square with the above comments on syntax?
lines 306-309 spell out that the context and local-number-part cannot 
necessarily
be combined to make a fully qualified E.164 number. They might, but this is a
coincidence.
Again. how does this square with the comments on concatenation to get 
an E.164 number?

I'm confused, are these your opinions on what should be supported?

BTW, this is an update to Draft Standard, so addition of new features
is difficult, for example your proposal on addition for ISUP attribute
support, or wholesale reconstruction to carry all ISUP IEs.

Other than those in 2806bis already, all tel: URI parameter definitions
should be in 'external' drafts such as Jams Yu's one on "cic & rn" parameters.

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