This is an old revision of the document!
This list is a union of suggestions made on the rfc-interest list, in conversations with the RFC Production Center, and RFC Series Advisory Group, with my take on prioritization based on list input and my professional input. I would like to see the various I-D on the topic of RFC Format to take in to account the “needed” items, and if some/any/many the “wanted” items can be solved for, great. I do not expect the solution(s) presented any one I-D to be able to meet every item on this list.
Draft-Edit, Review (what authors, ADs, and other interested parties worry about when writing and reviewing an I-D)
Note that requiring change to I-D format is outside the purview of the RFC Series Editor. Information collected that suggests changes to I-D format will be submitted to the IESG.
- Need to broader character encoding to respect author names
- questionable consensus; would note that at least one TLD registrar (AFNIC) is beginning to register domain names with diacritical marks and these will eventually show up in references and author's addresses
- Need to be able to update documents easily and see how they might look when published
- Need to be able to include graphics/images
- questionable consensus
- Need to be able to create new documents by hacking away at older ones
- Need be able to diff versions of a draft
- Need format to be easily rendered in to other, potentially undefined formats (.txt, .html, other)
- Need to be able to search document and document repositories with tools such as *grep
- Want broader character encoding for body of document
- questionable consensus
- Want the ability to denote protocol examples using the character sets those examples support
- Want the ability to semantically tag some document info, at least authors' names and references
- Want to be able to include equations
- Want a more flexible line length
- possibly should be rephrased to state want to make the new format display reasonably well on a variety of screen sizes
- Want to be able to tag ownership/source of comments
RFC-Edit
additional requirements to the Draft Edit/Review list as provided by the RFC editors
- Need source file to be editable by both authors and RFC editors
- Want a single, discrete source file for a draft (not multiple files and a make file)
- Want a publicly available “official” conversion tool (same source file producing the same output between I-D submission and RFC editing step)
RFC-Archive
what the RFC Editor worries about when publishing an RFC
- Need format to be easily rendered in to other, potentially undefined formats (.txt, .html, other)
- Need one format to be the authoritative version, suitable for legal records
- Need to be able to create new documents by hacking away at older ones
- Need backward compatibility to recreate documents originally created in an older version of the output tools (backward compatibility issue doesn't apply to docs published prior to the format change)
- Need a long-lived file format with an open specification, i.e., such that the community can continue to support it even if commercial support disappears
End consumption
- Need to be able to see graphics/images
- Need to be able to search document and document repositories with tools such as *grep
- Need to be able to create new documents by hacking away at older ones
- Want to be able to link sections and jump ahead in the document
- Want intelligent html-style linking within references
- Want the RFC to be suitable for small screens/mobile devices
- Want to have neat printing (intelligent pagination)
- Want to be able to view equations
- Want a more flexible line length
- Want a single document to view (should not have to jump between two documents for complete information)
