[rfc-i] Towards Consensus

Tim Bray tbray at textuality.com
Sat May 26 09:43:49 PDT 2012


On Fri, May 25, 2012 at 8:46 AM, Phillip Hallam-Baker <hallam at gmail.com>wrote:

> Watching this discussion I can see some points that I think that most
> reasonable people can agree on and I would like to suggest that these
> actually give us a pretty clear way forward as far as at least a first step
> goes.
>
> *Proposition 0: The objective of having IDs and RFCs is to communicate
> information to readers. Format proposals should be judged on their
> effectiveness as a communication medium and the demands they impose on
> document producers*
>

-1 The convenience and productivity of authors can’t be ignored.  It’s a
balancing act.


> *Proposition 1:* It is reasonable for a participant to request the
> ability to read IDs and RFCs in a particular format.
> *Proposition 2: It is utterly unreasonable for anyone to demand that
> others read IDs and RFCs in a particular format unless there are specific
> reasons why a particular format is necessary*
>

meh - I don’t think these propositions are useful in informing the
discussion.


> *Proposition 3: How to support included files (images, source code)
> should be considered separately from whether to support them*
>

-1. This is a cost/benefit analysis, nothing more.  In my case, since I
think the benefit of adding images is very low, I would be opposed to any
proposal where image provision imposed any significant costs on writer or
reader.

*Proposition 4: XML2RFC MUST continue to be supported as an input format
> *
>

+1


> *Proposition 5: HTML MUST be supported as an output format*
>

+1


> *Proposition 6: HTML output SHOULD use a restricted set of HTML features.*
> *
> *
>

-1 - I’d say MUST.  The thought of dealing with the full cruftiness of
“HTML as she are spoke” makes my blood run cold.


> * Proposition 7: HTML is capable of serving as both an input format and
> an output format*
>

Not qualified to comment. I’m perfectly comfy with authoring raw HTML, or
xml2rfc input, in an Emacs buffer, but I worry that there are still a lot
of people out there who blench at the thought of having to look at pointy
brackets.


>
>
>
> *1) A profile of HTML for use in RFCs and IDs*. This would specify
> permitted tags, required metadata and class identifiers to be applied so
> that the document displays correctly with the associated stylesheet. It
> MUST be possible to roundtrip information from the HTML profile to the
> XML2RFC format and back.
>

Agreed on the subset, but I’m unconvinced that the round-tripping is
practical.  Not saying I flatly disbelieve; just that it might be harder
than you think.


> *2) Stylesheets* for IETF, ISOC, etc documents.
>

+1

>
> *3) Modify the existing XML2RFC* toolchain to generate the new HTML format
>

I suspect it will be about as easier to reimplement; and far easier to find
someone to reimplement than to modify.


>
> *4) HTML2RFC tool.* This would perform nits checking and be capable of
> generating the corresponding XML2RFC file.
>

Unknown degree-of-difficulty


> *5) Modify the publication Web* site so that the HTML versions of the
> drafts are visible alongside the traditional format, pdf etc.
>

+1


> *6) Modify the submission tool* so that ALL that is required to submit a
> draft is to provide either the XML2RFC format or the HTML format (or the
> traditional format)
>

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120526/4d50f311/attachment.htm>


More information about the rfc-interest mailing list