[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?
paul.hoffman at vpnc.org
Thu Jun 21 13:16:51 PDT 2012
On Jun 21, 2012, at 12:57 PM, Joel M. Halpern wrote:
> HTML has the itneresting property that it is both an input form and a presentation form.
Errr, no. HTML must be sent through a display renderer in order to be a presentation form. In its native form, HTML is just as easy/hard to read as XML.
> So it muddies the water (which may be the right answer.)
If what you are saying is "the canonical form should have common renderers", then HTML would be preferred over XML. However (avoiding all caps there, but barely), you are assuming that the CSS associated with the canonical format is either part of the HTML file itself or that the HTML has a normative link to a static CSS file. Is that really what you want? This will very likely lead to errors if the CSS makes either vertical or horizontal spacing issues that are not easily detected by authors who are only looking at the rendered version. (This is one reason we have HTML experts in the IETF....)
> I am not saying that the RFC Editor should only publish one output form.
What other conclusion can be drawn from your statement "Further, I note that in practice, checking for correctness will be done by the authors (e.g auth48)on the output form, not the input form. Hence, I just can't see how the input can be canonical."? Unless you are saying that the authors must review every format that the RFC Editor will publish, you are saying that the RFC Editor must publish just one format, yes?
> Such a restriction seems counter-productive.
Fully agree, which is why I'm drilling down on this subject.
> Rather, there should be one form that readers who are NOT active IETF members, and who may not be able to read XML or SGML, can check in the case of apparent inconsistencies to make sure they know what the precise spec is.
Anyone can read XML if it is formatted for reading. The same is true for HTML. If you mean "displayed HTML", again you hit the problem of things that might be bolloxed by the CSS in review but that express themselves when converted to the other formats.
> If we decide that HTML is the right input form, I am probably willing to let some well-defined rendition of that HTML be the canonical form for resolving such inconsistencies.
Does this mean no CSS? Or mandatory invariant CSS? Or...?
> Note: If everything works well, such issues should be rare. Based on history, I know that rarity will not be equivalent to 0.
Fully agree there.
More information about the rfc-interest