I am having difficulty following this discussion. I agree with the requirements analysis in draft-ash-alt-formats, it's the conclusion I have a hard time following. The idea of using PDF as a normative form appears broken to me from every perspective except producing a document that looks professional. * The format is proprietary, only Adobe can change it * The format is patent encumbered * The format is dedicated to presentation on paper * Tools to support the format do not support semantic markup There is an obvious alternative, make use of XHTML, an open standard that is expressly designed to be non-proprietary and is so widely used that there is zero probability that the ability to read the documents will ever be lost for as long as it is possible to read the media on which they are stored. To repeat: THERE IS ZERO PROBAILITY THAT MANKIND WILL LOSE THE ABILITY TO READ HTML There are billions upon billions of documents marked up in HTML. We managed to decipher the rosetta stone we can decipher HTML. The notion that this will ever change is silly. If we loose the ability to read XHTML we will have lost the ability to read the bits on the hard drive as well. The one problem that XHTML does present is that support for compound documents with embedded images are not well handled. This is easily solved through the use of MHTML, MIME encapsulation of HTML documents and attachments. Again the format is widely implemented and easy to reverse engineer. The problem people have with moving to XHTML is not that it is a moving target. It is the idea of change itself. A standards based, future proof, non proprietary solution to this problem is to adopt: * Use of MHTML as the archive packaging. * Use of XHTML 1.0 as the document encoding. * Use of a standard IETF defined style sheet. * Use of PNG encoding for all images. These restrictions may all be enforced using easily constructed verification tools. The W3C already has these and would be more than happy to provide them to the IETF. Writing 100% compatible HTML is a bit of a pain but nowhere near as much of a pain as dealing with RFC TXT format which is designed with the built in assumption of north american paper sizes amongst others. There is already one standards body that has adopted the HTML approach. The IETF is not a standards body for document formats, why not rely on one that is? Meanwhile regardless of which spec the IETF deems to be normative the engineers will continue to code from the version of the specification that is easiest to read. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf