Michael, Please remember the following minor issues: (1) xml2rfc may be widely used, but it is not a requirement or a standard. It actually has no formal status in the IETF. Even the informational RFC that describes it is long out of date. All of that is reasonable for the way it is being used today, but is not consistent with your proposal. (2) People do prepare I-Ds and input to the RFC Editor in other ways. Plain ASCII text prepared with an editor, nroff, and, using other sets of tools, MS Word are all in use and there may be others that I don't know about. The specification in the image file document are compatible with all of these as well as with xml2rfc (plus or minus some changes or post-processing). (3) While one can debate it at length --and we, no doubt, will have to do that-- the other graphic and specification mechanisms you cite do not have either the track record or external acceptance to make a reasonable guarantee of long-term stability. john --On Tuesday, 26 August, 2008 17:30 +0100 michael.dillon@xxxxxx wrote: >> On first reading this seems to be an interesting way to go. > > It seems to be heading in the right general direction, but > I wonder why it does not concentrate on specifying inputs > rather than outputs. Given that XML is now widely used as the > input format for RFCs, it seems worthwhile to review the bits > of XML-related stuff that are mature enough for use for > writers. > > For instance, SVG for diagrams and PNG for images, standard > CSS for tables. > > Of course, there has to be a defined standard reporitory output > for "publishing" the RFCs, but that already seems to be PS/PDF. > If the IETF defines a standard input format, and the XML2RFC > toolset is updated to support that toolset and output PS/PDF > format for the repository, then that takes care of the format > issue. Then there is only one file, not two or three. And the > toolset could feasibly generate a text file plus PS/PDF images > only format, as an alternate output if that is desired. Or SWF > output files, or TGZ file with a folder containing HTML and > separate files for each SVG diagram or PNG image. No need to > choose, just prioritise. > > Stylistic issues are quite separate, although they should > probably also be specified up front if it keeps things more > orderly. I'd suggest avoiding numbering images/diagrams in > favor of naming them. E.g. see diagram former-state-machine or > refer to image original-napkin-notes. > > --Michael Dillon > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf