This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
design:start [2015/10/13 08:36] rsewikiadmin added reading list; removed discussion topics |
design:start [2019/05/07 09:31] rsewikiadmin General update |
||
---|---|---|---|
Line 15: | Line 15: | ||
By allowing for multiple Publication formats, readers can choose a format that works best for their circumstances. | By allowing for multiple Publication formats, readers can choose a format that works best for their circumstances. | ||
- | Over the past two years, the [[design: | + | The [[design: |
+ | |||
+ | ==== Project Implementation ==== | ||
+ | * [[https:// | ||
+ | * [[design: | ||
==== Reading list ==== | ==== Reading list ==== | ||
Line 23: | Line 27: | ||
1. The big picture | 1. The big picture | ||
- | * Flanagan, H., "RFC Format Framework", Work in Progress, [[http://datatracker.ietf.org/doc/draft-flanagan-rfc-framework/ | + | |
+ | [RFC7990] | ||
2. The underlying vocabulary | 2. The underlying vocabulary | ||
- | * Hoffman, P., "The ' | + | |
+ | [RFC7991] | ||
3. The outputs | 3. The outputs | ||
- | * Hildebrand, J. and P. Hoffman, | + | |
- | | + | [RFC7992] |
- | | + | |
- | | + | [RFC7993] Flanagan, H. “Cascading Style Sheets (CSS) Requirements for RFCs”, RFC 7993, DOI 10.17487/RFC7993, December 2016, [[http:// |
+ | |||
+ | [RFC7994] | ||
+ | |||
+ | [RFC7995] | ||
+ | |||
+ | [RFC7996] | ||
4. Generalized requirements | 4. Generalized requirements | ||
- | * Flanagan, H., "The Use of Non-ASCII Characters in RFCs", Work in Progress, [[https:// | ||
- | 5. Workflow and tools (note that the examples draft will not become an RFC, but is necessary for the project) | + | [RFC7997] Flanagan, H., “The Use of Non-ASCII Characters in RFCs”, RFC 7997, DOI 10.17487/RFC7997, December 2016, [[http://www.rfc-editor.org/info/rfc7997]]. |
- | * Hildebrand, J. and P. Hoffman, "RFC v3 Prep Tool Description" | + | |
- | * Hoffman, P. and T. Hansen, " | + | |
- | 6. The Statements of Work | + | 5. Workflow and tools |
- | * http:// | + | |
+ | [RFC7998] Hildebrand, J. and P. Hoffman, “‘xml2rfc’ Version 3 Preparation Tool Description”, | ||
- | ==== Format Requirements pulled from RFC 6949 ==== | + | Hoffman, P. and T. Hansen, “Examples of the ‘XML2RFC’ Version 2 and 3 Vocabularies”, |
- | 1. The content of an RFC must not change, regardless of format, | + | |
- | | + | ==== Format Requirements from RFC 6949 ==== |
+ | |||
+ | - The content of an RFC must not change, regardless of format, once published. | ||
+ | - The Canonical format must be persistent and reliable across a large variety of devices, operating systems, and editing tools for the indefinite future. | ||
+ | - While several Publication formats must be allowed, in order to continue support for the most basic reading and search tools and to provide continuity for the Series, at least one Publication format must be plain text. | ||
+ | - The boilerplate and overall structure of the RFC must be in accordance with current RFC and Style Guide requirements (see RFC 5741). | ||
+ | - The documents must be made accessible to people with visual disabilities through such means as including alternative text for images and limiting the use of color. See the W3C's accessibility documents | ||
+ | - The official language of the RFC Series is English. | ||
+ | - The Submission and Publication formats need to permit extending the set of metadata tags, for the addition of labeled metadata. | ||
+ | - Graphics may include ASCII art and a more complex form to be defined, such as SVG line art [SVG]. | ||
+ | - The Canonical format must be renderable into self-contained Publication formats in order to be easily downloaded and read offline. | ||
+ | - Fixed-width fonts and non-reflowable text are required for ASCII-art sections, source code examples, and other places where strict alignment is required. | ||
+ | - At least one Publication format must support readable print to standard paper sizes. | ||
+ | - The Canonical format should be structured to enable easy program identification and parsing of code or specifications, | ||
| | ||
- | 2. The Canonical format must be persistent and reliable across a | + | |
- | large variety of devices, operating systems, and editing tools | + | |
- | for the indefinite future. | + | |
- | readable and editable across commonly used devices, operating | + | |
- | systems, and platforms for the foreseeable future. | + | |
- | + | ||
- | 3. While several Publication formats must be allowed, in order to | + | |
- | continue support for the most basic reading and search tools | + | |
- | and to provide continuity for the Series, at least one | + | |
- | Publication format must be plain text. | + | |
- | + | ||
- | 4. The boilerplate and overall structure of the RFC must be in | + | |
- | accordance with current RFC and Style Guide requirements (see | + | |
- | [RFC5741]). | + | |
- | + | ||
- | 5. The documents must be made accessible to people with visual | + | |
- | disabilities through such means as including alternative text | + | |
- | for images and limiting the use of color. | + | |
- | accessibility documents [WCAG20] and the United Nations | + | |
- | " | + | |
- | [UN2006] for guidance. | + | |
- | desirable but focus on the creation of Internet-Drafts, | + | |
- | topic outside the scope of the RFC Editor. | + | |
- | + | ||
- | 6. The official language of the RFC Series is English. | + | |
- | required for all text that must be read to understand or | + | |
- | implement the technology described in the RFC. Use of non- | + | |
- | ASCII characters, expressed in a standard Unicode Encoding | + | |
- | Form (such as UTF-8), must receive explicit approval from the | + | |
- | document stream manager and will be allowed after the rules | + | |
- | for the common use cases are defined in the Style Guide. | + | |
- | + | ||
- | 7. The Submission and Publication formats need to permit | + | |
- | extending the set of metadata tags, for the addition of | + | |
- | labeled metadata. | + | |
- | created to make use of metadata tags consistent for the life | + | |
- | of the Series. | + | |
- | + | ||
- | 8. Graphics may include ASCII art and a more complex form to be | + | |
- | defined, such as SVG line art [SVG]. | + | |
- | not be accepted. | + | |
- | black-and-white to allow for monochrome displays, black-and- | + | |
- | white printing, and support for visual disabilities. | + | |
- | + | ||
- | 9. The Canonical format must be renderable into self-contained | + | |
- | Publication formats in order to be easily downloaded and read | + | |
- | offline. | + | |
- | + | ||
- | 10. Fixed-width fonts and non-reflowable text are required for | + | |
- | ASCII-art sections, source code examples, and other places | + | |
- | where strict alignment is required. | + | |
- | + | ||
- | 11. At least one Publication format must support readable print to | + | |
- | standard paper sizes. | + | |
- | + | ||
- | 12. The Canonical format should be structured to enable easy | + | |
- | program identification and parsing of code or specifications, | + | |
- | such as MIB modules and ABNF. | + |