[rfc-i] Problems and requirements for RFC Format

Heather Flanagan (RFC Series Editor) rse at rfc-editor.org
Wed Apr 18 06:58:21 PDT 2012


On 4/17/12 3:01 PM, Joe Touch wrote:
> Hi, Heather,
> 
> Your summary looks good, except that I worry that it's so complete as to
> ensure it cannot be satisfied.

I know.  At this point, however, I'd rather the list be complete and
make a conscious decision later regarding to what not to include.

-Heather

> 
> 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
> _______________________________________________
> 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