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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Wed, 28 Jun 2000 09:19:57 -0500

Patrick,

>I do not agree. You need more information than what is stored in an 
>MX or SRV, for both SMTP and LDAP and other protocols I know of.

You also need more information that what is stored to use the URL returned
from a NAPTR!  For the sames reasons an SRV _ldap_tcp or MX record does not
provide sufficient information to a client to utilize a service, neither
does a LDAP: or Mailto: URL.  Except at the most primative level, the URL
does not define the interesting stuff, the "schema" of a given service.  It
still requires out-of-band information, which at a minimum is provided in
the URL registration document, but more typically would be in a more
comprehensive service-specific document.  The SRV is exactly equivalent:  if
you register a service, you provide the same level of out-of-band
information necessary to utilize the identified resource.

For example, say I want to accept SMS pages, Store-and-Forward FAX, and
Voice messages, each addressed to my one telephone number, but terminating
on different devices.  (one goes to my mobile phone via an SMS gateway, one
to my office Ifax printer, and the third to my legacy voice mail machine).
NAPTR provides no additional means of distinguishing to the client which
record to use.  

   2.8.0.4.6.2.6.5.8.6.4.e164.int.
    IN NAPTR 102 10 "a" "smtp+N2R"     ""
"mailto:[email-masked]".
    IN NAPTR 102 10 "a" "smtp+N2R"     ""
"mailto:[email-masked]".
    IN NAPTR 102 10 "a" "smtp+N2R"     ""
"mailto:[email-masked]".

If we need to register a new service type for each messaging service, then
we have not gained much by the use of NAPTR over a similar record MX record
with a service-specific domain-name construction rule.  Except more records,
more protocol, and a need to upgrade my operating system.  

>Why do you oppose a URI as the outcome? 
NAPTR and URL's are overkill for many of the services I envision using the
ENUM service.  (store-and-forward fax for example)

	There are deployment obsticals to the use of NAPTRs that do not
exist 
 		for some of the simpler record types.  Some services just do

 		not need information beyond a simple MX record and a
service-
 		specific, pre-defined domain-name construction rule.

	There is a smallish limit to the number of NAPTRs that can be stored
		for a given telephone number, limited by the size of the DNS

 		packet. There is no way to scope the requests to a subset of
 		NAPTRs relevant to the service requested except to rebuild 
 		the mechanism currently defined for the SRV lookup.

	Artificial interdependency of protocols creates a standardization
tangle.
 		I see no reason to the advancement of the ENUM protocol
dependent
  		upon the adoption and deployment of NAPTR, a substantially
more
 		complicated	protocol than ENUM itself.

>What can you not express as a URI?

What can't you kill with a bazooka?  NAPTR and URI is simply not necessary
for many important services!  DNS resource records are a perfectly adequate
way to identify a resource!

Greg V.

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

---

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

> way to identify a resource!

True. But if I can only carry one weapon, I'd rather it be a bazooka
since I know it handles nearly every situation I'll encounter. 

I.e.  DNS records may be adequate for your very limited applications but
are you willing to handicap everyeone elses possibly slightly more
ambitious applications simply because yours don't need a particular feature?

-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: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 18:03:39 +0200

At 09.19 -0500 00-06-28, Vaudreuil, Greg M (Greg) wrote:
>from a NAPTR!

Nope. I claim you don't have to.

>Except at the most primative level, the URL
>does not define the interesting stuff, the "schema" of a given service.

In the case of LDAP, the schema discovery service is defined in the 
LDAPEXt working group.

In some other cases, people have to define new URI schemes, or 
redefine the ones they use.

As I said before, this wg is according to the charter working with 
the problem of resolving a E.164 number to a set of URIs.

>"mailto:[email-masked]".

These are all SMTP services. Not different -- from an internet perspective.

>  		packet.

Wrong. DNS uses TCP as fallback if the packet is truncated.

>  		complicated	protocol than ENUM itself.

NAPTR is already supported since a while back in Bind. I don't know 
what version was the first one supporting it.

>way to identify a resource!

I have still not seen any examples, more than "store and forward fax 
services", which is not description of a service from my perspective.

   paf

---

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

>more protocol, and a need to upgrade my operating system.

Actually, when thinking about it, IF you want to do that, I belive 
you can define new flags instead of "SMTP+N2R", i.e. a new string 
instead of "SMTP", but the best must be to define a new URI scheme, 
like IPP has done for printing.

   paf