On 29-mrt-04, at 6:16, Donald Eastlake 3rd wrote:
To me it seems that the IETF can't make up its mind: are RFCs just
drafts that don't expire, or are they hugely important documents that
must be absolutely perfect before they are published?
Why does it have to be one of your two alternatives?
Above I'm not describing what should be, or even what is, but what it
seems like to me.
RFC's are like books. No book is perfect. Almost all books undergo
significant review, copy editing, etc,, before publication.
The book analogy can work up to a point, but for certain types of
documents it makes very little sense. A book can't be changed after it
has been printed, so it reflects knowledge at a certain point in time
by its nature (and also often times by design).
However, true engineering documents change from time to time, no matter
how hard the push is to get it right the first time. There is no
copyediting like trying to implement a protocol...
It would of course help if RFC authors would stick to the point of
their RFC rather than discuss all the potential ways in which their
protocol could be useful. Draft authors are even worse, 75% of most
drafts is spent justifying the draft.
The problem is version control. We're engineers. That means we are,
more so than mere mortals, doomed never to get anything right the
first
time out. However, the RFC publishing model doesn't really allow for
incremental changes: you have to write a completely new RFC, which
then
gets a new number that has no relation to the original RFC.
While it is normally the case that an RFC is "revised" by the
publication of a new RFC which obsoletes the old, this is not
necessarily the only way to do it. If there are a significant volume of
changes but still only a small amount compated to the size of the
original RFC, it is possible to publish and updating RFC, at least for
Informational RFCs. See RFC 2801 and 3504. There is also an errata
mechanism maintained by the RFC Editor.
Then explain to me the existence of RFC 1918 with regards to RFC 1597.
What we need is a way to add information to RFCs whithout the need to
rewrite the original RFC or make the new information a full-blown RFC
of its own.
There is clearly no way to do what you want with printed books, which
are what RFCs are modelled after.
And email is modeled after letter writing, so what's up with this
quoting thing that we're doing here???
To get the effect you want, people
would need to go to a web resource or the like. But if they are willing
to do that, then they can almost as eaily find out about errata and
whether the RFC they are looking for has been obsoleted.
The alternative is that they use a printout of an RFC. Anyone willing
to create such a printout can just as easily print the whole family of
documents that make up a standard.
I also notice that you ignore all the problems of fluid specifications
that constantly change on line so that no two people/implementers can
be
sure they are working from the same spec unless they agreed on a time
stamp, etc.
Oh yes, the current situation where people implement drafts, RFCs
continue to have small but potentially lethal errors in them and new
replacement RFCs are published in a way that is impossible to determine
from looking at the RFC they're replacing is so much better.
I suggest we form a task force of people who all implemented at least
three RFCs times as many RFCs as they authored and let them tell us
what's right and what's wrong here.