[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?

[Joel M. Halpern]

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.
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.)

Yours,
Joel

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.
>
> R's,
> John
>