henry(_at_)zoo(_dot_)toronto(_dot_)edu writes:
A procedural thought on this: it Sure Would Be Nice if some of the people
who have been exposed to things like this sat down and wrote a few
Informational RFCs *documenting* some of this folklore. One of the most
infuriating things about implementing some of the Internet protocols is
running across these bits of important information that aren't written
down *anywhere*, apparently on the assumption that anyone who needs to
know them already does. Not so.
I must say that I do agree with this. I think that the concept behind
RFCs is truly remarkable and revolutionary; I know of no other field that
has decided fairly early in it's development to document protocols which
have been written cooperatively by people within the field. But this
takes care of only half the battle, the theory is there but not the
implementation; and as we all know, in computer science, theory without
an implementation of it does no one any good.
What we are beginning to see (and I think that the next 3-5 years
will show further evidence of this) is that a new "wave" of people are
joining "the game", and these people will be totally ignorant of the
so called "folklore" regarding implementation issues regarding the
various RFCs.
As an example, let us look at the example that Mark Crispin had made
reference to in one of the earlier memos in this thread. As most (if not
all) of you know, MIME allows for multi-media extensions within e-mail.
One of the "problems" with it is that implementors are having a hard time
dealing with dots within tspecials.
At this point I would imagine that some of you are saying "Yeah, so what
about that?", while others are saying "What in the world is that guy
talking about, and why should I care?". It is the second group of people
who illustrate my point.
If you were to go to MIME you will find no references made to the
implementation issues regarding the inclusion of dots within tspecials.
Currently the only people who know about the discrepancy are ones who are
following the 822 list. Who is going to know about this "problem" 3 years
from now? What is going to happen when 3 years from now someone decides
to write his own package based on MIME?
If permitted I would like to state that I do not mean to be "harsh" on
MIME. I happen to like it. I am using it as an example because I feel that
we will see MIME become very popular in the future, which in turn helps
illustrate two points:
1) That we have RFCs around which people will want to implement, not
just today or tomorrow, but in years to come, and we are not leaving
them enough information to do so effectively.
2) That there does exist a *real need* to keep track of this information.
I think that there should be some procedure which states that the
author(s) of a given RFC should also submit a follow-up document an X
amount of time after the RFC has been published. What is the time
frame on X? I don't know, 3 months, 6 months? In it the document should
contain whatever information the author(s) feel is useful and needed in
order to implement their protocol.
The question is, how would you see to it that this follow-up document
is ever written? For one thing we can "unpublish" their RFC; but this is
too extreme of a measure :-). We could hope that everyone starts
submitting the follow-up documents, starting a trend that will one day be
considered taboo if violeted.
--------------------------------------------------------------------------------
Neophytos Iacovou
University of Minnesota email:
iacovou(_at_)cs(_dot_)umn(_dot_)edu
Computer Science Department ...!rutgers!umn-cs!iacovou