Subject: RE: [Enum] NAPTR is not as an ENUM Requirement

From: "Robert H. Walter" <[email-masked]>
Date: Tue, 27 Jun 2000 12:30:08 -0400

Patrik Faltstrom wrote:
> My take is that I have not seen any other proposal on how to take an
> E.164 number and get URL(s) back than using DNS and NAPTR RRs.

Patrik please see "Internet-Telephony Directory for Mapping E.164 to
Internet Addresses"

http://www.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt.

The draft describes an approach that takes an E.164 number and
service protocol (e.g. SIP, VPIM, etc.) and returns a URI using
TXT RRs. Note delegation of the E.164 name space is described
using conventional NS and A RRs which eliminates the use of CNAME,
DNAME RR's.

Bob Walter, CTO
NetNumber (www.netnumber.com)

======================================================================
Robert H. Walter                          Voice: 978.454.4210 x24
NetNumber.com, Inc.                      Mobile: 617.828.6443
650 Suffolk Street                          Fax: 978.454.5044
Lowell, MA  01854                         Email: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 07:21:12 +0200

At 12.30 -0400 00-06-27, Robert H. Walter wrote:
>TXT RRs.

You can not use TXT RR for that.

The DNS wg's in the IETF opposes use of TXT RRs for similar purposes, 
so this is a showstopper.

When storing URI's in the DNS, NAPTRs are used. Full stop.

   paf

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 Jun 2000 23:13:26 -0700

>> The draft describes an approach that takes an E.164 number and service
>> protocol (e.g. SIP, VPIM, etc.) and returns a URI using TXT RRs.

to stick my dnsext co-chair nose in and explain.  using TXT RRs to
substitute for what would normally be a 'proper' RR is seen as an
end-run around the review and registration process.

randy

---

From: "Robert H. Walter" <[email-masked]>
Date: Wed, 28 Jun 2000 09:46:11 -0400

Randy, Patrik,

Thank you for your comments.  I'm in complete agreement. Section 4.2.1
of http://www.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt states
that use of either TXT and NAPTR are effectively end-run around's of the
review and registration process.  TXT RRs are simple, meet the requirement
of mapping domain names to URI's, however, they are semantically weak and
must derive their context from the zone they reside in. NAPTR RRs are
complex in comparison, can map domain names to URI information when
formulated as a regex, but are not well suited for this purpose.  The
following is quoted from the abstract of RFC2168 - Resolution of Uniform
Resource Identifiers using the Domain Name System 

  This document describes the first, experimental, RDS. It is
  implemented by a new DNS Resource Record, NAPTR (Naming Authority
  PoinTeR), that provides rules for mapping parts of URIs to
  domain names.

The NAPTR RR is specifically designed to map parts of URI's to domain
names, not map domain names into URI's.  If you accept that both TXT
and NAPTR RR's are both end-run arounds then one must either choose or 
wait for the creation of a new RR that is specifically designed for
mapping domain names to URI's.  I would welcome the opportunity to
work with the IETF to define this new RR.

Bob

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Wednesday, June 28, 2000 2:13 AM
To: Patrik Faltstrom
Cc: Robert H. Walter; [email-masked]
Subject: RE: [Enum] NAPTR is not as an ENUM Requirement

randy

---

From: Michael Mealling <[email-masked]>
Date: Wed, 28 Jun 2000 10:01:09 -0400

> work with the IETF to define this new RR.

Actually you are incorrect. Those are older documents that have been
and are in the process of being updated due to input from the working group.
NAPTR is not meant to only map URIs to domain-names. That is simply
one 'application' (to use the language from the documents I'm updating).

Here's the rough outline (no technical changes, just clarifications 
about what areas you can use NAPTR for):

There is this thing called a Dynamic Delegation Discovery System.
It is what we used to call the RDS but RDS was specific to URIs.
A DDDS is nothing more than the iterative rewrite algorithm. In order to 
use it you have to specify an Application and at least one Database.

The Application gets to define the Appliction Unique String
which is the thing the algoirthm works on to find out specific
syntactic rules for delegation. In the case of URI resolution, any URI
is the Application Unique String and the inttended output is 
a server that can authoritatively tell you things about it. 
In the case of an ENUM application the Unique String would be
the e.164 phone number and the output would be URIs that
identify services. You can use any Database with the Application.
The NAPTR record is how records are encoded in the DNS DDDS Database.
Domain-names are that database's keys.

