It's only needed as the initial deployment option. +5 years from now it
will be a mistake that we are stuck with for another +20 years.
On 6/10/2004 12:16 PM, Bob Atkinson wrote:
No; this is not acceptable. TXT is not a prototyping notion here; it's
the mainstream deployment option. Indeed, pragmatically, with that
reality there's no point to a dedicated RR type (though having one
additionally isn't fatal, just misguided).
You've missed the arguments, but I find that I'm at a loss what further
I or Jim could say that might alleviate that problem, so I'll not say
anything further on the topic.
Bob
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Eric A. Hall
Sent: Thursday, June 10, 2004 9:58 AM
To: ietf-mxcomp(_at_)imc(_dot_)org
Subject: suggested path and arch
Let me see if I can draw the relevant threads together into a
framework
proposal that is viable to everybody:
Names should have a magic label, eg "_MARID", that is bound to the
domain name of the email address. This allows multiple RRs to be
bound to the name, and allows delegating the name.
If the name does not exist and an SOA NXDOMAIN is returned which
references a different domain than what was used in the original
query, apply "_MARID" to the SOA domain. If NXDOMAIN is returned
for that, bail. This allows leaf-nodes to have explicit entries,
and for a master entry to act as a fallback for an entire domain.
For developmental and proto-typing purposes, we should use a TXT
RR, and we should document the structure of that RR in an
informational reference spec.
We should develop a binary RR that satisfies the considerations
associated with wide-scale deployment (avoiding TCP fallback,
etc). The result of this work goes standards-track, and is the
final target for deployment.
An additional informational doc can describe coexistence and
migratory considerations.
Disucssion points beyond this approach are the structure of the
textual
and binary data, the use of pointers to external policy docs, and so
forth, all of which falls into the proto-typing work item.
--
Eric A. Hall
http://www.ehsco.com/
Internet Core Protocols
http://www.oreilly.com/catalog/coreprot/
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/