Subject: [Enum] RE: draft-ietf-enum-e164-dns-03.txt

From: James Yu <[email-masked]>
Date: Wed, 9 Aug 2000 16:30:56 -0500

> >Don't know whether it is a good idea to mix real E.164 
> numbers and non-E.164
> >numbers.  Non-E.164 (E.164 like) number can use something 
> like pe164.  May
> >be you are trying to use E2U for those numbers to avoid 
> defining a new one?
> >But see the reason below that there will be other 
> "international" numbering
> >plans that may use enum-like process.  So it would be fine 
> to create a new
> >"numbering plan" name for those non-E.164 numbers.  For that 
> reason, I
> >suggest that we don't add '+' for the NAPTR part of the process in
> >e164.arpa/enum.
> 
> What I was thinking of was something which in the NAPTR recursive 
> process was some way for the rewrite of the telephone number might 
> rewrite a non-e164 number (without leading '+') into one which is a 
> E.164 number (and vice versa).
> 
> I.e. I felt together with Ericsson people (and others) that it is 
> important that you when defining the rewrite rule in the regular 
> expression can write one which matches (or not) on only E.164 numbers 
> or not.
> 
> I have no ide whether this will be used or not, but people have 
> adviced me all along to keep the '+' if possible. Phone people that 
> is.

I'm still not clear about this.  The '+' is not part of the enum DNS query
(only x.x.x.x.x.x.e164.arpa instead of x.x.x.x.x.x.+.e164.arpa).   So for
the NAPTR algorithm to use the E.164 number, it has to retrieve the E.164
number in the DNS query (e.g., get everything before .e164.arpa, remove all
the dots and reverse the order of the digit to recover the original E.164
number).  If '+' is needed, then '+' is added to the front of the E.164
number.  I assume that the client is not asked to remember the output of
step 2 in section 2. The rewrite rule will be applied to the string in the
DNS query and that string does not have '+' in it.   That is why I'm not
clear about the '+' discussed in your I-D.

Also, a client may send a DNS query to a local DNS server for resolution.
Does the local DNS server continue the DNS resolution process when it
receives NAPTR records (may be it depends on the type of NAPTR RRs
returned)?  I guess that if the NAPTR is for a SRV record, the local DNS
server will go to the NS specified by the "target" to retrieve SRV RR(s).
So the client performs the six steps described in section 2 but it is the
local DNS server that performs the DNS resolution.  The local DNS server
then is required to add the '+' to the E.164 number using the rewrite rule
if it needs to continue the DNS resolution process.  But only the client
knows that the DNS process is related to enum.  The local DNS server only
performs routine DNS process (including NAPTR) and may not know that the DNS
query is about enum.  Is it correct?

James

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

---

From: Michael Mealling <[email-masked]>
Date: Wed, 9 Aug 2000 18:09:42 -0400

> clear about the '+' discussed in your I-D.

Actually Patrik's draft is clear that the input to the NAPTR rewrite
rule is the original e.164 number without the dashes and not the
actual domain-name. The NAPTR docs are very clear that you can never
use a Key as an input to a rewrite rule and that once you've started
doing the NAPTR rewrite algorithm that you cannot change what string
its acting on....

See Section 3.1.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-03.txt

Specification for use of NAPTR Resource Records

   The input is an E.164 encoded telephone number. The output is a
   Uniform Resource Identifier in its absolute form according to the
   'absoluteURI' production in the Collected ABNF found in RFC2396[5]

   An E.164 number, without any characters but leading '+' and digits,
   (result of step 2 in section 2 above) is the input to the NAPTR
   algorithm. 

I think you might be confusing the e.164 phone number (the Application
Unique String) with the database Key which is the number without
any characters at all and the DNS DDDS Database key format which is
what has to be a valid domain-name....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Hong Liu <[email-masked]>
Date: Wed, 09 Aug 2000 21:59:38 -0400

Hi, Michael,

I am glad that you join the discussion here. I have some questions regarding the
NAPTR algorithm in the context of ENUM. I would appreciate that you could clarify
them for me:

