[rfc-i] not just 'lineprinter' (was Re: Fwd: New Version Notification for draft-flanagan-plaintext-00.txt)
wesley.george at twcable.com
Fri Jun 27 12:09:15 PDT 2014
On 6/27/14, 12:42 PM, "Dave Crocker" <dhc at dcrocker.net> wrote:
>> WG] We debate the content of the text, not the format, and the tags
>> that tell the machines what to do aren't overly useful for humans
>> when debating the content, so we leave them out. That's not news, and
>> it doesn't necessarily justify any particular format. In other words,
>> the format is completely transparent unless one is actively debating
>Except that it typically isn't transparent. When someone draws from the
>xml2rfc version, we usually see the labels included in the postings.
>When we don't see the labels, people are typically drawing from the txt
WG] The part of my reply that you edited out refutes this restatement of
your original assertion and example, and no one will benefit from me
attempting to restate my side. We're talking past each other at this point.
>You said you don't see current relevance of txt format. To say that is
>to, yet-again, attempt to re-fight the battle of whether txt should be
>The reality is that what most of us see and use is the txt format for
>most IETF discussions.
>> What I've been saying all along is that the restrictions imposed by
>> the current format and/or the requirement to maintain a text-only
>> version of I-Ds and RFCs add no value by themselves because the
>So at base you refuse to accept the decision to retain txt version and
>you are therefore injecting comments intended to re-argue the case,
>rather than focus on the actual topic at hand.
WG] You're mischaracterizing my motivation and opinion, but this thread
was sort of all over the lot, so I'll attempt to clarify, though I think
it'll be futile.
Use of line printer was shorthand for the format, since my understanding
is that "print on a standard 10-pitch line printer on A4 or Letter paper"
was part of the original design goal for formatting the documents. Since
no one uses line printers or dumb terminals anymore, I think it's
appropriate to be asking a couple of questions about the current drivers
and requirements for statically formatting a text-only version:
1) Whether the character formatting, pagination, headers, etc used by the
current text version of an I-D or RFC (I.e. Draft.txt or rfcnnnn.txt) is
still necessary to retain completely unchanged in perpetuity, and if so,
I am saying that I do not find the arguments justifying retaining this
exact formatting of text particularly compelling, and trying to push for
more objective reasons or technical considerations to support them. So
far, we have gotten at least the need to reference a certain portion of
text by anchor or page, but little else, which is leading me to the
conclusion that the reasons for the current text version's format
requirements are largely historic rather than current. But since the plain
text version will no longer be canonical, its formatting restrictions
shouldn't matter to me, because I should be able to just use a different
derivative format like HTML.
Except for the second question...
2) Whether it is necessary to keep the document from #1 completely plain
text and thus require ASCII art alternatives to any graphics generated
using the new methods permitted in the canonical format defined by RFC
6949, and if so, why.
This makes the formatting of the text version everyone's problem instead
of only those who intend to keep using it.
I've noted technical reasons why ASCII art is not a universally supported
alternative, and that it has always been simply a substitute for
displaying a graphic, rather than the preferred method of building a
diagram. I understand that some disagree with that view.
The question I keep asking is, what *current* use case requires
exclusively ASCII text and cannot support an inline graphic or a reference
URI such that everyone needs to be *required* to build ASCII art
alternatives? That tends to circle back to overall discussion of the
formatting of #1, it's kind of unavoidably linked.
The draft in the original subject line is, by suggesting formatting
changes to the text output, posing the question in #1 and that naturally
leads to #2, so I'm not refusing to accept any decision or attempting to
re-fight anything that is already decided.
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
More information about the rfc-interest