[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?
John R Levine
johnl at taugh.com
Thu Jun 21 18:26:03 PDT 2012
> Suppose that we declare that you submit however you want, and we generate
> text, html, pdf, ebook, and absurdogram formats. I don't care how automated
> it is, or how much we check the software, sometimes, there will be
> differences. Mostly, they won't matter. But once in a while, they will.
Honestly, that sounds like the worst of all possible worlds. There's no
master document with metadata we can rely on. I hope it's obvious why a
process that depends on manual intervention to produce other formats is a
bad idea. (Hint: in case of a problem detected several years later, how
do you resolve where the problem lies?)
> I am not so much worried about lawyers as about providing an easy way for
> users to resolve confusions in such cases.
Well, yes. That's why it seems obvious to me that we should pick one form
that contains all the metadata as the master document, and derive all of
the rest of the versions from that. I am really having trouble why people
think that xml2rfc wouldn't be suitable. It has all the info, we have a
reasonable start on the toolset, and in a pinch, it's not that hard to
read if you need to.
I've now asked several times for an example of a way that an xml2rfc
document might be broken, and the problem wouldn't be evident in the html
or text versions, with no replies at all. It's hard to make any progress
if people are hung up over problems that don't really exist.
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
More information about the rfc-interest