[rfc-i] Call for Comment: "RFC Format Requirements and Future Development"
peter.sylvester at edelweb.fr
Sat Feb 2 00:53:34 PST 2013
The text contains a paragraph.
* The Canonical format should be structured to enable easy
program identification and parsing of code or specifications,
such as MIB, ABNF, etc.
For such code snippets it also occurs that the pieces documented
in the text are regroupped in an annex. Done by hand this
can easly lead to consisyency problems and omissions.
It seems useful to have a way to annotate code snippets and
to be able to collect them in order to produce an external
file to be usable directly and also to produce consistent
annexes if necessary.
I think the canonical format should not only simplify
this work but the clear identification of such "code" seems to
be a important information in an RFC.
Another example of usage are the collection of ASN.1 modules
which suffer more or less from errors and inconsistencies
of the standards tracks base docs but should rather be creatable
by semi-automatic extraction without manual process.
Having seen the comment fromNico concerning:
* Having the Revisable format be in a markup language instead of
in a simple text-formatting structure ties us in to specific
tools and/or tool support going forward.
I'd say that there is a bit of sloppy language:
'a simple text-formatting structure' is a (somewhat limited)
markup language. I suggest adding some text indicating that
such extractions should not be done based of heuristics
of using markup for formatting bur rather on semantic
2.5: The text could be a more detailed about where and when the
nroff ids produced. I remember having created a text with nroff and send in
both the result as well as the source. Well, the editor
(many years ago) remade the nroff and it contained MANY
formatting errors. The errors mostly occurred in one line
code snippets of ASN.1 which which are difficult to detect.
More information about the rfc-interest