[rfc-i] Towards Consensus
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
> *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
> *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
> *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
*Proposition 4: XML2RFC MUST continue to be supported as an input format
> *Proposition 5: HTML MUST be supported as an output format*
> *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
> *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.
> *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.
> *5) Modify the publication Web* site so that the HTML versions of the
> drafts are visible alongside the traditional format, pdf etc.
> *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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest