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. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
