RE: RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-valid ation-epp-0 0

E.164 specifies a maximum of 15 digits, but also specifies an ISDN subaddressing parameter that can be (I believe) up to ten digits in length.  It is quite common in North American voicemail applications to use up to a four digit subaddress at the tail of the E.164 number to indicate a mailbox partition.  I believe in it's original use, the ISDN subaddress was intended to specify extensions behind a PBX or a specific terminal device in the residence. From the ENUM perspective, the distinction between the base E.164 number and the subaddress is meaningless, and in effect the E.164 "string of numbers" can be up to 25 digits long.  I don't believe numbers should contain the user presentation markup, but if you did, I can see the number easily reaching 31 characters.

Greg V.

-----Original Message-----
From: Bernie Hoeneisen [mailto:[email protected]]
Sent: Tuesday, September 28, 2004 7:44 AM
To: Hollenbeck, Scott
Cc: '[email protected]'; '[email protected]'
Subject: [Enum] RE: [ietf-provreg] New I/D:
draft-hoeneisen-enum-validation-epp-0 0


Hi Scott!

Thanks for your feedback!

On Mon, 27 Sep 2004, Hollenbeck, Scott wrote:

> OK, I had a chance to take a closer look.  I noticed that you're using a
> 31-character token for the E.164 number.  Why is that?  An E.164 number can
> contain no more than 15 digits per E.164, so why allow a maximum of 31?  For
> what it's worth I used a type like this in the EPP contact mapping:

The idea behind this was to leave it a Registry policy issue (or up to the 
validation method documentation), what format to use, in order to keep it 
as generic as possible. This would allow over-dialing, and characters 
such as "-", "(", ")" as seperators. Furthermore one could 
describe number ranges, e.g. "+41-44-26815xx", with this format.
I do not have a strong opinion on which format to use for this.

> Also, throughout the document s/März/March/

Ouuppps...!
This is due to a bug in the "xml2rfc" package. It used my locale settings, 
i.e. the environment variable "LC_TIME=de_CH" although any output 
documents of the xml2rfc tool are in English. I have submitted a Bug 
Report and informed the Debian maintainer about this issue. I even got 
immediately a patch!
However, this will be correct in the next revision.


cheers,
  Bernie