[rfc-i] feedback on draft-hoffman-rfcformat-canon-others-00, was: RFC Format - final requirements and next steps
touch at isi.edu
Thu May 17 11:52:17 PDT 2012
On 5/17/2012 11:42 AM, Paul Hoffman wrote:
> On May 17, 2012, at 11:28 AM, Joe Touch wrote:
>> Here's some of my feedback on this:
>> Sec 2 is incomplete as follows:
>> - It specifies the format of paragraphs, but the semantic content of text is significantly affected by structure, such as heading level, numbering, lists, and sometimes indentation (whether you agree or not, this is still the standard for bulk inclusion of quoted text).
> I'm missing something. I don't see how the proposed format (unwrapped text) affects any of "heading level, numbering, lists, and sometimes indentation". Can you give an example? I get the feeling I should be adding something, but I don't see what.
I'm saying that Sec 2 says nothing about how those items are indicated.
If that's the intent, then it should be stated.
I.e., why are paragraphs defined, but none of the others?
Do you mean that "all text items - paragraphs, headings, list items,
etc." are unwrapped text excluding CR/NL characters?
Maybe that's the better solution - to revise this section to refer to
paragraphs of body text as just one sort of text element, and that all
text elements are unwrapped text.
>> - it specifies UTF8, but is it limited to printable UTF8? what does TAB mean? (what are default tab settings, or is it always "add 8 spaces"?), etc.
> It is not limited to printable UTF8: otherwise, we would have no line endings. :-) The question of TAB and its many other "interesting" control character friends is left to the RFC Editor.
That should be noted; if you're going to refer to UTF8, perhaps note
that "printable UTF8 with a subset of control characters to be
determined later, including at least space and CR"?
>> - text art is not appropriate unless there's a way of indicating fixed-width font for that portion of the document; regardless of whether 90 chars can be printed, the art is nonsensical unless in fixed-width font (which then begs the question of font indication)
> Fully disagree. For the canonical version or any non-marked-up version, fixed-width is required for alignment of art (which includes ABNF). We don't need to say what font is used for display, just that it be fixed-width. For marked-up versions (such as HTML), they need to be able to encapsulate lines with text art but, again, they don't have to specify the font, just indicate that it should be fixed-width.
Fair enough; this assumption should be noted, though.
>> Sec 3 - there's no reason to refer to HTML here. The text is just as valid if another format were chosen (e.g., PDF).
> There is a very good reason: many people in this discussion have shown a strong desire for HTML. Ignoring that is ignoring a seeming consensus.
Either this document is about the difference between canonical and other
formats (which is what I thought it was about), or it is declaring HTML
the canonical format too.
If the latter, there should be a substantial discussion on that issue
and it should be made clear.
Either way, though, the choice of HTML as a canonical format has nothing
to do with the other points this document makes, and it would be useful
to be clear about what parts are interdependent and which are not.
>> I agree that HTML is useful to consider at least as one of the noncanonical formats, but this doc would be more useful if it didn't assume that HTML was in the running as the canonical format.
> Fully disagree. We should be honest about the community's stated desires.
More information about the rfc-interest