[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?
Joel M. Halpern
jmh at joelhalpern.com
Thu Jun 21 15:26:37 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,
I am not so much worried about lawyers as about providing an easy way
for users to resolve confusions in such cases. (This is, from where I
sit, the same argument that we use for why we pick one specific
representation inside a spec to be normative, even though we check
carefully that they are the same.)
On 6/21/2012 4:14 PM, John Levine wrote:
>> singular, form which can be read in the case of inconsistency.
>> thus, I am very uncomfortable with a canonical form that is the xml, etc.
> Why? This is a real question. I submit all my drafts in xml2rfc, I
> proof the html and occasionally the txt version. I'm having trouble
> coming up with a plausible scenario in which there would be a problem
> with the xml2rfc that wouldn't be apparent in the html and the txt.
More information about the rfc-interest