[rfc-i] Proposed new RFC submission requirements

Peter Sylvester peter.sylvester at edelweb.fr
Mon May 28 03:17:18 PDT 2012

On 05/28/2012 04:47 AM, Joe Touch wrote:
> On May 27, 2012, at 4:38 PM, Julian Reschke<julian.reschke at gmx.de>  wrote:
>> On 2012-05-27 20:15, Joe Touch wrote:
>>> On May 27, 2012, at 12:20 AM, Julian Reschke wrote:
>>>> On 2012-05-27 09:04, Joe Touch wrote:
>>>>> ...
>>>>>> It allows checking the references automatically in a more reliable way.
>>>>> By what, for what reason? You're all searching for a universal document format - the library science community has none, but you can do better?
>>>> Because people get reference wrong all the time, and the easier it is to find those cases, the better. It saves elapsed time for document reviewers and the RFC Editor.
>>> The format should be optimized for longevity first, utility of the output formats second, and flexibility of the author tools third.
>>> Your argument for saving effort on intermediate steps is like writing a compiler that runs very efficiently, but limits what programmers can write and generates terrible code.
>>> ...
>> My argument is for a source format that contains sufficient information so that the processor can issue warnings when needed *and* can generate the optimal code.
> Source formats should be up to the author.
As long as the transformation to whatever intermediate format insures
reversibility of information and structure when I want to create
a new version. It is not the author that should be required to keep
the "original" piece of octets coded in an undocumented format.
(the ambiguity in the previous sentence is intended). besides that
newer versions of the well know tool to not necessarily work the same.

I once used nroff, and during the rfc editing process the textual form got
reverse engineered to produce another nroff which was not only the same
and needed a lot of corrections.

One can argue whether one would like a sequence of annotated paragraphs
counting list items and headings as annotated paragraphs with figures
attached to I don't know where or whether one wants a
hierarchical structure of the document information which may a bit more
difficult to produce and to verify

xml2rfc, yes, it is a bit painful concerning balanced structure information.
browsers have the same problem with unbalanced html since they
need to show something and the circumvention "heuristics" are not always
the same (I think), so you don't get the same results (well, even for
well-formed stuff).

some people create spec in bottom up and regroup and split paragraphs
and sections. But this is true for any type of programming.
syntax oriented editor features, additions etc are well known,
IDEs are used, but one can still use ed or vi to edit a text,
if necessary since the stored format is documented.

have you copied using pieces of paragraphs, paragraphs with different
styles. wysiwyg is fun.

> All formats may need to have components checked. That need not be native to the format.
Checking a format that is not documented and subject to unpredictable change
is somewhat difficult.

to do some nitpicking which can be solved easily (if not to say, it is trivial).
Beware of those who use the word trivial. Is
     "For more see section 3.9. or 5.9. ."
I saw in one of mentioned drafts
     " in 4.1.  or 4. 2.  "
which seems to indicate that the original text does
not contain a reference but "4. 2." as pure text.

I guess references should not have a trailing point.

PS: Trillions of flies like sh**, it must be good. Sorry, I couldn't resist.

More information about the rfc-interest mailing list