Re: Request for comments

Keith Moore wrote:

> sounds much like what the RESCAP WG is working on.

Not sure whether to agree or disagree. :)

>  perhaps you should bring your proposal there.
>
> the question is not whether this will work, but whether it's better to
> put stuff in DNS or to vector it to a separate lookup service.

Exactly. The choice will have various trade-offs for this and similar
problems.

- Loosely-coupled query framework - Result based on queries to DNS, Metadata
server, and Data server, or a tighter coupling in terms of role of a
particular protocol server (for example, ENUM (and EADDR) using DNS for
functionality beyond SRV and A queries).

- Access control in terms of who can ask and/or update what.

- (Ab)using an existing, deployed protocol or defining one anew? What criteria
define an abuse and are they reasonable in contrast with other factors in
favor of using something extant? What criteria justify creating a new
protocol? The dreadful question IMHO seems to be where do you stop touching
DNS? Also, where to start and stop using directory services like LDAP?

I don't know.

> > This message is a request for comments on draft
> > http://www.ietf.org/internet-drafts/draft-singh-eaddr-00.txt. This memo
> > simply extends the ENUM idea in RFC 2916 to get various contact URIs
> > using an email address, instead of a telephone address, as the starting
> > point. The question to this group is if this is a useful idea to pursue.
> >
> > Abstract:
> >
> > "ENUM uses NAPTR DNS Resource Records (RRs) to map an E.164 telephone
> >  number to Uniform Resource Identifiers (URIs) of other ways of
> >  contacting (for example, by email) a specific resource. This memo
> >  proposes an ENUM-like service called EADDR where an email address,
> >  instead of a telephone number, is used as the key to fetch other
> >  contact URIs. At human level, EADDR seems more useful than ENUM
> >  because it is easier to remember an email address than a telephone
> >  number as the key. At machine level, both services are equally
> >  useful."
> >

Received on Thursday, 15 November 2001 18:44:02 UTC