Jim Lyon wrote:
In summary, the requirements that drove the
current design include:
1. It MUST be possible for organizations to publish email
policy records without installing any new software. (This
pushes us toward TXT records.)
Ted Hardie wrote:
This isn't a MUST and can't be; it has to be an assessment
of the rewards of the deployment versus the cost.
Attempting to short circuit that so absolutely is a pretty
clear signal that the rewards won't be sufficient to warrant
significant time or effort on anybody's part. That's not a
signal we want to send, at least in my personal opinion.
I have to disagree with this. If I had to install new software, I would
never had published my SPF record in the first place (NTM that there is
no software that I really like for my platform as of now).
The way to get a new something adopted is to make pre-requisites small
and even better non-existent. Reading it backwards, the best way to kill
MARID before it's even born will be to require domain owners to install
some software that might not even exist yet, that might (and likely
will) be buggy, might be costly, etc; for a protocol that does not exist
this is suicide.
It MUST be possible for organizations to publish email
policy records without installing any new software. I
would not do it otherwise and I'm not the only one.
This is a _strong_ MUST. Don't confuse organizations that want to
publish email policy records and organizations that want to test said
records.
There is an aspect of Jim's comment that deserves clarification.
Any proposal would indicate how it is to be implemented allowing
any organization equal opportunity, but all proposals will require
software if utilized. Jim appears to be arguing what software is
to change. In addition, retaining control of these records by the
standards process appears to be another concern. To ensure the
integrity of DNS system, the size of these records must be
constrained. The "core" proposal would allow any "organization" an
ability to piggy-back on such records hundreds or thousands of bytes
of perhaps a proprietary format. I see such an open-ended approach
an invitation for trouble. Consider choices from deployment and
engineering aspects without a predisposition as to where these
changes occur, but at the least, retain control of the standard to
ensure both the integrity of the system and to afford all
organizations an equal opportunity for its implementation.
-Doug