[rfc-i] not just 'lineprinter' (was Re: Fwd: New Version Notification for draft-flanagan-plaintext-00.txt)
dhc at dcrocker.net
Fri Jun 27 09:42:40 PDT 2014
On 6/27/2014 8:57 AM, John Levine wrote:
>> This use of 'lineprinter' as a tag for text presentation is a
>> clever bit of distracting marketing.
> I use 'lineprinter' because 'plain ASCII' is misleading.
That's the historical reference in the IETF. And since we are in the
IETF, use of that abbreviation has plenty of clear context.
If you don't like that, try txt, as I've been using. It's neutral and
On 6/27/2014 9:01 AM, George, Wes wrote:
> On 6/27/14, 9:12 AM, "Dave Crocker" <dhc at dcrocker.net> wrote:
> the implication of something archaic is intentional,
> because I honestly don't have a sense for the current utility, so I
And yet I provided one in the note you are responding to.
But that's almost secondary to the question of seeking biasing language
rather than just discussing things in terms of their technical tradeoffs.
We are retaining txt format. Let's stop trying to marginalize it.
> don't see a point in treating it with any particular reverence. I
> think you're continuing to overstate the unique utility of the
> *format* itself in vague terms order to make your case, so I think
> we're both guilty of some rhetorical license, and unlikely to
> convince each other if we continue like this.
I'm guilty of noting a long-standing and spectacular success and wanting
to respect its track-record. I'm guilty of noting that changing
something that works always produces unintended consequences and that
they are almost always unwanted. I'm also guilty of noting many
short-lived failures and wanting to respect their risks. Bright shiny
new capabilities are delightful. However ones that survive over time
are problematic to predict.
Perhaps 20-25 years ago, there was a strong push to have us standardize
on using HTML for RFCs. I was impolite enough at an IETF plenary to
note that there was no core, fixed, stable version of HTML for us to
choose. No document we could point that specified a universal core that
we could rely on. It got a nice laugh at the plenary, but the issue was
and remains quite serious.
>> By way of the simplest possible example, please note that IETF
>> discussions about draft revisions usually are in a form that is
>> based on the text version and not on a markup version. Sometimes
>> xml2rfc form is used, but not that often. Essentially never in
>> html or epub or...
> 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
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.
More information about the rfc-interest