I'm not sure what "requirements" means in our context, but I don't
like any of the meanings I can think of.
It certainly seems logical that one would start by defining
requirements and then refine them into a spec and eventually into
working code. This is basically the waterfall model of software
design that was popular in the 1960s. It's fallen our of favor,
because it's proven many times to be a one-way ticket to disaster.
The short reason is because if we knew what we were going to build, we
would have built it already.
One version of requirements I can imagine is general motherhood-type
principles on which we all agree, like it has to work with existing
SMTP implementations, it has to work when deployed incrementally
without a flag day, it has to scale to a billion hosts or whatever the
target size of the Internet is these days, and, oh yes, it has to make
it at least somewhat more likely that a recipient can tell whether the
claimed sender of a message (for some definition of sender) is the
actual sender. Those are all fine, but I think we all know them
already, so there's not much point in reiterating them.
Once we get past the area of unanimous agreement, we move into the
realm of war by proxy. We have at least five proposals on the table,
and any detailed arguments about requirements will in fact be
arguments among various proposals. If I like Domain Keys, I think
it's a requirement that the verification keys be in the DNS and a
domain be able to publish multiple keys. If I like TEOS, I think it's
important that a signature include forgery-resistant author assertions
about the message. And so on. These arguments aren't hypocritical.
If I think a proposal is good, it's because I think it does the right
things, so of course those things should be in the requirements. If
we're going to argue proposals, which we will, we should admit that's
what we're doing and go ahead and do it.
It seems to me it would be much more productive to examine the
proposals we have, particularly the ones that have been implemented
(DK and TEOS at least, probably others), and see if we can reach
agreement that at least one of them does something worth
standardizing. No doubt there will be minor tweaks here and there, I
hope not so extensive as to invalidate the experience of existing
implementations, but I'd be a whole lot more comfortable moving ahead
with something where there is at least some evidence that it works.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
http://www.taugh.com