[rfc-i] Problems and requirements for RFC Format

Joe Touch touch at isi.edu
Tue Apr 17 15:01:33 PDT 2012


Hi, Heather,

Your summary looks good, except that I worry that it's so complete as to 
ensure it cannot be satisfied.

Some omissions I note, though (from the discussion; these aren't my 
personal requirements):

(at all phases) "Ability to denote protocol examples using the character 
sets those examples support". This is a variant of "Respect for authors' 
names", but is more technically-oriented.

(at all phases) "Ability to semantically tag some document info, at 
least authors' names and references".

The "Single file" might apply at all phases, not just RFC-edit. In 
particular, AFAICT it applies the most at the archive format, but 
perhaps less so elsewhere.

(for archive)"Long-lived file format with an open specification, i.e., 
such that the community can continue to support it even if commercial 
support disappears"

It might be useful to have some notion of what aspects might be 
negotiable (I'd stray away from MUST/SHOULD/MAY formality, though). 
Granted, that might be in the next step.

Joe

On 4/17/2012 2:13 PM, Heather Flanagan (RFC Series Editor) wrote:
> 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
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest


More information about the rfc-interest mailing list