(1) In draft-ietf-urn-naptr-rr-04.txt Section 4, the basic NAPTR algorithm is
presented. It says that "the algorithm starts with a string and some known key..."
So does it mean that the input to the NAPTR algorithm contains two parameters, one
for the string, another for the known key?

In the context of ENUM, do you mean that the string is an E.164 number, without any
characters but leading '+' and digits, say +4689761234, while the key is the domain
name derived from the string, say 4.3.2.1.6.7.9.8.6.4.e164.arpa?

If that is the case, then the input to the NAPTR algorithm is both +4689761234 and
4.3.2.1.6.7.9.8.6.4.e164.arpa . In other words, one needs to change the wording in
Section 3 of draft-ietf-enum-e164-dns-03.txt regarding the input to the NAPTR
algorithm.

(2) In dratf-ietf-urn-ddds-00.txt, a more generic algorithm is presented in Section
3.3. The description of this algorithm is somewhat different from the one above. In
this case, the DDDS algorithm seems to imply that there is only one input, i.e., the
Application Unique String. The first step of the algorithm is to apply the First
Well Known Rule to the Application Unique String to produce a Key.

To map ENUM into the DDDS context, I have the following correspondence:
Application Unique String: an E.164 number without any characters but leading '+'
and digits, say +4689761234. This is the input to DDDS algorithm.
First Well Known Rule: Step 3 to 6 in Section 2 of draft-ietf-enum-e164-dns-03.txt.
(Initial) Key: the domain name derived from the string, say
4.3.2.1.6.7.9.8.6.4.e164.arpa
Any subsequent substitutions shall be applied to the Application Unique String, i.e.
+4689761234.

Personally, I would like to see the ENUM protocol in draft-ietf-enum-e164-dns-03.txt
modeled after the DDDS framework than the transient NAPTR draft, just like what you
did with URI/URN resolution in draft-ietf-urn-uri-res-ddds-00.txt. It seems to me by
reading your draft-ietf-urn-dns-ddds-database-00.txt, the NAPTR algorithm is a
special case of the DDDS algorithm where the database is DNS and the RR is NAPTR,
and ENUM is just another application using DDDS with DNS and NAPTR. I am not sure
how much more work needs to be put into rewriting draft-ietf-enum-e164-dns-03.txt to
do that.

(3) In the case of ENUM, which document we should use as reference to NAPTR,
draft-ietf-urn-naptr-rr-04.txt or dratf-ietf-urn-ddds-00.txt plus
draft-ietf-urn-dns-ddds-database-00.txt? It does not seem to me that the two are
totally consistent. I personally like the latter better.

(4) In DDDS/NAPTR algorithm, does it apply to only the first matched NATPR RR
satisfying the services for the application or all NATPR RRs satisfying the
services? The reason I ask this question is that in ENUM, an application may like to
check all the NAPTR RRs before deciding on which one to use, say SIP call is
preferred by the callee but the caller can only send email. Here suppose both have
the same service E2U.

(5) In the NAPTR definition, it seems that the flag field dictates what can be put
in the regexp and replacement field. For example, the "U" flag requires that the
regexp field cannot be empty while the replacement field should be empty; the "A"
and "S" flags requires that the regexp field be empty while the replacement field
cannot. Is this the right interpretation? How about the "P" flag and the empty flag?
What is the implication of each on the regexp and replacement fields?

(6) Since ENUM only returns URIs, does it mean that only the "U" flag and the empty
flag can be used in the NAPTR RRs for ENUM? In other words, are "A", "P" and "S"
f;lags not allowed for ENUM NAPTR RRs?

Thanks again for the help!

Best regards,

--Hong

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Aug 2000 07:29:12 +0200

>clear about the '+' discussed in your I-D.

No, the steps that have to be taken is _exactly_ what is written in the spec:

(1) Take the E.164 number
(2) Remove all characters part from leading '+' and digits
(3) Remove the '+'
(4) Reverse the order of digits
(5) Add '.' between digits
(6) Add ".e164.arpa." at the end
(7) Look up NAPTR in DNS
(8) If NAPTR is non-terminal apply rewrite rule to output of (2)
     and query for new NAPTRs again which you apply output of (2) to

