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

From: "Anne Brown" <[email-masked]>
Date: Mon, 26 Jun 2000 10:45:14 -0500

As stated in the requirements draft, the ENUM system provides a service for
the retrieval of service-specific endpoint addresses OR the retrieval of the
addresses of servers, if  available, which may contain this endpoint
information.  The RR is not required to provide resource-based and
service-specific information as this type of information will be very
difficult to maintain at a global level.  This will be especially true for
enterprise-based information.

Though I don't have any proposed text or examples to contribute, I would
like to see text in the abstract and introduction, stating that there are
other alternative uses of the ENUM service than retrieval of
service-specific information.  

Regards,

Anne Brown
Nortel Networks
[email-masked]
+1 613 765 5274

-----Original Message-----
From: 	Patrik Fältström [mailto:[email-masked]] 
Sent:	June 26, 2000 11: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

---

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

At 10.45 -0500 00-06-26, Anne Brown wrote:
>As stated in the requirements draft, the ENUM system provides a 
>service for the retrieval of service-specific endpoint addresses OR 
>the retrieval of the addresses of servers, if  available, which may 
>contain this endpoint information.

I quote the charter of this Working Group:

>This working group will define a DNS-based architecture and 
>protocols for mapping a telephone number to a set of attributes 
>(e.g. URLs) which can be used to contact a resource associated with 
>that number.

This is what this working group is working with.

That said, the mapping from a E.164 number to a domainname can be 
(re)used for other things, but that is up to other working groups to 
talk about.

    Patrik