[rfc-i] Proposed new RFC submission requirements
mrex at sap.com
Fri Jun 1 11:40:59 PDT 2012
Joe Touch wrote:
> Peter Sylvester wrote:
> > As long as the transformation to whatever intermediate format insures
> > reversibility of information and structure when I want to create
> > a new version.
I agree with Peter that the ability to take an existing RFC or I-D,
and even more so and abandonned I-D and convert it back into ones
favorite authoring format is a HUGE advantage.
NRoffEdit can do this. I just tried this with rfc5746.txt (a document
authored with xml2rfc). The resulting TXT output from NRoffEdit's
reauthoring shows ZERO diffs with http://tools.ietf.org/rfcdiff
When replacing the textual "Table of Contents" with an NRoffEdit-managed
Table of Contents" (5 seconds work), one notices with rfcdiff was
missing the "Author's Addresses" section.
While the automatic conversion isn't perfect (the heuristics about
.in vs .nf/.fi macros could be slightly better. The HUGE advantage
is that you can start adding/changing contents pretty much _instantly_
after picking up the TXT, and take care of occasional .in vs. .fi/.nf
bikeshedding in your spare time rather than being an initial roadblock
to your creativity an enthusiams.
> The entire publishing community - including the research community
> - recognizes that access to source format does not impede the ability
> to write new material even when it reuses previous material.
> New documents shouldn't be minor revisions of existing docs. They often
> need to be substantially revised in content anyway, structurally
> reorganized, etc.
Whenever a revised information about _the_very_same_ protocol, as well
as a new protocol revision are created from an existing specification,
it is _extremely_ valuable if the new document and the existing document
can be diffed by http://tools.ietf.org/rfcdiff in order to determine
the _exact_ differences between both in order to add the new features
or support for a new protocol version to an existing implementation.
Messing around heavily will create major headaches with the readers
of the document, and is only sensible when it is anticipated that
new implementations will have to be done from scratch anyway.
More information about the rfc-interest