From: Lyndon Nerenberg <lyndon(_at_)orthanc(_dot_)ab(_dot_)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(_at_)rhyolite(_dot_)com