[rfc-i] Number of submission formats
nico at cryptonector.com
Fri Jan 18 13:30:57 PST 2013
On Fri, Jan 18, 2013 at 12:45 PM, John Levine <johnl at taugh.com> wrote:
>>> Specifically, for any given RFC there should be one canonical form
>>> which needn't be the same as for other RFCs (i.e., some will be .txt,
>>> some will be PDF, ...). And for any input to the RFC-Editor queue
>>> there should be a single canonical input form that the editors will
>>> work with (XML with whatever schema, nroff, ...).
> Heck, no. There is a canonical output format, the one to which we
> point if someone wants to know what is "the RFC."
Today's I-D upload tool has several input formats allowed, one is
required. The .xml input is only really useful when a) you want
others to be able to see it (and contribute XML changes) or b) the I-D
is about to get sent to the RFC-Editor queue, in which case the editor
can just... find it there, saving a step in the process.
But the RFC-Editor will also take nroff, so being able to submit
either or both of those is useful.
> There are acceptable input formats. Currently there are, as I
> understand it, 2 1/2 input formats, line printer format similar to the
> current output format, xml2rfc, and maybe nroff if it uses the same
> coding the production people use.
I can't imagine the RFC-Editor being happy to work with the formatted
.txt only as an input. Say I edited an I-D that way, formatting and
paginating by hand (don't laugh, I used to, though I had a script to
do the pagination)...
> I don't see any reason to change that structure. [...]
Paul is the one that proposed a change. I was trying to get that
change narrowed and clarified.
More information about the rfc-interest