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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 26 Jun 2000 10:39:46 -0500

Thanks for the reply.  

I expect that use of MX records directly would require a separate
mail-service specific specification of how to build the domain portion.  One
leading contender for general email is to use the ENUM domain as follows:

	[email-masked]

If the local mail gateway will accept telephone number local-part, it can
also be provisioned to accept mail addressed to e164.arpa.  At that point
the local part is examined to determine who it goes to internally.  (using
laser?)

Just a suggestion for an example.  Another would be to show the use of SRV
records to connect to a named LDAP service. (see
draft-vaudreuil-enum-e164dir-00.txt.

Greg V.

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Monday, June 26, 2000 10:07 AM
To: Vaudreuil, Greg M (Greg); [email-masked]
Subject: Re: [Enum] NAPTR is not as an ENUM Requirement

At 09.58 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote:
>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.

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.

>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

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.

>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!

Ok.

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

   paf

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

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 26 Jun 2000 23:29:31 +0200

At 10.39 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote:
>mail-service specific specification of how to build the domain portion.

The same thing is true for LDAP. I myself thought from the beginning 
that SRV RR was enough, but it is not. You need in many protocols 
like SIP, SMTP and LDAP some local metainformation when connecting to 
the service which you have just found.

The reasons for having NAPTR still in the dratf is because:

- The idea with ENUM was to go from E.164 to URI, because then
   you will get both local part and domain and whatever else
   is needed in that (random) URI scheme
- I wanted _one_ way of handling extra protocol specific
   information, and the world seem to agree on using URIs.

This even though, as you point out, the most important part of the 
draft is to tell how to map a E.164 into a domainname -- which then 
can be used in whatever way one wants.

>One

:-)

The only downside with this is that the "holder" of the E.164 number 
also have to have one mail domain for the domain in question, and 
also one local part. The chance is that the user already have one 
email address at some random ISP, for example 
"[email-masked]" and it might be problematic for joe to set 
up another domainname. Hotmail doesn't help him.

The ability to have "mailto:[email-masked]" in a NAPTR which 
have as a name the E.164 number is what I think "a good thing".

But, I am definitely not opposing your ideas. I am just explaining 
why I think it is important to have NAPTR still in the draft.

>draft-vaudreuil-enum-e164dir-00.txt.

I understand the logic (I think), but I have problems with the 
examples. For example "5.1 Example: Hypothetical Reachme Service" 
which shows how to find a specific LDAP server.

It doesn't talk about what query to issue at that LDAP service. You 
talk about "

>The client can then use LDAP with the reachme schema to determine
>the set of communications technologies available for +1 613 555
>1212.

Does that specify exactly what query to issue? In that case, where?

In the case of LDAP (and also SIP) I of course (as you understand) 
rather see the URI be in an NAPTR record instead of using out of band 
information.

     Patrik