yOn Mon, 31 May 2004, Greg Connor wrote:
Back to the main point about extensibility.
Greg Connor wrote:
| 0. Current SPF method:
| v=spf1 +ptr +mx ?all
| v=spf2 +ptr +mx +domainkeys -all
I casually wrote "version numbers don't cut it" in a recent message. Let
me elaborate a bit. I think version numbers are great for products, but
not so great for protocols. First off, it suggests that there will be a
central authority determining what goes into the "next" version. (That may
not be the intent, but it is a conclusion that many readers will come to on
their own, based on how they already understand "version numbers" to work)
There is a central authority. It's called the SPF developers, or the IETF
list or (insert politically appropriate body here);.
It is possible to have a version split off from the numbered sequence (like
1, 1a, 1d). That allows you to add one feature pretty easily, but if there
You'd be welcome to do so but noone else would support it. It would
be useful for testing in small environments, but useless in the wider
world. And in a closed environment, who cares about version numbers?
are two or three features people want to add, you would have to have like
four or more versions of your record, to support all possible receivers (1,
1a, 1d, 1ad).
I think this puts too much burden on the publisher, to cater to the many
possible permutations of receivers... I think it ought to be the other way
around: the receivers ought to be flexible enough to cater to the many
types of publishers out there, within the limits of their currently loaded
feature sets.
Version numbers are OK for "major" version changes (of the type that make
the whole language incompatible with older parsers). But I think I would
like to have a way to add features incrementally too, that is not as
cumbersome as changing the version number.
That is the main reason I am harping on extensibility. The XML issue has
just brought it out into the open :)
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/