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

Brian E Carpenter brian.e.carpenter at gmail.com
Tue Jul 31 00:10:16 PDT 2012

I'm getting really confused.

This list seems to be discussing some competing solutions. But I haven't
yet seen either an agreed problem statement or an agreed set of requirements.

I know this isn't an IETF WG. But if it was, we'd surely be under a lot of
pressure to get the problem and requirements agreed first.

I'm not in Vancouver, but I'd urge you to take a collective deep breath
before continuing.

   Brian Carpenter

On 30/07/2012 22:06, Tim Bray wrote:
> 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
> ------------------------------------------------------------------------
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list