This is an old revision of the document!
draft-hoffman-rfcformat-canon-others-03
Pagination
Character encoding
Mobile Devices
We should take their needs for format flexibility (reflow) in to account
Not enough people use mobile devices, and those that can can generally scroll, so this should be treated as an edge case
Use of tools
We can't be that unique in our needs that we can't use commercial tools
We have more control over the tools we write, to make sure it meets all other requirements, and we have xml2rfc to work from as a base
ASCII art
It does not allow for reflow
It forces people to rely more on words and clear written descriptions than the diagrams; each diagram is relatively simple and discrete
The often poor, limited diagrams are a hindrance to visual thinkers
Dependence on advanced diagrams (or any diagrams) causes accessibility issues
If we go beyond
ASCII art, need to pick just one format: GIF? PNG? SVG?
If we go beyond
ASCII art and have the normative diagrams be entirely separate documents, we do not need to limit ourselves to one graphic format
Equations
Some authors have chosen not to publish
RFC due to difficulty in displaying proper mathematical equations
So few
RFC include mathematical equations that this should not be given any priority in the discussion of format
Metadata and tagging
Ability to semantically tag some document info, at least authors' names and references is useful
Metadata is unnecessary overhead
HTML
Containment
Containment is good
Containment is unnecessary and not compatible (or perhaps just not required?) with traditional
HTML and word processor document
Tags
there is no list of tags that will be required for XML or
HTML, thus building in required simplification and support for the archival nature of the series (that people can work longer with a simplified set of tags)
XML
ASCII
Containment
Containment is good
Containment is unnecessary and not compatible (or perhaps just not required?) with traditional
HTML and word processor document structure