In
<81AC085044D04B429F5FB883D94FA1AF3A0D0F(_at_)df-fido-msg(_dot_)exchange(_dot_)corp(_dot_)microsoft(_dot_)com>
"Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
The point of using XML is to have confidence that we have sufficient
syntactic flexibility to describe the probable future extensions,
whether they contain data in-line or they contain pointers to external
data.
I have yet to hear of any extensions that can't be reasonably handled
with SPF modifiers. Frankly, after 6 months of people looking over
SPF, there haven't been very many good/popular ideas of future
extensions to SPF.
If we want complete confidence that we have sufficient flexibility, we
have to mandate Java in a sandbox or ActiveX downloads or something.
XML appears to offer very little real usefulness, and it adds a huge
amount of bloat. As someone pointed out, you can write a complete SPF
parser in just about any language in the amount of space that the C-ID
XML schema consumes. Debugging the schema alone and making sure it is
right may well be more work than creating an SPF parser.
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. [...]
2. It MUST be possible to extend the kinds of policy information that
get published in the future, without breaking previously deployed
interpreters. (This pushes us toward XML, plus requiring interpreters to
ignore tags in namespaces they don't understand.)
This may push us toward XML or Java in a sandbox, but that doesn't
mean we should go that far. RMX and FSV are probably not extendable
enough, but I think that XML and Java are way too much. SPF appears
to be the right tool for the job.
3. It MUST be possible for EVERY [policy to not fall back to TCP]
I would humbly suggest that people who don't like XML, or don't like TXT
records, or don't like something else, either need to argue that the
above requirements aren't appropriate, or they need to explain why their
favorite alternative does a better job than the current design of
meeting the above requirements.
Much of the resistance to XML on the SPF list appears to be from mail
admins who don't want their mail servers to have to parse XML.
We must acknowledge that both the domain owners and the mail admins
have, effectively, veto power over MARID. Giving the choice to domain
owners about which format to publish runs the very real risk that mail
admins will veto MARID.
The current SPF-ID draft calls for all the ad-hoc parsing of macro
strings and CIDR notations that pure SPF requires, *PLUS* you need to
do XML parsing. This XML parsing can't be some tiny subset of XML, or
you don't gain the advantages that XML lends. The XML however, is
coming from third parties that can not be trusted, so you have to
worry about using a stock, generalized XML parser that can open to
abuse or bugs.
XML runs counter to the KISS principle: It isn't needed, it adds bloat
to the DNS, it increases the chances of bugs (exploits, DoS attacks,
incompatibly interpretations, etc.), and it adds bloat to the MTAs.
I think we need to turn this around:
Please justify the need for XML. If you can't show clear reasons why
it is required, XML should be tossed out.
-wayne