> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf