Keith Moore writes:
if we had tried to sort out all of these issues, we'd have missed the
opportunity to use 2822 as an RFC number
It's cute to replace 822 with 2822. It's mind-bogglingly stupid to use
that cuteness as an excuse for ignoring issues. This is supposed to be
a helpful document for implementors, not an April Fool's RFC.
Well, that's a long way from the point I was trying to make, which was
basically that we'd still be working on DRUMS if we hadn't given up
trying to resolve certain issues. Somehow mail continues to work even
without those issues being resolved.
If you don't think that complicated decisions should delay publication
of simple decisions, you'll have to accept the idea of multiple specs,
each spec labelled as being only part of the picture.
FWIW, I do think that good specifications often have to resolve complicated
decisions, and that it's usually better to spend the time required to do so
than to gloss over the lack of consensus with silence or ambiguity. At the
same time, if you don't eventually get a significant reduction in ambiguity
for your trouble, and you can make the protocol work well despite the
ambiguity, it's worth asking whether the effort was worthwhile.
DRUMS seemed like a good idea at the time, but in hindsight I'm not at all
sure that 282[12] resulted in more uniformity or less confusion for
implementors. Maybe it's too soon to tell. Or maybe the process exposed
ambiguities that had always been there. But I think that (despite efforts
to constrain the group's activities with its charter) DRUMS served as an
invitation to those who wanted to change things for no good reason, or (more
likely) out of noble intentions but for dubious potential benefit.