[rfc-i] Wes George review of rfcformatreq

Bernard Aboba bernard.aboba at gmail.com
Fri Dec 28 10:23:23 PST 2012


(Forwarded at Wes' request).

[WEG]

-------- Original Message --------
Subject: RE: [rfc-i] Wes George review of rfcformatreq
From: "George, Wes" <wesley.george at twcable.com>
To: Brian E Carpenter <brian.e.carpenter at gmail.com>
CC: Bernard Aboba <bernard.aboba at gmail.com>,RFC Interest	 <rfc-interest at rfc-editor.org>,"Heather Flanagan (RFC Series Editor) (rse at rfc-editor.org)" <rse at rfc-editor.org>

First things first - I'm having problems posting to this list despite having been subscribed to it (receiving messages) for nearly a month. I think I'm stuck in moderation, so I can't guarantee that anyone other than the direct addressees will see my response. That's why Bernard forwarded my review. Someone may need to do likewise with this message.

> From: Brian E Carpenter [mailto:brian.e.carpenter at gmail.com]
>
> I'm all for improving readability, but for the IETF stream, the
> canonical format is also the normative reference format, so all
> normative information must be present in the canonical form of an RFC.
> That means we must be very clear whether features such as colour or
> greyscale are required to be supported. I say not, because they are too
> complex and subject to varying definitions to be used for normative
> purposes (as in "The protocol elements shown in pink are OPTIONAL and
> those shown in red are MANDATORY").
>
> In other words, for every feature we let into the canonical format, the
> IETF stream will need a statement like "This feature MUST NOT be used to
> indicate normative information" or "This feature MAY be used to indicate
> normative information".
[WEG] Well, I agree with that concern, hence my statement, "it makes far more sense to *allow* for the definition  of color, with the understanding that if color data is ignored due to the inability of a display to render it, it will not affect the quality of the drawing nor its ability to convey information to the reader." That simply says "color MUST NOT be normative" in more words. In your example, the key question is whether the diagram/color is the *only* place that normative requirement appears, or if it is defined elsewhere in normative text and the diagram is simply illuminating the concept. The former would be unacceptable, while in my mind the latter is fine. That would also address accessibility concerns by ensuring that a graphic that is unlikely to translate into something useful when read through a txt to speech translator is the only place that normative information is contained in the draft. But I don't think that this leads us to banning the use of color in the canonical form altogether.

> I think that argues for minimalism in the feature set.
[WEG] I disagree. I think inertia, precedent, and nostalgia are what's arguing for minimalism in the feature set, and none of those are good reasons on their own. I think that there needs to be a better justification for why we should continue to retain some of these limitations, rather than simply assuming that they should remain because they exist today. I think the idea that all normative information MUST be available in the canonical form is the right one, but I remain unconvinced that the canonical form must be limited to simply black and white text as a result. As I noted, we are applying limitations that used to be technical 25+ years ago (LPR plus truly monochrome TTY displays as state of the art for consuming I-Ds) and forcing the canonical form to retain them now that they are primarily an affectation. Today's "monochrome TTY" is an emulator running in a window on a monitor driven by a device capable of displaying millions of colors and very complex graphics. The fact that some choose to use that for consumption of I-Ds is primarily based on the fact that it's the simplest way to do so right now because of the current format, rather than it being truly the most effective way to convey all information. The technical limitation now is probably printing it on physical paper or display on e-ink screens, neither of which can be guaranteed to support color, but can be reasonably expected to support a modern definition of monochrome which includes some bit depth of shades of grey that could easily be used to represent a wider palette of colors.

And even if I lose the argument about color, I do stand by my assertion that "monochrome" needs to be explicitly defined in either this document or the style guide if that is to remain the requirement. Using current I-D format as an example, monochrome is truly "black and white" or single-bit. Using what my "black and white" printer generates as an example, or what a first-gen e-ink display supports, I think we're talking about 4 or 8 bit (16-256 shades of grey) at the very least. Yes, this requires some additional definition of a supported color palette and a mapping from color to greyscale, but I disagree that this is so complex as to be avoided. In reality, it's already defined by the HTML standard: 16 initial "named" colors, plus another 130 named if we wanted to get slightly fancier, while still allowing us a nice easy way to limit the palette away from the 16M colors allowed by the HTML Hex color code range. By using this existing standard, we also are likely to be able to take advantage of existing mapping that allows monochrome devices to properly represent things that were originally intended to be displayed in color.

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