Subject: RE: [Enum] Itternation in ENUM, a disconnect with DDDS?

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 15 Aug 2000 09:27:09 -0500

In both examples you provided, the substitution only works if it is trivial,
that is, if the replacement string completely replaces the original string.
The current draft permits much more interesting and non-interoperable
combinations.

For a typical corporate network, want to set up NAPTR entries representing
services at a given site.  The following would be an expected set:

*.dallas.num.lucent.com

  IN NAPTR "U" "mailto+E2U" "!(.*)mailto:\+19727332\1@@lucent.com" .
  IN NAPTR "U" "mailto+E2U" "!(.*)LDAP:\LDAP.lucent.com/cn=+19727332\1@" .
  IN NAPTR "U" "tel+E2U"   "!(.*)tel:+19727332\1@!" .

*.7.2.3.3.7.2.7.9.1.e164.arpa

  IN DNAME: dallas.num.lucent.com

*.nanp.us

  IN DNAME: 1.e164.arpa

If the origional String: 2722 queried as 
2.2.7.2.dallas.num.lucent.com, it would  yield: 

	[email-masked].

If the original string was +19727332722, queried as
2.2.7.2.3.3.7.2.7.9.1.e164.arpa, it would yield: 

	[email-masked]

If the original string was +727332722, queried as 
2.2.7.2.3.3.7.2.7.9.nanp.us, it would yield: 

	[email-masked]

...Three different results for the same number.

I do not believe duplicating the rule-set at each leaf-node in the DNS tree
or placing multiple NAPTRs for each path at each leaf-node are acceptable
answers. 

The alternatives seem:

	1) Permit only trivial regexp (replacement only) in NAPTR for ENUM
	2) Permit only trivial DNS structures, 
		limit DNS structures to only include one path to a given
node
		i.e., no DNAME, CNAME, or itterative NAPTR
	3) Carefully describe the interactions between interesting Regexp
and
		DNS structure..... It was not obvious to me.
	4) Extend / Change NAPTR for ENUM to take advantage of DNS 
		structures by permiting use of the NAME field in DNS
responses
		in the construction of the URI.

I prefer 4 because it provides useful expressive power while dramatically
simplying the provisioning and configuration of real-world ENUM services.

Am I making sense?

Greg V.

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Tuesday, August 15, 2000 2:34 AM
To: Vaudreuil, Greg M (Greg); [email-masked]'
Subject: Re: [Enum] Itternation in ENUM, a disconnect with DDDS?

At 11.02 -0500 00-08-14, Vaudreuil, Greg M (Greg) wrote:
>But because the Regexp applies to the ORIGINAL string, it did not
>solve the problem, it simply pushed more work on the client.  When I try to
>apply the regexp to derive the URI, there is a good chance based on the
>query path that the right substitution won't happen.

I agree it would be interesting to both be able to change the orginal 
string and give back the next domainname to use. But that is not the 
case.

So, one have to in the terminal NAPTR write a regexp which matches 
all different kind of input strings, and one common one is '.*', i.e. 
match everything.

>2) Address Completion:
>
>If one queries using an incomplete number using a locally significant DNS
>root, such as 1.1.2.3.4.5.6.7.8.9.nanp.us, one could be returned a NAPTR
>record with a regexp that results in a full e164 number and causes a
>subsequent query for the complete e164 record
>1.1.2.3.4.5.6.7.8.9.1.e164.arpa.  So far, easy and useful.
>
>However, I encounter the same problem as above.  Again, assuming the URI
has
>telephone number components within it, the E164 node needs to potentially
>have two NAPTR entries, one for each of the two paths used to retreive the
>records.  The poor sucker trying to make his IPtelephone work now needs to
>figure out all the possible paths to construct a rule-set that reliably
>works.  When combined with short digit (local) dialing and private
>numbering, we can end up with tens of NAPTR records for a few simple
>services.

Well, I rather think the NAPTR should look like:

1.1.2.3.4.5.6.7.8.9.1.e164.arpa. IN NAPTR "U" "E2U+LDAP"
    "!(.*)!ldap://....\1" .

...where the .... is replaced by a correct LDAP URI content.

You can also do

1.1.2.3.4.5.6.7.8.9.1.e164.arpa. IN NAPTR "U" "mailto+E2U"
    "!(.*)!mailto:\[email-masked]" .

etc etc

I.e. in some cases it is a good thing to keep the orginal string.

     paf

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 15 Aug 2000 23:51:12 +0200

>   IN NAPTR "U" "tel+E2U"   "!(.*)tel:+19727332\1@!" .

First, these are not syntactically correct regular expressions, and 
secondly, given the way ENUM is written at the moment, you have 
either multiple regexps, like (I corrected the regexp errors):

IN NAPTR "U" "mailto+E2U" "![^+](.*)!mailto:+19727332\[email-masked]!" .
IN NAPTR "U" "mailto+E2U" "!+(.*)!mailto:+\[email-masked]!" .

I.e. given that people know the rules, it is not hard to make regexps 
that work.

So, the original question was whether you need to know "what paths" 
have been taken, and my response is "yes" you need to know that.

But, does it matter?

    paf