[rfc-i] normative (and vetted) text vs. diagram (was Re: Fwd: New Version Notification for draft-flanagan-plaintext-00.txt

George, Wes wesley.george at twcable.com
Thu Jun 26 08:44:45 PDT 2014


On 6/26/14, 10:59 AM, "Dave Crocker" <dhc at dcrocker.net> wrote:


>Creating a strong bias against having any ascii art is a large strategic
>change.
WG] yes, but I would make a distinction between not requiring ASCII art
alternatives and explicitly prohibiting its use, where only the latter is
creating a bias against ASCII art. If not requiring ASCII art means that
it suddenly stops being used, I think that it proves my point that it
isn't the best tool for the job.

>
>Moving towards declaring diagrams never normative is a very large
>strategic change.
WG] yes, but making our documents accessible to visually-impaired folks
needs to figure into that discussion much more prominently than making the
change in an attempt to sidestep this ASCII vs SVG debate. I'd rather have
the option of making a diagram normative when necessary, but I'm not sure
that's possible if we are to retain parity for visually impaired access
whether the diagram is ASCII or SVG.

>
>We should not back into these changes without explicit community
>discussion and a much better understanding of the collateral effects.
WG] Yes, but that goes both ways. I think I've been clear that there are
collateral effects to the current format as well, in the form of the
accessibility and approachability for authoring and consuming the
documents for new participants and non-IETF implementers.
>
>We need to be clear about the long-standing benefits of txt-formatted
>RFCS
WG] and part of being clear is revisiting and rationalizing the
justification for the current format to see what is simply inertia or
nostalgia and what is actually still a legitimate requirement or use case,
whether technical limitation or otherwise. I've repeatedly asked for
specific examples of devices in active use for consuming IETF output that
cannot by technical limitation support anything but ASCII. Your VT100
emulator window + Lynx doesn't count, nor does your printed copy, because
both of those are generated by devices perfectly capable of dealing with
simple graphics and richer formats, and any limitations requiring text are
a choice on the user's part. "why do we still need ASCII?" seems a simple
question, yet the lack of an answer is forcing me to assume that we don't.

>and we need to retain that utility.  This includes ascii art.
WG] No, we need to stop treating that as truth by assertion and justify
*why* that utility is still important to retain. Big difference.

>
>No it is not fun to produce ascii art and yes it has limitations.
>Neither point is irrelevant but neither do they justify deprecating a
>form that has been so spectacularly successful.
WG] but they do justify no longer requiring it and embracing a tool that
does not have those issues. Past success is not a guarantee of future
applicability. Vacuum tubes were spectacularly successful too, but we
still moved on to transistors when it was clear that they were superior
for all but a very few applications.

>My own suggestion is:
>
>1. If there is a artwork, there must be an ascii art version.
WG] Until I see a real technical justification for a set of consumers or
active use cases that actually CANNOT support the limited definition of an
SVG that we are planning to use, I disagree. Precedent is not enough by
itself. All I'm asking is that we look at this objectively and solve the
problems we have, rather than the problems we think we still have because
we had them 15 years ago.

Wes George


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 mailing list