[rfc-i] Proposed new RFC submission requirements
touch at isi.edu
Fri Jun 1 11:48:42 PDT 2012
On 6/1/2012 11:40 AM, Martin Rex wrote:
> 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.
It's a very bad place to start. If the changes are that small, then
write the "diff" doc itself. If not, then the entire contents are worth
revising in the current environment.
Whether this is possible is different from whether the formats and tools
ought to be *expected* to support it.
IMO, any tool that I can't cut/paste content from nearly any output
format and get most of the way there, and can adjust format in a few
minutes to either match the original doc or a new desired structure is
If we stop increasing the effort of the toolchain and use tools that
don't have such a steep learning curve, we won't need to expect
authoring support for docs that have reached RFC.
>> 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.
> Better DON'T!
> 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.
If the mod is that small a change to an existing protocol, it is better
described by a doc that indicates only the changes, not one that
includes the entirety of the previous protocol with changes.
We should not be relying on diffs to explain differences with past
versions. Updates to existing protocols ought to have a required section
explaining the differences explicitly.
More information about the rfc-interest