Justic Couch defined a database using a flat text file for use with
the URI Application. He needed it for URNs in VRML apps where the
resolution information was mostly known a head of time.

I hope to have new versions of these documents explaining all of 
this come the first of next week. The important thing to note
is that they do not change any technical aspect of how NAPTR
works. Specifically, the ENUM drafts will not have any technical
aspects of NAPTR changed out from underneath them.
They just clarify that you can do it and how you say what it
is you are doing...

-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: Richard Shockey <[email-masked]>
Date: Wed, 28 Jun 2000 09:57:18 -0500

>end-run around the review and registration process.

Thanks Randy... I need clarification on one issue... As I understand it 
..and I could be wrong here,  a request for NAPTR records will return ALL 
records associated with a particular number.

If there are _lots_ of services associated with a phone number it is 
conceivable that one could reach the 256 byte limit on UDP transmission and 
the NS would then signal the resolver to open up a TCP connection for the 
retrieval of the records.

However if SRV records are used ...the resolver can request _only_ those 
records associated with a service, correct?

I'm not arguing for or against the use of NAPTR vs SRV. I restate my belief 
that these definitions and any appropriate IANA registration must come from 
the appropriate application WG.

Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Randy Bush <[email-masked]>
Date: Wed, 28 Jun 2000 08:28:10 -0700

> records associated with a service, correct?

no time to look at docs to be sure my foot is in my mouth.  but the
essential concept is that of rrs of the same label-class-type will be
returned as a set.  srvs have different names for different services.
naptrs do not necessarily.

you could get a partial with trunc set.

but, if you really expect a glopload, look at requesting with edns0 set and
that should make you happier.

randy, way out on a limb

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 17:50:17 +0200

At 09.46 -0400 00-06-28, Robert H. Walter wrote:
>NAPTR RRs are
>formulated as a regex, but are not well suited for this purpose.

Why are they not well suited?

Have you read draft-ietf-urn-naptr-rr-03.txt?

>names, not map domain names into URI's.

Nope, it is designed to map arbitrary text into some other text using 
regular expressions. That is why the text about non terminals in the 
enum draft is written as it is.

     paf

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 18:07:49 +0200

At 09.57 -0500 00-06-28, Richard Shockey wrote:
>Thanks Randy... I need clarification on one issue... As I understand 
>it ..and I could be wrong here,  a request for NAPTR records will 
>return ALL records associated with a particular number.

If you query for a domainname and a specific RR and class, you get 
back all records matching that request.

>conceivable that one could reach the 256 byte limit on UDP 
>transmission and the NS would then signal the resolver to open up a 
>TCP connection for the retrieval of the records.

The limit is not 256 bytes, but you are in principle correct.

>However if SRV records are used ...the resolver can request _only_ 
>those records associated with a service, correct?

See above.

On the other hand, you don't know beforehand what services to ask for 
when you only have the E.164, so you might have to query for a number 
of SRVs.

    paf

---

From: "Robert H. Walter" <[email-masked]>
Date: Wed, 28 Jun 2000 14:08:10 -0400

>Why are they not well suited?

NAPTR is not well suited to map domain names to URI's because
it envolves non-trivial regular expression processing by the
client application and/or resolver.  If the Basic NAPTR Algorithm
is followed, the regex field must be matched and processed to
obtain the resulting URI.  The replacement field can not be used
because it MUST be a domain name.  Don't misunderstand me, all of
this can be can be implemented... IMHO it's simply over-kill and
not well suited to the objective of SIMPLY mapping a domain name
to a URI.

Bob

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 21:44:43 +0200

At 14.08 -0400 00-06-28, Robert H. Walter wrote:
>client application and/or resolver.

Ok, then we have different opinion whether regular expressions are ok 
or not. I felt that

(a) In any application which reads any other RR from DNS than type A 
have to do quite some stuff to get the data anyway
(b) In any application which tries to deal with abstraction of 
services will be complicated anyway, so a regexp implementation will 
be a tiny fraction of the code you need
(c) Libraries exists on the net which implements regular expressions

>If the Basic NAPTR Algorithm
>because it MUST be a domain name.

I know, this is one bug in the draft.

>Don't misunderstand me, all of

Ok.

I don't think the whole algorithm will be simple, but now I 
understand where we don't agree.

   paf