We also certainly don't want to put yet more hurdles into the
path of getting drafts published. Does the RFC editor have to
verify the URLs and that they still exist? Do we worry about
advertising pages and implementations that turn out to be
malicious? I'd really rather not have to deal with an RFC
where a domain of a fledgling open-source project was taken
over by a malware distributor.
I would like to provide one recent example. In the EMU working group we
worked on a protocol, called EAP-GPSK http://www.ietf.org/rfc/rfc5433.txt.
The work was done in a design team, it took a very long time (the first
design team draft dates back to May 2006).
Jouni Malinen implemented the protocol in 8 hours! Jouni also provided a
number of suggestions and we put him into the acknowledgments section.
Before the draft got published as an RFC the reference to his implementation
was removed by the RFC Editor. The RFC Editor also verified the URL and it
was not correct anymore (but that's another topic).
As mentioned in
txt the problem with feeding experience with running code back into the
specification work is elsewhere.
There are three main problems:
* Almost random changes to the specification make early implementation work
almost useless (if your goal is to produce code that aims having code for a
specific RFC after all). Since it takes so long to finish the
standardization work it is often not possible to wait till the RFC comes
* Nobody cares if you have running code. Requests to substantially change
the specification often come at a late stage. Even IESG members have already
re-written specifications during IETF Last Call. As a joke, I suggested to
just submit the table of contents to the IESG and then start the work there.
* Finally, because it takes so long to finish specifications the 3-level
Standards Track process is rarely utilized anymore. That process considers
interoperable code but what does it help?
Ietf mailing list