ietf-mxcomp
[Top] [All Lists]

RE: suggested path and arch

2004-06-10 10:16:04

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/



<Prev in Thread] Current Thread [Next in Thread>