[rfc-i] Problems and requirements for RFC Format

Heather Flanagan (RFC Series Editor) rse at rfc-editor.org
Tue Apr 17 14:13:08 PDT 2012


Hi all -

Thank you all for your patience and input to the RFC Format question.
One of the things I've been working on is an organized list of what
problems we're trying to solve and what the requirements actually are
for the RFC series.  As Larry Masinter mentioned in the BoF, there are
several different constituencies that have their own particular problems
and concerns, and that will in turn influence whatever we decide
regarding the future of the RFC format.

What I would like from the folks on the rfc-interest list is feedback on
whether or not I've captured consensus on the problem space.  Note that
I'm avoiding formal use of MUST and SHOULD right now, though I have
tried to indicate level of requirement as I understand it so far.

======

Draft-Edit (what authors worry about when writing an I-D)
* Respect for authors names (Limit to character set prevents proper
display of all names)
* Authors need a way to update documents easily and see how they might
look when published
* Need to be able to include complex graphics/equations
* Need be able to diff versions of a draft
* Need to be able to create new documents by hacking away at older ones
* Want a more flexible line length
* Want to be able to tag ownership/source of comments


Draft-Review (what authors, Ads, and working groups worry about when
reviewing an I-D)
* Respect for authors names (Limit to character set prevents proper
display of all names)
* Need to be able to include complex graphics/equations
* Need be able to diff versions of a draft
* Want a more flexible line length
* Want to be able to tag ownership/source of comments


RFC-Edit (what RFC editors worry about when editing a document)
* Respect for authors names (Limit to character set prevents proper
display of all names)
* Need to be able to include complex graphics/equations
* Want a common source file type (lack of one common source file type
results in more training on markup language (nroff, xml) and
inconsistency in output)
* Want a single, discrete source file for a draft (not multiple files
and a make file)
* Want a publicly available "official" conversion tool (same source file
producing the same output between I-D submission and RFC editing step)
* Need source file to be editable by both authors and RFC editors


RFC-Archive (what the RFC Editor worries about when publishing an RFC)
* Need format to be easily rendered in to other, potentially undefined
formats (.txt, .html, other)
* Need one format to be the authoritative version, suitable for legal
records
* Need to be able to create new documents by hacking away at older ones
* Need backward compatibility to recreate documents originally created
in an older version of the output tools (backward compatibility issue
doesn't apply to docs published prior to the format change)


End consumption (what consumers of RFC worry about)
* Need to be able to see complex graphics/equations
* Want to be able to link sections and jump ahead in the document
* Want intelligent html-style linking within references
* Want the RFC to be suitable for small screens/mobile devices
* Want to have neat printing (intelligent pagination)
* Need to be able to search document and document repositories with
tools such as *grep

======

So, what's missing?

-Heather Flanagan, RSE



More information about the rfc-interest mailing list