[Mailman-Users] A rant on parsing RFCs

Stephen J. Turnbull turnbull.stephen.fw at u.tsukuba.ac.jp
Tue Oct 24 04:14:07 EDT 2017


Ruben Safir writes:

 > RFCs are a record of a process.

Partially true.  The process almost invariably leaves its trace in the
text, and (as in any committee work) many compromises are inexplicable
without reference to the process.  But the text of an RFC is a
specification, not a narrative.

 > Unless you were directly involved that that process, RFCs are about
 > as useless as garbage.

False.  True, RFCs are difficult for most who haven't participated in
the process to read and understand correctly.  But I can say from
experience that it's quite possible to understand them without
participating in the drafting process.

What's needed to understand RFCs is first, a formal mindset, and
second, firm (indeed, I might say "desperate") grasp of the principle
that these are *wire protocols*, and that therefore behavior of
systems at either end of the channel is a pretty poor foundation for
understanding them.  Endpoint behaviors can be perfectly conformant no
matter how they look to users, as far as the RFCs are concerned.  RFCs
are only concerned with defining and serializing data structures at
the channel's transmitting end, conveying the data to the receiving
end, and reconstructing the data there.

 > They are not only without clear explanation,

You're looking in the wrong place if you look in standards-track RFCs
for explanation useful to non-specialists.  That's why Grant quoted a
BCP, and I, an informational RFC.

 > but they are often just plain wrong and contradictory.

In other words, RFCs are a human endeavor. :-)

 > People who suggest reading them need to have their meds adjusted.

Nobody suggested reading them.  People who already have experience
reading them did read them because reading RFCs is necessary to
understanding *how* any Internet function is intended to work[1],
quoted them, and complimented each other for doing so.

Anybody who doesn't want to read RFCs is still welcome to comment, but
it's most profitable for them to stick to what they *want* to happen.
They'll have to rely on those of us who know what the RFCs say for
judgments of feasibility and cost, and for design, in implementing
those requested behaviors.

Footnotes: 
[1]  Alternative behavior is permitted, but is unlikely to work as
desired without explicit private agreement.  Taking existing RFCs as a
baseline and agreeing on slightly variant protocols is often a very
productive way to implement new Internet features, as well as private
protocols.



More information about the Mailman-Users mailing list