[rfc-i] Wes George review of rfcformatreq

Bernard Aboba bernard.aboba at gmail.com
Thu Dec 27 11:21:24 PST 2012



-------- Original Message --------
Subject: [IAB] [IAB Trac] #254: Wes George review of rfcformatreq
From: IAB issue tracker <trac+iab at trac.tools.ietf.org>
To: draft-iab-rfcformatreq at tools.ietf.org,wesley.george at twcable.com
CC: iab at ietf.org

#254: Wes George review of rfcformatreq

 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”.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-iab-
  wesley.george at twcable.com          |  rfcformatreq at tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  /home/ietf/id/draft-     |    Version:
  iab-rfcformatreq-00.txt            |   Keywords:
 Severity:  -                        |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/iab/trac/ticket/254>
IAB Trac <http://tools.ietf.org/group/iab/trac/>



More information about the rfc-interest mailing list