From: Michael Thomas <mat(_at_)cisco(_dot_)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(_at_)rhyolite(_dot_)com