--Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
Both the SPF and XML syntaxes do the job at hand. Both are workable.
And both are extensible. But we need to pick ONE. So the question
should be, which one has the extensibility we desire.
I appreciate the background info on IESG and IETF. It is useful. It
sounds like you are saying "Pick ONE Language" should be considered a
requirement of the group. Do you believe strongly that it should?
In the case where we have to pick one and only one language, here is a new
summary of issues and a new possible compromise position.
Position 1. In favor of XML:
1. XML is it.
* We see extensibility as a core requirement (at least syntax, but leaving
the door open for features as well). We see XML as synonymous with
extensibility, and we see a customized language like SPF as inferior in
this regard, and can clearly articulate why.
* Also, we see MARID as a part of a larger scheme of "email policy
documents" and we can clearly articulate what that means.
* There may be size issues but we are willing to deal with that.
* Supporting those domains that have already published SPF is not a big
concern.
Position 2. Opposed to XML:
2. SPF classic syntax
* Extensibility is a reasonable goal, but should not get in the way of
simplicity, human-readability, and byte-economy, which we see as more
important.
* We are not convinced of the need to bind MARID together with a larger
"email policy" document that is not yet defined.
* SPF classic is extensible by way of adding modifiers (e.g.
domainkeys=all) and by new version tags (e.g. v=spf1d). SPF records may
contain unknown mechanism (like +dk) but pre-existing implementations will
always stop and return "unknown" in that case.
* Support for those domains that have already published SPF is important.
Position 3. Implement both, let domain owners decide:
Position 4. Leave it up to the MTA:
5. XML is the standard. Receivers MAY also check other "legacy" formats.
* We believe XML is likely to take over in the future. Implementations
are considered MARID-compliant if they read and understand XML TXT records
published using a _prefix (such as _ep or _lmap)
* It's up to sysadmins and MTA implementers if they want to support SPF
records also. A large number of MTAs will choose to do this anyway, given
the large amount of data already published. SPF data will be published at
the domain itself, rather than at a _prefix label.
* It is conceiveable that market forces may continue to create demand for
SPF Classic even well after the initial deployment. If people continue to
use and support SPF Classic and XML fails to take off, a future RFC may
codify the de-facto standard.
Here is my take on this. During the jabber session, Jim Lyon expressed
that it is important to him that MARID be a part of a larger context, and
that "email policy document" is something that the world needs anyway.
This sounds "nice" BUT I don't accept this as a "requirement".
Therefore, I am willing to accept compromise position 5 ONLY if there is a
draft from MS saying "Here is why we need an Email Policy Document over and
above MARID requirements" AND that draft receives favorable responses from
MARID members.
Right now, I don't believe extensibility trumps simplicity, economy, and
the large amount of data published in SPF classic format.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>