[rfc-i] Towards Consensus

Phillip Hallam-Baker hallam at gmail.com
Sat May 26 17:55:16 PDT 2012


On Sat, May 26, 2012 at 12:43 PM, Tim Bray <tbray at textuality.com> wrote:

> 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.
>

The objective is communication. The cost of producing the documents has to
be balanced against the advantages but is not the ultimate objective. I did
say the damands imposed on the authors is relevant but I am happy to change
the wording.



> *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.
>

I don't think there is much dispute as to the value of included source
files. Since the technical demands for images would be identical, can't we
just agree for the sake of argument that we are going to be dealing with a
compound document and defer the discussion of which ones we are going to
support?

We have had ABNF and XML Schema in RFCs for ages. It would be nice if we
had tools that could check syntax and nits for those as well as the main
text.



> *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.
>

OK, strengthen that to a MUST, I don't think anyone is actually arguing for
unrestricted HTML.



> * 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.
>

XML2RFC does have ten years practical experience built in. So being able to
convert back and forth would provide at least some form of sanity check on
the proposal.

I don't think it is particularly hard to do either.



>
>
>> *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.
>

Yeah, whatev.


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

I don't think it at all hard to do with C# and .NET.

I will let you know if I was right.


> *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
>


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120526/bf577e74/attachment.htm>


More information about the rfc-interest mailing list