This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
formatreq [2012/05/10 10:01] rsewikiadmin |
formatreq [2013/05/31 09:25] (current) rsewikiadmin |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | Draft-Edit, Review (what authors, ADs, and other interested parties worry about when writing and reviewing an I-D) | + | ====== RFC 6949 ====== |
- | * Need to broader character encoding to respect author names | + | Note that the requirements have been gathered |
- | * Need to be able to update documents easily | + | |
- | * Need to be able to include graphics/images | + | |
- | * 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 | + | |
- | * 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' | + | |
- | * Want to be able to include equations | + | |
- | * Want a more flexible line length | + | |
- | * Want to be able to tag ownership/ | + | |
+ | ---- | ||
+ | The RFC Series has been in existence for over 40 years. | ||
- | RFC-Edit (additional requirements from 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 " | ||
+ | Canonical source and display versions of an RFC exists for several reasons: | ||
+ | * to provide verification of the content of a RFC in case inconsistencies are created when a document is converted to another format or mirrored to another location | ||
+ | * to verify the final content of a document in cases of legal dispute | ||
+ | * to aid in the conversion of the RFC in to formats requested by the community | ||
- | RFC-Archive (what the RFC Editor | + | The very basic format of RFC source and display documents have two persistent characteristics that are considered by the RFC Series |
- | * Need format | + | * persistence (tools |
- | * Need one format | + | * convertibility (the plain text version |
- | * 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 | + | |
- | * Need a long-lived file format with an open specification, | + | |
+ | That said, the very simple nature of the current display format in particular introduces a variety of limitations, | ||
+ | * ASCII art is considered by some to be a major limitation in expressing visually-oriented information | ||
+ | * the internationalization of the authorship and the Internet is introducing characters not possible in plain ASCII | ||
+ | * the more common forms of display (web pages, smaller devices) make the limitations of page and line length a hindrance to the reading of an RFC | ||
- | End consumption (what consumers | + | |
- | | + | So, the community and the RFC Editor have decided to review the canonical format of the RFC series and discuss whether it needs to change |
- | * 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 | + | ---- |
- | | + | === Fundamental requirement === |
- | * Want the RFC to be suitable for small screens/ | + | * Any new format MUST continue the level of persistence found in the existing format |
- | * Want to have neat printing (intelligent pagination) | + | * While the canonical source format MUST be easily converted in to a variety of other formats, a single canonical display format must exist to satisfy the requirements of legal and content disputes |
- | * 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) | + | === Draft-Edit, Review (what authors, ADs, and other interested parties |
+ | |||
+ | //Note that requiring change to I-D format is outside the purview of the RFC Series Editor. | ||
+ | ^ Feature | ||
+ | | Need broader character encoding for author names | No | Yes, with limitations | ||
+ | | Need to be able to update documents easily and see how they might look when published | ||
+ | | Need to be able to include non-ASCII | ||
+ | | Need to be able to create new documents by hacking away at older ones | Yes | Yes | | | ||
+ | | Need be able to diff versions of a draft | Yes | Yes | | | ||
+ | | 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 | ||
+ | | 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' | ||
+ | | Want to be able to include equations | Limited | ||
+ | | Want a more flexible line length | ||
+ | | Want to be able to tag ownership/ | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | === RFC-Edit === | ||
+ | // | ||
+ | ^ Feature | ||
+ | | 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) | No | Yes | RFC Ed currently accepts XML and nroff and does all the necessary conversions as part of the editorial process | | ||
+ | | Want a publicly available " | ||
+ | |||
+ | |||
+ | |||
+ | === RFC-Archive === | ||
+ | //what the RFC Editor worries about when publishing an RFC// | ||
+ | ^ Feature | ||
+ | | Need source format to be easily rendered in to other, potentially undefined formats (.txt, .html, other) | ||
+ | | Need one source and display 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' | ||
+ | | Need a long-lived file format with an open specification, | ||
+ | |||
+ | |||
+ | |||
+ | === End consumption === | ||
+ | ^ Feature | ||
+ | | Need to be able to see non-ASCII graphics/ | ||
+ | | Need to be able to search document | ||
+ | | Need to be able to create new documents by hacking away at older ones | Yes | Yes | | | ||
+ | | Want intelligent html-style linking within references | ||
+ | | Want the RFC to be suitable for small screens/ | ||
+ | | 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) | ||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
+ | |||
+ | 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. |