That is what you _have_ to do.

>Also, a client may send a DNS query to a local DNS server for resolution.

Of course.

>returned)?

I don't understand. Do you ask whether the local resolving DNS server 
is doing the NAPTR resolution? The answer to that question is "no". 
The client have to do that as the client is the one which know what 
the input to the NAPTR algorithm is for E2U. You can not when using 
NAPTR take for granted that what the regexp is applied to can be 
extracted from the domainname.

>I guess that if the NAPTR is for a SRV record, the local DNS

I don't see how SRVs can be included in the ENUM mechanism...

>query is about enum.  Is it correct?

The DNS part of this is only querying for DNS RRs, and does not do 
anything else regarding NAPTR rewrites.

   paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 10 Aug 2000 08:40:44 -0400

On Wed, Aug 09, 2000 at 09:59:38PM -0400, Hong Liu wrote:
> presented. It says that "the algorithm starts with a string and some known 
> key..." So does it mean that the input to the NAPTR algorithm contains 
> two parameters, one for the string, another for the known key?

Not really. It just means we used sloppy language. That should read "the
algorithm starts with a string and some predefined rule". This, among
others, is why we're working on the DDDS documents. Since those documents
are new it didn't seem fair to make ENUM wait 6 months on the DDDS
documents, thus we decided to send draft-ietf-urn-naptr-rr-04.txt
forward. It will be obsoleted by the DDDS documents when they are approved.

> In the context of ENUM, do you mean that the string is an E.164 number, 
> without any characters but leading '+' and digits, say +4689761234, while 
> the key is the domain name derived from the string, say 
> 4.3.2.1.6.7.9.8.6.4.e164.arpa?
> 
> If that is the case, then the input to the NAPTR algorithm is 
> both +4689761234 and 4.3.2.1.6.7.9.8.6.4.e164.arpa . In other words, 
> one needs to change the wording in Section 3 of 
> draft-ietf-enum-e164-dns-03.txt regarding the input to the NAPTR algorithm.

Nope. We just need to update draft-ietf-urn-naptr-rr-04.txt with the newer,
better, faster DDDS documents. While draft-ietf-urn-naptr-rr-04.txt is 
technically accurate, it just won't cut it in the long term...

> (2) In dratf-ietf-urn-ddds-00.txt, a more generic algorithm is presented 
> in Section 3.3. The description of this algorithm is somewhat different 
> from the one above. In this case, the DDDS algorithm seems to imply 
> that there is only one input, i.e., the Application Unique String. The first 
> step of the algorithm is to apply the First

Yep. Much clearer isn't it....

> Application Unique String: an E.164 number without any characters but 
> leading '+' and digits, say +4689761234. This is the input to DDDS algorithm.

Yep....

> draft-ietf-enum-e164-dns-03.txt.

Actually no. The First Well Known Rule is Database agnostic and since
the domain-name specific portions of draft-ietf-urn-naptr-rr-04.txt
are steps 3-6, the First Well Known Rule should only be steps 1-2.
Which is essentially saying that the First Well Known Rule returns
the entire Application Unique String unmodified.

> 4.3.2.1.6.7.9.8.6.4.e164.arpa

The Key is derived from the Rule, but yes, for your example your first
real key would look like what would come out of step 6.

> Any subsequent substitutions shall be applied to the Application Unique 
> String, i.e.  +4689761234.

Yep...

> Personally, I would like to see the ENUM protocol in 
> draft-ietf-enum-e164-dns-03.txt modeled after the DDDS framework than the 
> transient NAPTR draft, just like what you did with URI/URN resolution in 
> draft-ietf-urn-uri-res-ddds-00.txt. 

I think that's everyones long term intent. It just didn't seem fair to
make you guys wait on the URN group to wake up and deal with these documents.

