Opened 9 years ago

Closed 9 years ago

#254 closed defect (fixed)

Wes George review of rfcformatreq

Reported by:… Owned by: draft-iab-rfcformatreq@…
Priority: major Milestone: milestone1
Component: draft-iab-rfcformatreq Version: 1.0
Severity: Active WG Document Keywords:


Section 2.1 - it seems odd to not specifically mention readability here. While several of the more specific items can be considered aspects of how one defines readability, I think noting that as an explicit goal and reason for making changes to the format may be helpful.

I also have a comment on one specific section of 3.2:

“Graphics may include ASCII art and SVG line art. Color will

not be accepted; RFCs must correctly display in monochrome to
allow for monochrome displays, black-and-white printing, and
Accessibility issues.”

I strongly suggest a change to both the wording and the requirement here to clarify that this only applies to the canonical format, as it currently reads as if color will never be supported, even in other derivative formats.

Generally, what I read from the discussion of the canonical form is that this is the lowest common denominator format – readable on the largest variety of devices, and the baseline from which other presentations (optimized for a given device or display) are derived, likely using metadata to augment the display as appropriate.
This says to me that 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.
In other words, color can and SHOULD be used as an augmentation to improve legibility and understandability, but MUST NOT be required for completeness. Similar to the fact that we are requiring alternative text for images for accessibility, this is a simple matter of requiring drawings to support monochrome display while still allowing them to use color when available, probably through the use of alternate color definitions for greyscale or monochrome (or perhaps simply assuming that most monochrome/greyscale devices have figured out how to represent color adequately given the fact that virtually all UI design uses it).

I would also note that there is a considerable difference between true monochrome and greyscale, and I think it’s worth seriously considering which we truly mean and why when we define formatting requirements. I’m not convinced that the former is something that we still need to optimize for. When we’re discussing printout, "black and white" is a bit of a misnomer. Every printer type that isn’t an antique (and many that are) is capable of generating at least a rudimentary 2-4 bit greyscale, especially if it is also capable of displaying SVG art. The same is true with things like non-color e-ink screens. The only “device” in wide use that is still using a truly monochrome display is command line interfaces (VTY/TTY, SSH, etc), and even then, similarly to printers, anything that isn’t an antique is capable of displaying more than one bit color. Most of those text-based interfaces are being used on modern machines via emulator clients that support a much wider variety of display colors, so I don’t think that it’s a high bar to at least assume greyscale rather than true monochrome. Since this has the potential to be very limiting, it is worth being very crisp in our definitions of what we’re actually allowing when we say “monochrome”.

Change History (6)

comment:1 Changed 9 years ago by bernard_aboba@…

  • Component changed from /home/ietf/id/draft-iab-rfcformatreq-00.txt to draft-iab-rfc-format
  • Milestone set to milestone1
  • Owner changed from draft-iab-rfcformatreq@… to draft-iab-rfc-format@…
  • Severity changed from - to Active WG Document
  • Version set to 1.0

comment:2 Changed 9 years ago by bernard_aboba@…

  • Owner changed from draft-iab-rfc-format@… to draft-iab-rfcformatreq@…

comment:3 Changed 9 years ago by bernard_aboba@…

  • Component changed from draft-iab-rfc-format to draft-iab-rfcformatreq

comment:4 Changed 9 years ago by n.brownlee@…

Heather's response:

Thank you for your comments.

Regarding section 2.1, that is the start of a capture of arguments not a
listing of the requirements. I think we could argue the point that
readbility is at the base of some of those arguments, but since it
wasn't a specific focus, I did not capture this requirement here.
Readability is part of the foundation of the requirements that are
recorded in section 3: "There are several components of the original
format requirements that must be retained to ensure the ongoing
continuity, reliability and readability of the Series"

Regarding section 3.2 and your comment about color, while derivative
works beyond the RFC Editor may include color, it will not be included
in RFC documents. I think color represents a wealth of challenges that
would require more time, tools, and resources than we have and is
something I do not want to pursue for the foreseeable future.

comment:5 Changed 9 years ago by hlflanagan@…

The particular requirement involving graphics has been modified as follows:

  • Graphics may include ASCII art and a more complex form to be

defined, such as SVG line art. Color and grayscale will not
be accepted; RFCs must correctly display in monochromatic
black-and-white to allow for monochrome displays, black-and-white
printing, and support for physical and age-related disabilities.

comment:6 Changed 9 years ago by hlflanagan@…

  • Resolution set to fixed
  • Status changed from new to closed

One further modification: reference added for SVG.

Closing ticket.

Note: See TracTickets for help on using tickets.