[rfc-i] feedback on draft-hoffman-rfcformat-canon-others-00, was: RFC Format - final requirements and next steps

Julian Reschke julian.reschke at gmx.de
Thu May 17 11:09:32 PDT 2012


On 2012-05-17 20:03, Paul Hoffman wrote:
> On May 17, 2012, at 6:26 AM, Julian Reschke wrote:
>
>> On 2012-05-12 20:11, Paul Hoffman wrote:
>>> Greetings again. A draft of my proposal can be found at<http://www.ietf.org/id/draft-hoffman-rfcformat-canon-others-00.txt>.
>>> ...
>>
>> Here's some quick feedback:
>>
>>> 2.  Canonical RFC Format
>>>
>>>    Canonical RFCs are text files.  The format of those files is:
>>>
>>>    o  Text paragraphs consist of a single line with no line wrapping.
>>
>> Alternatively, it could use "soft line breaks" (lines with SP LF), in which case the text would still display in programs that do not wrap lines.
>
> Sure, but is it necessary? The draft proposes that one of the other formats published by the RFC Editor be close to the current one (LPF, or "line printers forever"). The ever-decreasing number of users who want to read an RFC in software that does not wrap lines could use that format instead.

OK.

>>>    o  The document has no page breaks and thus no page headers and
>>>       footers.
>>>
>>>    o  It is explicitly allowed to have art in external files.  Those
>>>       files are referred to in figures in the RFC as URLs that point to
>>>       the RFC Editor's web site.  The RFC Editor will determine which
>>>       graphic formats are allowed, and it is likely that at least SVG
>>>       and GIF will be permitted.
>>
>> I think it would be cool if we could address the case where the canonical version has ASCII art inline, but other variants are available as links.
>
> Good catch: I did not call out "variants", which I think others here have asked for. I'll do so in the next draft.
>
>> Also, s/GIF/PNG/
>
> Either, or both, seems fine. I'll soften the wording to not foreshadow decisions by the RSE that will be heavily bikeshedded.

Ack.

>>> 4.  Input Format for RFCs
>>>
>>>    This document does not suggest an input format for RFCs.  The RFC
>>>    Editor needs to decide that in coordination with all of the
>>>    representatives of the various RFC streams.  Fortunately, the
>>>    decision of the input format does not need to be tied to the decision
>>>    of the canonical RFC format or the non-canonical versions available
>>>    at any time.  Even if the canonical RFC format is the one described
>>>    in this document, there is no reason that the input format to the RFC
>>>    Editor has to be the same format: it could be XML, HTML, and so on.
>>>    The conversion from the input format to the canonical and non-
>>>    canonical formats used by the RFC Editor is done by the RFC Editor
>>>    with their own tools and human-based processes.
>>
>> ...which should be available to the community as well.
>
>
> The tools, or the human-based processes? :-)

If it's not doe by tools, we'll have a problem :-)


More information about the rfc-interest mailing list