> From: Lyndon Nerenberg <lyndon@orthanc.ab.ca> > > Consider the problem of answering the question "Is the RFC on my screen > > or printer the same as your document? Was either version edited by > > someone or something?" > > > Then no matter what DTD verifiers the RFC Editor runs, we will have > > people saying "RFC 98765432 says blah de blah right here on this > > sheet of paper" because they printed it with a User Friendly XML > > printer that fixes spelling errors and deletes bits that infringe on > > Microsoft's business plans and the RIAA's intellectual property. > > Vernon, if you honestly believe this to be true, then the only format you > could possibly advocate is printed hardcopy locked up in a vault. Yes I honestly belive this to be true. The only format I'm really happy with for normative RFCs is paper. (Well, I'd prefer etchings on stainless steel.) However, .txt is close enough because .txt's do get converted to write-once paper that anyone can compare with any other purported copy. > Even ASCII documents are subject to bit rot, be it on media, during > transmission, while in memory, etc. Yes, everything including paper rots. However, XML is not only designed to be malleable, but most if not all of its proponents in this cycle of this old argument have touted that characteristic as if it were desirable feature instead of terrible bug. With XML (as with HTML), you must assume that someone or something has edited your copy differently than anyone else's copy. As I said, the presentation or form of a document matters. Changing pagination often changes what people understand of a document. The purposes of RFCs do not include being easy to edit. Everything including the convenience of people with ambitions to produce RFC 987654321.ter must be subservient to the real purposes of RFCs. Vernon Schryver vjs@rhyolite.com