This is an old revision of the document!
The HTML document must preserve all semantic information that is in the canonical XML document. One use case is that preformatted text that has different tags in the XML will also be differentiable in the HTML, making it trivial to extract all of the (for example) ABNF in an RFC with a simple program. Another use case is that someone who wants to write programs that will extract information from an RFC can do so equally well with the XML and HTML, and can choose the tool that uses one or the other format for input.
A non-requirement is that the HTML document have any non-semantic information such as comments and processor instructions. (This non-requirement should be removed if they are not allowed the XML.)
The HTML document must come with a default internal set of CSS formatting. This will allow for a mostly-consistent display of RFCs across browsers. It will also allow for the HTML file to be moved over different transports (such as mail) and have the result look the same.
The HTML must display well in at least one text-based browser.
The HTML document must allow easy local override of the default CSS formatting. This will allow users who have a different visual style that they prefer to make RFCs display with that style without having to alter the contents of the HTML document. This might also be valuable for allowing people with specific accessibility needs to have custom CSS.
No HTML tags in the document may have style information. All style information must be done through “class” and “id” attributes, with the style for those represented in the CSS alone.
The HTML must make it easy to separate chunks into separate files. This will make creating EPUB documents easier in the future.
The HTML document must be valid HTML. The RFC Editor will need to use a validating tool before publishing the HTML. This is not important for viewing with browsers, but is important for programs that will use the HTML format as input for processing.