Subject: [Enum] Address completion vs private dialing plans

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Thu, 10 Aug 2000 14:06:02 -0500

I think we are talking about two different things.  One is the proper
handling of private dialing plans.  The second is an implementation of an
address completion facility using DNS.  We need to distinguish between them.

The address completion facility takes a dialed string of digits and applies
logic to determine 1) What dialing plan (or local service codes) if any the
dialed digits correspond to and 2) what if any prefix needs to be added or
stripped to construct a valid and unique number within that dial plan.

The example Patrick illustrates A swedish address completion facility.
Given that I am in Sweden, I resolve the digits received using the ENUM
process using a hard-coded num.se domain.  Through the DDDS mechanisms, I
eventually get to a "fully qualified" E164 number and begin the ENUM
process.  

Stated more generally, address completion takes as input a topological
"location" and an input string and results in a numbering plan identifier
and a set of digits unique to that number plan.  Of course, this is a
fantastic facility, but totally out-of-scope for ENUM except to keep options
open for other cool stuff using the same mechanism.

So, in the spirit of "+" to keep things open, I believe we need to go a bit
deeper.  In the general case, the ENUM algoritmn really takes as input both
a string of digits and the identifier of the dial-plan in which the digits
are unique.  The dial plan identifier is used to select the domain suffix
for the DNS lookup and to select between various candidate remapping rules.
Patrick recognized that the RegExp algorithm needs the dialplan identifier
in order to operate as an address completion facility and proposed using "+"
as the e164 identifier.  I would argue that we should address this need in a
more complete way and should explicitly identifing the numbering plan as
part of the input to the NAPTR algorithm. 

So, rather than use +e164digits as the input, why do not we use something
like numberingplan+e164digits.   This is far more powerful than just looking
for a "+" and guessing about which "other" is to be used.

This also addresses another complication that arises with the use of DNAMEs
in conjunction with NAPTRs.   I may arive at the same NAPTR set using
numerous paths defined in by my clients dial-plan tables:

	2.2.7.2.dal.lucent.com (a 4 digit site-wide extension reached 
		by simply dialing four digits)
and
	2.2.7.2.1.0.1.lucent.com    (A 7 digit corporate location+extension
		VPN dialing plan reached by dialing 8+location+extension)
and
	2.2.7.2.3.3.7.2.7.9.nanp.us (the NANP plan reached by dialing 9+10
digits)

and
	2.2.7.2.3.3.7.2.7.9.1.e164.arpa (The E164 GSTN plan reached by
dialing
		011+e164 number in the US.)

where the e164.arpa, and lucent.com are a Cnames pointing back to
2.2.7.2.dal.lucent.com and nanp.us has a Dname pointing to 1.e164.arpa.  Now
I can  have a set of four NAPTR entries, one with a different re-write for
each of the "dialplans".

With the numbering plan identified, one could more easily determine which
regexp to use where the current proposal would leave you guessing.

Greg V.

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Aug 2000 21:31:19 +0200

>for a "+" and guessing about which "other" is to be used.

This is exactly what I am after, but didn't want to specify _how_ the 
private numbering plan was specified. I think what Greg suggests is 
an interesting example, especially with the "numberingplan" string 
being empty for E.164.

Reason for the latter is that I explicitly am stubborn as this 
document is in last call, and IF we find a solution to this without 
doing fundamental changes to the document (such as removing the '+') 
then the document can become an RFC _really_soon_now_. Else, we have 
to reissue the last call.

Not an argument for not doing "the right thing", but an argument to 
_really_ verify whether we want to start "all over again". I know all 
of you want to implement this and get some experience! I am _not_ a 
party which implements this scheme. I am just the editor and want to 
have things done so I can do other things (like being Area Director 
for Applications Area :-).

I.e. the '+' has been there in the NAPTR algorithm all along, so it 
is not anything new.

   paf