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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 26 Jun 2000 09:58:15 -0500

Coming out of the Adelaide meetings, I understood we had agreement that
NAPTR is good and useful but not a requirement for the deployment of the
ENUM service.  The particular resource records to be queried are a function
of the higher-level service being requested.  For example, if one is sending
regular SMTP mail using telephone numbers, only an MX record is necessary.
No additional NAPTR related processing should be required.

This separation of the RR type from the ENUM protocol is not clear and
should be.  In addition to clarifying the many editorial references
suggesting NAPTR record queries are the only ones used of ENUM, I suggest
adding an example (maybe using MX) to clarify that NAPTR is not required.

The specific references I suggest editing are:

1.1 Introduction

Was:
    Through transformation of E.164 numbers into DNS names and the use
    of existing DNS services like delegation through NS records, and use
    of NAPTR[1] records in DNS[4], one can look up what services are

Suggested: 
    Through transformation of E.164 numbers into DNS names and the use
    of existing DNS services like delegation through NS records, and
resource
    records such as NAPTR[1], or MX records in DNS[4], one can look up what 
    services are

3. Indentifying available servers

This section is very misleading.  This entire section needs to be recast as
one of at least two examples.  The current section reads as a requirement to
support only NAPTR for the ENUM service even though there are no
"requirement words" such as MUST and SHOULD.  In part this is because this
section is longer than the ballance of the document!

Greg V.

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 26 Jun 2000 17:07:22 +0200

>No additional NAPTR related processing should be required.

That is correct, if you know that the recipient can handle email. 
Also, an MX doesn't give you the local part to use.

Because of this, I have tried to solve the problem with going from an 
E.164 number to a URI, which can be a mailto URI which is what one 
should use.

But, I understand what you are talking about.

>     records such as NAPTR[1], or MX records in DNS[4], one can look up what

You can not look up what service to use using MX records. That can 
only be done via NAPTR records.

But, I will try to change the text so this is more clear.

Personally, I don't think MX is possible to use as you (as I said 
above) doesn't know the local part of the mail address to use. If you 
use the E.164 number as a replacement for the domain part, and know 
by out of band communication (for example) what the local part is, 
_then_ MX can be used.

>section is longer than the ballance of the document!

Ok.

Will be changed (the example is wrong anyway...).

   paf