Hello, During IETF 86, the IAB formally approved the RFC Format Requirements and Future Development document for publication. This draft outlines the requirements gathered from the communities of interest regarding the Canonical format for the RFC Series. With those requirements in hand, the next step is to explore how those requirements might be implemented and verify what is possible and reasonable for the Series going forward. The direction we will be exploring is one where the Canonical format - the format that is authoritative for content of an RFC - is XML using the xml2rfc DTD. From that format, the RFC Editor will experiment with rendering four Publication formats: plain text, HTML, PDF, and EPUB. The goal is to run through this experiment over the next year and determine if this is in fact the correct direction for the Series or if some other option should be explored as potentially more viable. We are focusing on the xml2rfc DTD and associated rendering tool as something most likely to meet the requirements as defined in a reasonable time frame and budget because xml2rfc is: * well-known by many in the authoring community as well as the RFC Editor; * has a start on meeting most of the requirements already; * is based on a solid mark-up language that is expected to exist for the foreseeable future. In order for xml2rfc meet the community's requirements, changes will need to be made to make the DTD and the xml2rfc code. For example: * broader error checking and layout control will be required; * tools will be needed for editors to be able to archive a final XML file and associated image files; * a process or code change will be required to roll out DTD changes to those who run the tool locally; * new code for proper rendering of new HTML, PDF, and EPUB output will be required. With the recent xml2rfc version 2 changes, the code itself should be much more extensible and easier for a team of programmers to work with. The purpose of declaring this an exploration rather than an absolute answer at this time is so we have the opportunity to answers several key implementation details that were not part of the requirements, such as: * What version of HTML will be produced? * How divergent will we allow the HTML version to be? Can it have a frame at the top that includes file metadata such as status and links to errata when other Publication formats cannot? * How will multiple versions be displayed on the rfc-editor website? * What processes need to change to allow the RFC Production Center and RFC authors an efficient way to review multiple publication outputs? * What changes will be required in the Style Guide to reflect changes to the Canonical and Publication formats? * Given the difficulty some authors have expressed in using xml2rfc, is it possible to add new elements to allow for additional Publication format while still having a commonly usable tool? More information regarding the upcoming effort, including anticipated questions from the community, can be found here: http://www.rfc-editor.org/rse/FormatFAQ.html Discussion regarding the work effort will be held on the rfc-interest mailing list. Heather Flanagan RFC Series Editor _______________
