> From: Michael Thomas <mat@cisco.com> > ... > For (2), somebody has graciously pointed out that > draft/rfc->html mungers already exist. > > So as a more modest proposal: > > On the drafts and RFC's repository have two new > options: > > 1) Source in whatever format it came in > 2) The .txt sent through the .html grinder As stated that would be a disaster of inviting not just the camel's nose but the whole herd into the tent. For I-Ds, redistributing whatever the authors submitted is mostly harmless and potentially valuable to working groups. It's also potentially dangerous if a working group tolerates attempts to "steal" documents, but let's put that worry asside. The catastrophy would be keeping anything except .txt for RFCs anywhere remotely official. The obvious issue of in any sense publishing more than .txt is how you handle unavoidable conflicts between .txt and the format of the same document. Just repeating "The .txt is normative" is not enough. Unless you are merely a legalistic stadnrads lawyer, you care about more fostering interoperability than avoiding liabilities. That requires preventing misunderstandings instead of telling the mislead "you should have read the .txt document." There will be differences between the two formats. A major point of non-.txt is to have diferences in presentation. Presentation matters and affects the perceived semantics. We have experimental proof of this in the PostScript RFCs, and that despite the fact that the presentation of PostScript is fixed compared to XML. This week we've heard complaints that pagination and line-breaking in the .txt RFCs is rigid, as if that were a bug instead of a vital feature. 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 there is the IETF political problem. As is standard in these recurring discussions, there have already been plenty of claims that .txt is not powerful enough for searching, linking, pictures, editing, and reformating. As soon as there are XML RFCs there will be irresistable pressures to make them normative. I think PostScript RFCs are not normative only because Jon Postel autocratically said "No" to the similar pressures then. The pressures would be stronger now, and we don't have Jon Postel to order the tide to retreat. 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 Schryver vjs@rhyolite.com