Subject: [Enum] non-E.164 Numbers in ENUM

From: [email-masked]
Date: Wed, 15 Sep 2004 12:39:34 -0400

To all,

A recent discussion on the IPTEL list indicates that there is still confusion regarding the handling of non-E.164 compliant number in ENUM. The issue regards the handling of numbers that contain extra digits beyond what is considered a valid number. This practice is common in today's telephone network, when companies advertise their telephone number with convenient words which often exceed the actual digits needed. This is done, and works, since the telephone network today always knows when to throw away the extra digits, either at the originating exchange, or at some intermediate point. These extra digits can never have any effect on the routing of the call, nor should they result in the call being rejected.

As an example, I just retrieved an ad from my wastebasket which lists a number as 1-888-OUR-BRAIN. Since the real E.164 number is +1-888-687-2724, the extra "6" must be ignored when dialed.

Some responders on the IPTEL list indicated that they think that it is perfectly okay for end users to register number combinations with extra digits, at least in "Tier 2 nameservers". Some go so far as to suggest that ENUM should allow different translations for the actual (correct length) number and the ones with extra digits. As someone pointed out, the end user could create literally millions of extra combinations from one valid number.

This situation arises when the originator of the ENUM request does not know the dialing plan that pertains to the number they are sending, and therefore may include more digits than are required. This relates to a general issue that has been raised many times in the past reqarding what to do when the originating device (end user's phone) does not know the dial plan. In existing telephone service, the end user's device never knows the dial plan, leaving it up to the network to know. This is why a cell phone user is required to press a key at the end of what they think a complete number is. The network then validates it and throws away extra digits, and intercepts if there are not enough digits.

It appears that there needs to be a general solution to the unanswered question "What if my phone does not have a dial plan".

For ENUM, there needs to be a clarification of what entries can be supported in ENUM. I believe it needs to be made very clear that it can not include number combinations that exceed the E.164 defined numbers (as regulated by various countries). In the world zone 1, that is currently 10 digits.

Mike Pierce
Artel

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Marian Durkovic <[email-masked]>
Date: Wed, 15 Sep 2004 13:37:28 -0400

> For ENUM, there needs to be a clarification of what entries can be supported 
> in ENUM. I believe it needs to be made very clear that it can not include 
> number combinations that exceed the E.164 defined numbers (as regulated by various 
> countries). In the world zone 1, that is currently 10 digits.

I'm afraid this is not technically possible. Once you delegate a zone with 
NS record(s), the dalegated nameserver can put any number of subdomains
under the delegated domain or even a wildcard record to match anything
- this in fact drops all extra digits right away.

In some cases adding extra digits might even be useful - for example
to be able to directly reach PBX extensions on a PBX without DDI block.

	With kind regards,

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk    ----
----                                                                  ----
--------------------------------------------------------------------------

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 15 Sep 2004 13:37:28 -0400

Hi MIke, folks,
first, a plea - PLEASE don't sent HTML format mails - I have my mailer 
set
to present plain text mails in a font size I can read, so whilst my 
myopia
is not your problem, presentation of web pages in default (small) font 
size
doesn't help my attitude :).

On to the substance::
RFC3761 is clear - this is for E.164 numbers only.
In DDDS terms, this means is that the Application Unique String is an 
E.164 number
(with all non-numeric characters except the initial '+' removed).

---

From: Jim Reid <[email-masked]>
Date: Wed, 15 Sep 2004 14:45:46 -0400

>>>>> "Marian" == Marian Durkovic <md at bts.sk> writes:

    >> For ENUM, there needs to be a clarification of what entries can
    >> be supported in ENUM. I believe it needs to be made very clear
    >> that it can not include number combinations that exceed the
    >> E.164 defined numbers (as regulated by various countries). In
    >> the world zone 1, that is currently 10 digits.

    Marian> I'm afraid this is not technically possible. Once you
    Marian> delegate a zone with NS record(s), the dalegated
    Marian> nameserver can put any number of subdomains under the
    Marian> delegated domain or even a wildcard record to match
    Marian> anything - this in fact drops all extra digits right away.

This is not true. There is a maximum length of a domain name. It's one
of the fundamental constants of the DNS. Though admittedly that length
-- 255 characters including the dots -- is much more than the 15(?)
digit maximum for an E.164 number. This limit also applies to wildcard
matching.

And as you should know by now, wildcards in the DNS are evil. They're
even worse in the context of ENUM. That's because a DNS wildcard can
match anything. If a query name contained non-digits, this would match
a DNS wildcard if one existed. That could mean unexpected data getting
input to the NAPTR rewriting rules. Or, worse, some telco equipment
gets asked to dial a "number" like 01234Marian's+Funky+Wildcard-Match.

You are however correct to suggest that once a delegation is made, the
owner of that delegation can extend their part of the name space: for
instance to add extra digits to telephone numbers. This may have
undesirable consequences for telephone equipment and national/local
numbering plans.

---

From: Jeff Williams <[email-masked]>
Date: Wed, 15 Sep 2004 20:16:14 -0400

Jim and all,

> digit maximum for an E.164 number. This limit also applies to wildcard

  Your of course correct here Jim, and thank you for again pointing this
out and/or bringing it to attention.

>
>
> And as you should know by now, wildcards in the DNS are evil.

 I disagree with this statement as stated.  Yes, wildcards in DNS
can be used for evil or disruptive purposes, but they can also be used
for very beneficial uses as well.

> They're

  Why is this bad for ENUM?  I can see easily specific situations were
it could be bad or used badly.  But I don't see any justification for
it being bad in a broad sense as you stated it here.

> undesirable consequences for telephone equipment and national/local

  Agreed that in some to many instances, this could have very undesirable
consequences for antiquated telephone equipment as well as some,
if not many national and/or local numbering plans...

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 16 Sep 2004 03:40:42 -0400

Mpierce1 at aol.com said:
> A recent discussion on the IPTEL list indicates that there is still confusion 
> regarding the handling of non-E.164 compliant number in ENUM. The issue 
> regards the handling of numbers that contain extra digits beyond what is considered 
> a valid number. This practice is common in today's telephone network, when 
> companies advertise their telephone number with convenient words which often 
> exceed the actual digits needed. This is done, and works, since the telephone 
> network today always knows when to throw away the extra digits, either at the 
> originating exchange, or at some intermediate point. These extra digits can never 
> have any effect on the routing of the call, nor should they result in the 
> call being rejected.

This is called "overdialling" and it is *not* guaranteed to work in all
telephone networks. There are cases in the UK - I am assured by my
colleagues - where this will cause misrouteing or call failure.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 16 Sep 2004 03:46:08 -0400

Jim Reid said:
> -- 255 characters including the dots --

Nitpick: it's 255 octets including the length fields of each component
including the final empty one.

So "www.davros.org" is encoded as:

    3 'w' 'w' 'w' 6 'd' 'a' 'v' 'r' 'o' 's' 3 'o' 'r' 'g' 0

and so is 16 octets and not the 14 you might expect. So the limit is
actually 253.

In addition, if both sides think that UTF-8 is in use (though, of course,
it shouldn't be) then "character" is not "octet".

---

From: Marian Durkovic <[email-masked]>
Date: Thu, 16 Sep 2004 06:05:53 -0400

> digit maximum for an E.164 number. This limit also applies to wildcard

Sure there's a DNS limit, however I was thinking in much smaller "scale"
- when user wants to add 1 or 2 digits or so.  

> gets asked to dial a "number" like 01234Marian's+Funky+Wildcard-Match.

Jim, I don't think this can happen. According to RFC3761, all non-digit
characters must be stripped out, so after applying this requirement,
01234Marian's+Funky+Wildcard-Match gets reduced to 01234. So yes, you
will get a response when manually doing nslookup etc, but the real
ENUM client should not perform any weird queries/substitutions.

> undesirable consequences for telephone equipment and national/local

The consequences depend on actual implementation. Suppose you have a PBX
without DDI - so all users calling from PSTN dial +12345678 and get 
connected to the operator (or get to IVR asking them to dial extension
usign DTMF). Then you add VoIP gateway to the PBX, which 
can reach the extensions directly. By populating the ENUM zone with:

+12345678    -> operator at company.com
+1234567811  -> ext-11 at company.com
+1234567812  -> ext-12 at company.com
.....

you will allow the ENUM clients to reach the extensions directly, but at the
same time, if any equipment cuts the extra digits, the user will reach
the operator/IVR as if calling from PSTN. So there are no bad consequences, 
just the users from IP world will have more comfort than the users from PSTN
- they could bypass the operator and/or two-stage dialing process via IVR.

	With kind regards,

----   Marian Durkovic                       network  manager         ----
----                                                                  ----

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Thu, 16 Sep 2004 06:11:15 -0400

Hi Clive, folks,
  following this particular peregrination,
ENUM domains are more fun that this - you have to multiply the number 
of digits by two,
as each digit is a label, and so it gets a single octet (0x01) 
prepended to it, plus
the apex labels (\004e164\004arpa\000) appended. Nevertheless, as both 
ENUM (and the
tel URI spec) specifically mention E.164, then 15 digits is a name 
field length of
(2*15 + 11) = 41 octets.
With 255 octets, we have some "headroom" for any updates to the RFCs to 
reflect
changes to E.164, but IMHO any major change (to e.g. E.192, or ISO 
network addresses,
or any other abstract space you care to get a doctorate studying) MUST 
be an update to
the 3761 (and whatever RFC2806bis becomes).

Praise the stars, IDN (and punycode) doesn't come into it with 
registered ENUM domains,
as the labels are digits and are required to be in the 
USASCII-equivalent set, whilst
the apex is specified in USASCII characters, so is by definition in the 
equivalent set.
Of course, if someone wants to have a sub-domain in their registered 
zone, then this
could include  any whacky stuff, so the punycode identifier string 
might be needed,
along with the punycoded characters of that label, plus the label 
length octet.

However, no ENUM client is going to look in this domain (unless it 
supports non-final
NAPTRs) so, from an ENUM perspective, it's "invisible".

all the best,
  Lawrence
On 16 Sep 2004, at 08:38, Clive D.W. Feather wrote:
Jim Reid said:
In addition, if both sides think that UTF-8 is in use (though, of 
course,