This is an old revision of the document!
Current proposals:
This is a summation of the more polarizing issues related to RFC format. Many participants in the discussion have dropped off in reaction to the sheer quantity of discussion around these and the other topics. To bring everyone back up to speed, this list the more contentious topics.
Definitions
Submission format, Input format = Internet-Draft as submitted to the RFC Editor; may or may not be the same as any other format (though it would make the workflow somewhat simpler for the RFC Editor if it were); if necessary, will be converted to another format for further processing and publication
Canonical format = the authorized, recognized, accepted, official version of the document; other document types may be derived from this format; may or may not be one of the possible output formats
Archival format = currently the printed, paper copy and the digital .txt of the RFC
Output format, Display format = format as it may be read or printed after publication process has completed; currently ASCII, PDF, and HTML are common output or display formats
Reference format = the version of the RFC commonly used as a normative or informative reference; currently the ASCII format; need to determine if this format can/will be the equivalent to the Canonical format, and if not, what is the appropriate format to reference
Pagination
Character encoding - ASCII
Character encoding - UTF-8
For: Allows authors to spell their names correctly; certain special characters in equations or quoted from other texts allowed; citations of web pages using more international characters possible; in discussions of internationalization, actually being able to illustrate the issue is rather helpful, and you can't illustrate a Unicode code point with “U+nnnn”.
Against: Exactly what characters are allowed and where the line should be drawn remains unclear (why some characters commonly used in European languages and not other, non-Latin characters? This is just pushing the problem around.)
Additional thoughts: just moving from
ASCII to UTF-8 (as opposed to UTF-8 and
HTML or XML) leaves us with dependencies on the local file systems and processors to be configured properly and do the right thing with the document though adding a byte-order mark (BOM) to the beginning of each non-
HTML UTF-8 text file will go a long way towards recognition; browsers will recognize UTF-8 and can declare the encoding definitively
Mobile Devices
For: We should take their needs for format flexibility (reflow) in to account
Against: Not enough people use mobile devices, and those that can can generally scroll, so this should be treated as an edge case at best
-
Production and publication issues
Use of RFC-specific tools
Against: We can't be that unique in our needs that we can't use commercial tools
For: We have more control over the tools we write, and the audience that reads RFCs will always be capable of coding up something new if needed; we have xml2rfc to work from as a base and should perhaps consider how to retain nroff
ASCII art
For: Dependence on advanced diagrams (or any diagrams) causes accessibility issues; forces people to rely more on words and clear written descriptions than the diagrams; each diagram is [relatively] simple and discrete
Against: It does not allow for reflow; the limitations to the diagrams are a hindrance to visual thinkers
Additional thoughts: If we go beyond
ASCII art and have the normative diagrams be entirely separate documents, we may not need to limit ourselves to one graphic format (but doing so may make things simpler). Also, if we go beyond
ASCII art, wneed to pick just one format: GIF? PNG? SVG?
Graphic art / Advanced diagrams
Equations
For: Some authors have chosen not to publish
RFC due to difficulty in displaying proper mathematical equations
Against: So few
RFC include mathematical equations that this should not be given any priority in the discussion of format
Metadata and tagging
For: Ability to semantically tag some document info, at least authors' names and references is useful
Against: Metadata is unnecessary overhead
Additional thoughts: there is no complete list of tags that will be required for XML or
HTML that would build-in required simplification and support for the archival nature of the series (that people can work longer with a simplified set of tags), and until we have that, we cannot talk about tags (note that a list has been started in the XML format I-D)
Containment
For: Lack of containment for sections means that processing software cannot be fully aware of the document structure, and that is serious restriction
Against: Containment is unnecessary and not compatible (or perhaps just not required?) with traditional
HTML and word processor document
Against: Requiring containment may limit the number of editors authors can use to create documents
Against: Requiring containment would require every authoring format to be translatable to the submission format
Against: Containment should be optional
Source Code format