RPC Wiki

1. examples of Publication outputs (they may be done manually and are designed to show what things will look like) a specification or set of specifications on what needs to be done to create the necessary tools for XML to be the canonical format that in turn creates four publication formats
2. documentation on what areas we have discussed and resolved internally so when I take this back out to the community, I can point to something that says “we discussed that issue, not discussing it again unless you have some new information that is relevant”
3. clear guidelines on how different scripts (see RFC 6365 for terminology clarification) will be allowed in specific sections of an RFC now that the UTF-8 encoding will be allowed in the Author's Address section (I expect this to have an impact on the tools, but I don't know what that impact will look like)
4. an SVG profile for tags allowed/not-allowed in the XML
5. document the requirements for the XML format and the transformation tool(s)

1. How will unintentional variations in output be dealt with?
2. Will the Publication formats be allowed to change, allowing for modifications if the transformation from XML introduces format-specific errors? Who would judge whether the bug was in the Canonical format rather than the Publication format?
3. How does xml2rfc fit in to this work? What needs to change?
4. Given the end goals, what tools are entirely missing? (i.e., is what we have now sufficient for diffs?)
5. Will we have one or more “preferred” publication formats?

• Thoughts on Non-Canonical Formats
• How RFC Output Is Produced
• Sample of Text Output
• Ideas for the RFC tool
• Thoughts on SVG
• Requirements for Images
• Requirements for Text Output
• Requirements for HTML Output
• Thoughts on UTF-8
• Proposed Content for Front and Back Matter
• Non-Canonical Formats and the Errata system

    1.  The content of an RFC must not change, regardless of format,
        once published.
        
    2.  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.
        
    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's
        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, a
        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.