[rfc-i] Problems and requirements for RFC Format

[=JeffH]

Hi Heather.

Here's a few quick thoughts on the requirements. Unfortunately there may be 
some duplication with others' feedback in the extensive thread(s).


 > 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


need to be able to write a doc in a given format, and then easily render it in 
multiple other formats, without or minimizing any format-specific-tweaking, for 
distribution to various audiences via various means (e.g. hardcopy, email, web, 
ftp, etc.)

need to be able to easily locally search through sets of both source-format and 
published-format (i.e., .txt) docs using common tools (e.g., using grep and 
cousins)

need to be able to use common source management tools (e.g. cvs, git, etc.) for 
managing document sources and outputs, both for individual authors and for 
group authoring.


note that docs in the I-D format are also written and/or distributed "outside" 
of the IETF..

  examples:

   OpenID's original specs <http://openid.net/developers/specs/>

   a whitepaper I wrote:
    http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html

I assume there's a host of detailed reasons for this external-to-IETF-use, 
though the top-level summary is perhaps the open availability of the xml2rfc 
toolset, its overall ease-of-use, and the usefulness of its multiple parallel 
outputs (.txt, .html, etc.).

I mention this because this "Draft-Edit" section (or "stage in the 
spec-production pipeline") has wider applicability (ie more use cases) than 
just the focused lets-write-and-produce-an-RFC use case, and these are likely 
worth factoring in (tho how to weight their requirements is another question).

HTH,

=JeffH