On Fri, Jan 14, 2005 at 03:18:45AM +0100, Julian Mehnle wrote:
Stephane Bortzmeyer [bortzmeyer(_at_)nic(_dot_)fr] wrote:
Julian Mehnle <bulk(_at_)mehnle(_dot_)net> wrote
But now we are editing the official SPFv1 specification, which is
not required to confine itself to simply document existing
implementations.
I do not agree. The good thing about SPF (specially when you compare
with Sender-ID, DomainKeys or IIM) is that it works today, it has
several interoperable implementations and it has been tested in the
wild.
If we move from that, we lose a lot and we are not sure we improve
anything.
One important point of SPF is to work _well_ (surprise!). We are probably
able to fix SPF's present flaws (e.g. that, in the absence of the zone cut
defaulting, an SPF record would have to be specified for every single
domain/host name), which bears real value. If we are careful, we can be
sure to only make changes that improve the situation.
Stephane is, I'm afraid, 100% correct. I could scarcely believe what I
was reading when I saw your email containing the chunk that Stephane
quoted.
For goodness' sake, *please* get the definition of the *current* SPF
out of the door, done and dusted *before* moving on to anything at all
new. This would appear to me to be critical to widespread acceptance of
SPF.
Right now you (the SPF Council) need to be finishers, not people who go
off and have bright ideas to save the world. If you don't tidy up the loose
ends we already have lying around, no-one else can, and SPF as a standard
will be as much vapourware as ever.
I vote for a different method: create, as soon as possible, a RFC
describing the *current* SPF. After that, try to create a SPF 2 with
new bells and whistles. At the present time, many people regard SPF as
no more mature than Sender-ID since none of them has a RFC (or another
formal specification).
Not keeping 100% backwards compatibility does not imply delaying the
standardization process.
Even if you're right, it's not about process, it's about hearts and minds.
Right now what SPF needs is a solid, set-in-stone standard document that
will never change, and which people can point at and say "that's the
standard, we've got thousands of people using it, and it works".
You don't get to say that if you keep on changing it.
Of course, since there was no proper specification, we cannot expect
that every existing implementation will follow the RFC. But we can
move as close as possible. If we insist on the "zone cut" search, for
instance, 0 % of exiting implementations will be conformant...
I don't think that's a big problem. All the implementations aren't used
widely yet, and most of them are still under development, so new versions
would be released (and used) soon anyway.
You have to draw a line in the sand and say "no more". Be ruthless. There
is *always* some great new feature that you can add to make it even better,
but if you never stop to let the world catch up with you, they'll give up
and follow someone who will.
Look, if the gain from zone cut defaulting wasn't as significant as it is,
I wouldn't bother arguing about it...
Actually, I'm not convinced that the gain is significant. As Paul Vixie
said in the mail that William quoted, use m4 or some other automated way
of generating records, or hassle your named vendor for more toys.
And what exactly would your reasons be for removing the new RR type from
the spec? It doesn't even make existing implementations incompliant.
This is possibly the one grey area where you can get away with it, but only
because this whole aspect of the spec is currently hypothetical; changing
something that is only hypothetical in the first place really won't affect
anybody.
Time to dig in your heels and draw that line in the sand, please. In fact,
it should probably have been drawn 9 months ago -- the longer we go without
a fixed standard, the worse our chances.
Cheers,
Nick