Subject: Direction of the RFC Format Development effort

From: RFC Series Editor <[email-masked]>
Date: Thu, 02 May 2013 16:49:59 -0700

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
_______________