On good and bad RFCs

The worst of the nine RFCs I have written is doubtlessly 5465, IMAP NOTIFY, which should have been good but is a disaster. Its main characteristics are that it's complex (both in terms of number of rules in the RFC and the number of features needed in a server), that it's much more complex than the first of its input documents, and that noone implements it.

My best may be 4978, IMAP COMPRESS=DEFLATE, which is much shorter than 5465, roughly as complex as its first draft version was, contains an informative section with implementation advice, and is widely implemented. Perhaps it should not be — perhaps people ought to use IMAP on top of compressed TLS, not compressed IMAP. Which makes it even more surprising that the document is so widely implemented.

Both contain good examples and are, if I may say so myself, lucidly written. 5465 is lucid about many too many details, 4978 is lucid and restrains itself to the core of the matter.

Is 4978 widely implemented (and 5465 not) because it's simple? Quick to read? Because it contains numbers to persuade potential implementers of its utility? Because it contains implementation advice? Because Dave Cridland bribed and cajoled a few people into implementing it, and we then had a successful interop test? Some combination? Something else? I have no idea.

I'm currently working on a tenth RFC, about how servers can present internationalized mail to conventional clients, and I think it'll be good. This time, when someone asks me to add more text, I try to improve what's there instead, and I really, really want to keep the number of rules close to zero and restrain the document to the core of its subject.

(I suppose 2782, DNS SRV might be considered my most successful RFC. But I think 4978 is it, since it's so much more successful than many comparable RFCs, while SRV is only one of many DNS RRs to be used widely. Besides, it's easier to compare and contrast 5465 with 4978 than with 2782.)