This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
formatreq [2012/05/29 09:06] rsewikiadmin |
formatreq [2013/05/31 09:25] (current) rsewikiadmin |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | 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. | + | ====== RFC 6949 ====== |
+ | Note that the requirements have been gathered and published as [[http:// | ||
+ | |||
+ | ---- | ||
+ | |||
+ | The RFC Series has been in existence for over 40 years. | ||
+ | |||
+ | |||
+ | Canonical source and display versions of an RFC exists for several reasons: | ||
+ | * to provide verification of the content | ||
+ | * to verify the final content of a document | ||
+ | * to aid in the conversion of the RFC in to formats requested by the community | ||
+ | |||
+ | |||
+ | The very basic format of RFC source | ||
+ | * persistence (tools to read, edit, and print the documents remain easily accessible to everyone) | ||
+ | * convertibility | ||
+ | |||
+ | |||
+ | 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 | ||
+ | |||
+ | |||
+ | 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 | ||
+ | |||
+ | |||
+ | ---- | ||
+ | === Fundamental requirement === | ||
+ | * Any new format MUST continue the level of persistence found in the existing format | ||
+ | * 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 | ||
Line 5: | Line 36: | ||
//Note that requiring change to I-D format is outside the purview of the RFC Series Editor. | //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 graphics/ | ||
+ | | 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 | Yes | Yes | | | ||
+ | | 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/ | ||
- | * Need to broader character encoding | ||
- | * 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' | ||
- | * Need to be able to update documents easily and see how they might look when published | ||
- | * Need to be able to include graphics/ | ||
- | * 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' | ||
- | * 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/ | ||
Line 28: | Line 56: | ||
=== RFC-Edit === | === RFC-Edit === | ||
// | // | ||
- | * Need source file to be editable by both authors and RFC editors | + | ^ Feature |
- | * Want a single, discrete source file for a draft (not multiple files and a make file) | + | | Need source file to be editable by both authors and RFC editors |
- | * Want a publicly available " | + | | 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 " | ||
Line 36: | Line 65: | ||
=== RFC-Archive === | === RFC-Archive === | ||
//what the RFC Editor worries about when publishing an RFC// | //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) | + | ^ Feature |
- | * Need one format to be the authoritative version, suitable for legal records | + | | Need source |
- | * Need to be able to create new documents by hacking away at older ones | + | | Need one source and display |
- | * Need backward compatibility to recreate documents originally created in an older version of the output tools (backward compatibility issue doesn' | + | | Need to be able to create new documents by hacking away at older ones |
- | * Need a long-lived file format with an open specification, | + | | 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 === | === End consumption === | ||
- | * Need to be able to see graphics/ | + | ^ Feature |
- | * Need to be able to search document and document repositories with tools such as *grep | + | | Need to be able to see non-ASCII |
- | * Need to be able to create new documents by hacking away at older ones | + | | Need to be able to search document and document repositories with tools such as *grep |
- | * Want to be able to link sections and jump ahead in the document | + | | Need to be able to create new documents by hacking away at older ones |
- | | + | | Want intelligent html-style linking within references |
- | * Want the RFC to be suitable for small screens/ | + | | Want the RFC to be suitable for small screens/ |
- | * Want to have neat printing (intelligent pagination) | + | | Want to have neat printing (intelligent pagination) |
- | * Want to be able to view equations | + | | Want to be able to view equations |
- | * Want a more flexible line length | + | | Want a more flexible line length |
- | * Want a single document to view (should not have to jump between two documents for complete information) | + | | 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. |