OK, so nearly everybody seems to think that I misunderstood the
motivations of early implementation contributors, so let's ask them
directly.
If you did contribute an early implementation or did think of
contributing but finally didn't, please respond to this email with
your story. Interesting points are why you did (or not) the early
implementation, will you do more, what would motivate you to do more
early implementations, etc... You can send your responses directly
to me if you do not want to respond publicly - I will keep them
confidential and post just a summary of the responses.
For the purpose of this exercise, an early implementation is an
implementation of an IETF protocol under development as an
Internet-Draft.
You asked..,. so here's my data.
In recent times I've mostly been involved with the Sieve WG. According to my
tally the Sieve WG has had a total of 35 drafts on its plate at one time or
other. Of these roughly 13 have become RFCs and 10 more are in the RFC Editor
queue (my numbers here may be slightly out of date).
Out of all of these I implemented 21 of them while they were still unapproved
drafts: 3028bis, relational, relational-bis, subaddress, subaddress-bis,
spamtest, spamtest-bis, copy, vacation, imapflags, variables, environment,
editheader, notify, notify-mailto, refuse-reject, date-index, ihave, regex,
external-lists, and dsn. When you take into account that at least 4 of these
drafts were never serious contenders for standardization, that's an early
implementaion rate of well over 60%.
I have also implemented body and mime-loops, but only after they were last
called. Implementation of body turned up no late-breaking issues in the draft
(although I now wish I had lobbied for one or two additional restrictions).
Implementation of mime-loops, OTOH, turned up a couple of omissions and errors,
one of which really needs to be addressed before publication. So that's a case
where earlier implementation would have helped a bit.
Sieve-in-xml is sort of a special case. In one sense I haven't implemented it,
but in another Sai and I wrote the XML schema, Relax NG grammar, and conversion
stylesheet that apppear in the draft, which collectively constitute at least a
partial implementation. Other folks here at Sun have also implemented an
earlier version of this draft in its entirety.
Additionally, at least two drafts, notify-sip and convert, are for various
reasons ones we are unlikely to ever implement. As such, there's no way I could
justify doing an early implementation of either one of them.
I'm the author or coauthor of six of these drafts. I implemented all but one of
these as I was writing the document (all six if you count sieve-in-xml). I
haven't checked to see if I'm listed as a constributor in most of the others
but I suspect I am.
As for "draft drift", i.e., things change a bunch after implementation,
requiring a lot of implementation retooling, that has not been a serious
problem - so far at least. (A bunch of these documents are still just drafts so
that could change.) The two drafts that changed quite significantly along the
way are imapflags and notify. Changes to imapflags required some recoding, but
nothing too onerous. So far I have only sketched out what's needed to get our
notify and notify-mailto support up to spec, and it looks a little tricky but
doable. In this case the bigger issue is that due to customer requirements we
had no choice but to deploy the original version of notify and notify-mailto.
We're now stuck with supporting the old notify in additional to the new, which
grots up the code a bit, and having to write a tool to up-convert existing
scripts to the new notify format.
Finally, refuse-reject proved to be an interesting case for us. One of the
provisions that got added to that draft along the way (production of SMTP-time
errors when possible) would have been very difficult if not impossible for us
to implement. But as the draft proved to be contentious and took a long time to
get through the process, some largely unrelated product enhancements changed
that and made implementation not just possible but fairly easy.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf