[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Single vs Multiple documents
Just a quick comment before going offnet for a few days in the local
mountains;-). This is a critical issue.
It is the province of the Host Requirements document to assert how the
various RFCs combine to form the full standard for a given service or
protocol, or application. (Why the Host Requirements RFC is not
updated more than once per year is a question for IESG to address.)
Anyway, it is my reading that the ietf-smtp WG was specifically
instructed to not rework all the existing stuff in RFC821/1123, and
others, but to work only on extensions for improvement of RFC821/1123.
The WG ID was thus just another increment in any case, that has to be
combined with other RFCs. The fact that combining is not always easy
does not mean that this specific WG should break its pick to solve
this problem all by itself, by only producing a single document.
(This "How to Combine RFCs into SuperRFCs" is a job for SuperIESG;-).
I believe that the case in hand is an example of how hard it is to
produce good standards in big chunks. The predominant danger is that
of including bathtubs and kitchen sinks, and other sundry stuff that
is not really good, in part through political trading of acceptance of
this or that or the other thing in order to get the whole thing
through the process. It also creates stresses which lead to including
half baked technologies because of the need to get it on the currently
departing train, or wait a significant period for the next train.
By breaking the task into separate documents, we break the back of
these bad influences.
By breaking it up into separately adopted parts, each one must stand
on its own merit, and withstand all challenges on its own merit.
This is a good thing!
Best...\Stef