> It seems to me by reading your draft-ietf-urn-dns-ddds-database-00.txt, the 
> NAPTR algorithm is a special case of the DDDS algorithm where the database 
> is DNS and the RR is NAPTR, and ENUM is just another application using
>  DDDS with DNS and NAPTR. I am not sure how much more work needs to be 
> put into rewriting draft-ietf-enum-e164-dns-03.txt to do that.

100% correct! Actually, if you read Patrik's draft closely most of it is
already in there.

> draft-ietf-urn-dns-ddds-database-00.txt? It does not seem to me that the 
> two are totally consistent. I personally like the latter better.

As do I but since the DDDS documents are new it wouldn't be prudent to make
ENUM wait another 6-8 months for the DDDS documents to go through the 
process. The two sets of documents are technically consistent and that
should be sufficient for now. If, in the future, someone comes up with
new ENUM specific services or even a new DDDS Database (go noodle on that
one for a while! ;-), then I think it would be very appropriate to bring
those documents in line with the DDDS ones...

> services? The reason I ask this question is that in ENUM, an application may 
> like to check all the NAPTR RRs before deciding on which one to use, say 
> SIP call is preferred by the callee but the caller can only send email. 
> Here suppose both have the same service E2U.

All. As long as the regex matches and they are of the same Order 
(not preference), you get to select based on whatever criteria in the
Service field you want....

> (5) In the NAPTR definition, it seems that the flag field dictates what 
> can be put in the regexp and replacement field. For example, the "U" 
> flag requires that the regexp field cannot be empty while the replacement 
> field should be empty; the "A" and "S" flags requires that the regexp field 
> be empty while the replacement field cannot. Is this the right interpretation?

Actually no. If the flag is 'U' then, since the replacement field is a dname
and not a text field you can't stick the URL in it. In the case where the
flag is either an 'S' or 'A' then it can be in either. It depends on how 
complex the rule is. In the case where there is really no regular expression 
to be used you can stick the domain-name in the replacement field.
Its just an optimization for domain-name compression. Due to recent changes
in domain-name compression concensus, we could have dropped the replacement
field entirely. We decided to keep it just so we didn't change existing
code. Its fairly harmless...

> How about the "P" flag and the empty flag?

I doubt if the "P" flag means much to ENUM. Plus ENUM gets to decide which
of these it wants to use. Patrik's draft only allows "U" for now. "P"
was used so that folks could excape out of the NAPTR algorithm and do some
something called WIRE that was an interesting idea but never really took off.

> What is the implication of each on the regexp and replacement fields?

Same as above which is: nearly everything goes in the regexp field except
in the special case where the regexp match exactly and the replacement
is a static domain-name then you can just stick the domain-name in the
replacement field.

Here's an example from the URI Application:

One common case is where a particular URN is flat. ISBN numbers make a good
example. Let's supposes there was this mammoth ISBN database running via THTTP
on port 5000 on the host "public.isbn.org". In this case you just want to
map 'urn:isbn:foo' to "public.isbn.org port 5000 via THTTP". You could do
this:

   IN NAPTR 0 0 "s" "thttp+I2L+I2LS" "!urn:isbn:.*!thttp.isbn.org" .
   (then you'd have an SRV record that further contains the port and 
   real hostname)

See how the regular expression contains no back refernce? It isn't required
since no real part of the URI is used in the replacement section. Its
just simply saying "if it matches then just always go here". Due to DNS
requirements at the time we were forced to move this special case out
to a new dname field that could be compressed. Thus giving us this:

   IN NAPTR 0 0 "s" "thttp+I2L+I2LS" "" thttp.isbn.org

> (6) Since ENUM only returns URIs, does it mean that only the "U" flag and 
> the empty flag can be used in the NAPTR RRs for ENUM? In other words, are 
> "A", "P" and "S" f;lags not allowed for ENUM NAPTR RRs?

Patrik's draft only mentions "U" so I'm assuming that "A", "S", and "P" 
are not defined for ENUM. So no, they are not allowed.

> Thanks again for the help!

Anytime. Thanks for the nice comments on the DDDS stuff. If you have
any comments or suggestions for those documents I'd be happy to have them!

-MM