In arguing against extensibility, John Levine argues that it's a bad
thing (he used the word "chaotic") to have information in a MARID record
that is not understood by everyone.
To rebut this, I note that substantially every successful data format
and protocol contains buckets for information that isn't globally
understood. For example, consider headers in RFC 2822 mail messages.
The general ethos is that if you see a message that contains a header
you don't understand, you just ignore it. Without this ethos, many
useful extensions (MIME, for example) would have been impossible.
A similar story applies to the headers in HTTP. Without the ethos of
ignoring what you don't understand, many commonly used features would
have been impossible.
Similarly, in RFC 2821, responses to EHLO contain a list of extensions,
many of which the client doesn't understand. Again, the ethos is that
you completely ignore anything you don't understand. Doing so is
exactly what enables SMTP extensions.
Or look at DNS. In a DNS packet, there's only a single unassigned bit,
and some deployed DNS software gets pissed off if it's not zero. This
fact, more than any other, has hampered attempts to expand the DNS
protocol.
Or look at the difference between ASN-1 and XML. ASN-1 can describe
anything for which the entire schema is known in advance, but it's hard
to extend a schema after the fact. XML, on the other hand, has the
clear ability to carry goo whose semantics are not known by older code.
Guess which has been more successful.
Given that we *know* that we'll need more information in the future
(most of us are here to reduce spam, not just authenticate MTAs), it
behooves us to plan the extensibility now. SPF's current modifiers are
a step in the right direction (they have the ignore what you don't
understand ethos), but as I've argued elsewhere, they aren't sufficient.
The reason they're not sufficient has to do with cases where you need to
attach new pieces of information to particular SPF mechanisms; SPF
merely gives you a way to attach new information to the whole record.
For this same reason, John's suggestion of just having a pointer to a
separate XML document isn't sufficient, either.
-- Jim Lyon
PS: John also continues the misconception that anything that uses XML
will be big enough to require DNS TCP. This just isn't true. It looks
like most XML-encoded stuff runs about 20% bigger than SPF-encoded
stuff. The size concern might be persuasive if typical SPF records were
pushing 400 bytes, but they're not. They're usually around 50 bytes.
The number of characters in the XML framing is just not that big an
issue. When you're spending 18 bytes to represent an address range, it
just doesn't matter that much whether you frame it with "+a:" and space,
or with "<r>" and "</r>".