[rfc-i] Comments on draft-hildebrand-html-rfc-2012-07-07 and draft-hoffman-rfcformat-canon-others-03

[tbray at textuality.com (Tim Bray)]

My first really careful review of these documents, let?s call them
?hoffman? and ?hildebrand? for short.

First: Both could work.

Hildebrand omits a lot of details about workflow and assignment of tasks
that is usefully covered in hoffman.   I think my ideal outcome would the
the workflow and polices described in hoffman, only with a canonical format
as described in hildebrand, as opposed to the much-hated rfc2xml format.
 As soon as you start to ?improve? that, you?re going to be on a slippery
slope, so why not jump all the way to a basic simplified HTML, which has
already been designed by other people, is easy to view directly, and for
which the software tools are rather fully debugged.

Details:

3.1 Syntax

- why pretty-printing?  This offers no benefits to people who want to
process the text automatically, adds extra work at authoring time, and as a
person who works regularly with HTML/XML source, it?s not obvious that it
really gives much benefit to source readability.

3.2.6

- I?d leave out <strong>, require that all emphasis be with <em>, that <i>
be used only for foreign words, <cite> where appropriate for titles, and
<b> not at all.  If people really think we need two levels of emphasis,
bring back <strong> but still leave out <b>.

3.2.11

- I'd recommend requiring <p> inside of <li>. E.g.

<li>
  <p>My first point.</p>
</li>
<li>
  <p>My second point, which introduces complexification.</p>
  <p>HTML does the paragraphs nicely and this is really useful.</p>
</li>

3.3.1

- Change ?on submission? to ?on publication?. No point making the author
package it all up, which is going to make it harder for the RFC editor to
work with. I?m not even sure the relative-URI requirement is useful at the
pre-publication phase - just require the doc editors to make sure the PNGs
are reachable by anyone who wants to see them, leave the packaging work to
the RFC Editor

3.3.4

- Also, <pre><code> works for code blocks, producing the effect you?d
probably like.
- I suggest forbidding CDATA sections
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120730/aecb0f49/attachment.htm>