User Tools

Site Tools


design:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
design:start [2013/10/17 11:20]
rsewikiadmin [Other information]
design:start [2019/05/07 09:31] (current)
rsewikiadmin General update
Line 15: Line 15:
 By allowing for multiple Publication formats, readers can choose a format that works best for their circumstances.  The Text and PDF will be extremely basic and support the widest array of tools.  The HTML will allow more features and be readable by modern browsers. By allowing for multiple Publication formats, readers can choose a format that works best for their circumstances.  The Text and PDF will be extremely basic and support the widest array of tools.  The HTML will allow more features and be readable by modern browsers.
  
-Over the past few months, the [[design:design-team|RFC Format Design Team]], formed in Berlin, has discussed the more detailed requirements for the XML Canonical format as well as the requirements of the different Publication formats and their associated character encoding.  The results of that discussion, including documentation on items discussed but decided against as requirements, are documented in the pages below.+The [[design:design-team|RFC Format Design Team]] (July 2013 - December 2016) discussed the more detailed requirements for the XML Canonical format as well as the requirements of the different Publication formats and their associated character encoding.  The results of that discussion, including documentation on items discussed but decided against as requirements, are documented in this wiki.
  
-==== Requirements ==== +==== Project Implementation ==== 
-  * [[design:utf8-requirements|Requirements for UTF-8 and Unicode]] +  * [[https://trac.tools.ietf.org/tools/ietfdb/wiki/FormatToolsPlan|High-level code release tracking]] 
-  * [[design:image-requirements|Requirements for Images]] +  * [[design:format-implementation|Format Implementation Steps]]
-  * [[design:anchor-requirements|Requirements for Anchors]] +
-  * [[design:text-requirements|Requirements for Text Output]] +
-  * [[design:html-requirements|Requirements for HTML Output]] +
-  * [[design:epub-requirements|Requirements for EPUB Output]] +
-  * [[design:pdf-requirements|Requirements for PDF Output]]+
  
 +==== Reading list ====
 +The RFC Format is a large project that has required several documents to capture the requirements found in each aspect of the work. The documents depend on each other, and are moving through the community review and publication process as a set to help keep those relationships intact. Several documents require understanding a separate document for full comprehension of the material.
  
-==== Discussion topics ==== +Below is the suggested reading order for the drafts that describe the new RFC format requirements. The design team has done a great job in pulling all fo this together, and many members of the community have reviewed these in parts and offered targeted feedback. Please take this time to review the drafts as a compendium, and then review the Statements of Work that describe the programming effort that will depend on these drafts as their requirements.
-  * [[design:formats|Discussions around on Non-Canonical Formats]] +
-  * [[design:xml-tags|New or modified XML syntax]] +
-  * [[design:tool|Ideas for the RFC tool]] +
-  * [[design:svg|Thoughts on SVG]] +
-  * [[design:utf-8|Thoughts on UTF-8]]+
  
-==== Other information ==== +1. The big picture
-  * [[design:existing-xml|Pre-reading - vocabulary and today's tools]] +
-  * [[design:producing-output|How RFC Output Is Produced]] +
-  * [[design:text-sample|Sample of Text Output]] +
-  * [[design:html-notes|Notes on Existing HTML Formats]] +
-  * [[design:front-back-matter|Proposed Content for Front and Back Matter]] +
-  * [[design:format-errata|Non-Canonical Formats and the Errata system]] +
-  * [[design:design-team|The RFC Format Design Team]]+
  
-==== Format Requirements pulled from RFC 6949 ====+[RFC7990] Flanagan, H., “RFC Format Framework”, RFC 7990, DOI 10.17487/RFC7990, December 2016, [[http://www.rfc-editor.org/info/rfc7990]].
  
-      1.  The content of an RFC must not change, regardless of format, +2. The underlying vocabulary 
-          once published. + 
-           +[RFC7991] Hoffman, P., “The ‘xml2rfc’ Version 3 Vocabulary”, RFC 7991, DOI 10.17487/RFC7991, December 2016, [[http://www.rfc-editor.org/info/rfc7991]]. 
-      2.  The Canonical format must be persistent and reliable across a + 
-          large variety of devices, operating systems, and editing tools +3. The outputs 
-          for the indefinite future.  This means the format must be both + 
-          readable and editable across commonly used devices, operating +[RFC7992] Hildebrand, J. and P. Hoffman, “HTML Format for RFCs”, RFC 7992, DOI 10.17487/RFC7992, December 2016, [[http://www.rfc-editor.org/info/rfc7992]]. 
-          systems, and platforms for the foreseeable future.+ 
 +[RFC7993] Flanagan, H. “Cascading Style Sheets (CSS) Requirements for RFCs”, RFC 7993, DOI 10.17487/RFC7993, December 2016, [[http://www.rfc-editor.org/info/rfc7993]]. 
 + 
 +[RFC7994] Flanagan, H., “Requirements for Plain-Text RFCs”, RFC 7994, DOI 10.17487/RFC7994, December 2016, [[http://www.rfc-editor.org/info/rfc7994]]. 
 + 
 +[RFC7995] Hansen, T., Masinter, L., and M. Hardy, “PDF Format for RFCs”, RFC 7995, DOI 10.17487/RFC7995, December 2016, [[http://www.rfc-editor.org/info/rfc7995]]. 
 + 
 +[RFC7996] Brownlee, N., “SVG Drawings for RFCs: SVG 1.2 RFC”, RFC 7996, DOI 10.17487/RFC7996, December 2016, [[http://www.rfc-editor.org/info/rfc7996]]. 
 + 
 +4. Generalized requirements 
 + 
 +[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]]. 
 + 
 +5. Workflow and tools 
 + 
 +[RFC7998] Hildebrand, J. and P. Hoffman, “‘xml2rfc’ Version 3 Preparation Tool Description”, RFC 7998, DOI 10.17487/RFC7998, December 2016, [[http://www.rfc-editor.org/info/rfc7998]]. 
 + 
 +Hoffman, P. and T. Hansen, “Examples of the ‘XML2RFC’ Version 2 and 3 Vocabularies”, Work in Progress, draft-hoffman-rfcexamples-04, May 2015. **Not to be published as an RFC** 
 + 
 + 
 +==== 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.  This means the format must be both readable and editable across commonly used devices, operating systems, and platforms for the foreseeable 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  and the United Nations "Convention on the Rights of Persons with Disabilities" for guidance.  Appropriate authoring tools are highly desirable but focus on the creation of Internet-Drafts, a topic outside the scope of the RFC Editor. 
 +  - The official language of the RFC Series is English.  ASCII is 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. 
 +  - The Submission and Publication formats need to permit extending the set of metadata tags, for the addition of labeled metadata.  A predefined set of metadata tags must be created to make use of metadata tags consistent for the life of the Series. 
 +  - Graphics may include ASCII art and a more complex form to be defined, such as SVG line art [SVG].  Color and grayscale will not be accepted.  RFCs must correctly display in monochromatic black-and-white to allow for monochrome displays, black-and-white printing, and support for visual disabilities. 
 +  - 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, such as MIB modules and ABNF.
                      
-      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.  See the W3C'+
-          accessibility documents [WCAG20] and the United Nations +
-          "Convention on the Rights of Persons with Disabilities" +
-          [UN2006] for guidance.  Appropriate authoring tools are highly +
-          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.  ASCII is +
-          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.  A predefined set of metadata tags must be +
-          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].  Color and grayscale will +
-          not be accepted.  RFCs must correctly display in monochromatic +
-          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.+
design/start.1382034004.txt.gz · Last modified: 2013/10/17 11:20 by rsewikiadmin