ietf-svn-bot
commented
3 years ago @alexey.melnikov@isode.com commented
Pete Resnick has changed "printable" to "visible", but this reopened some debate.
The OpenGroup document referenced uses “graph” instead of “visible”.
Hector Santos:
I noticed the change from "printable" to "visible" US-ASCII characters in various sections. What's the key difference, the key idea with this change? Is the idea is that we are not encouraging print outs? What about the Visually Impaired? Why even have this attribute? Imo, it should be taking for granted that its need to be "readable" US-ASCII characters understood by all devices, printers, SFI "Speech Friendly Interface"
Pete Resnick: This actually comes from erratum 4692, where it was pointed out that the normal definition of "printable character" includes whitespace, which is not what we wanted to represent in those terminals. RFC 5234 uses the term "visible" (see the definition of VCHAR) for all of the non-whitespace printable characters, so I went with that. I take your point about the term being potentially problematic, but it is the current technical terminology in use. I defer to others as to whether we want to address this.
John Klensin:
FWIW, and being fairly sure I don't want to get into the middle of this, the terms typically used in the coded character set and computer-based typography literature are:
-
printable character (which, as you point out, usually includes spacing characters [1] (for ASCII, SP, HT, and sometimes VT, CR, and/or LF but, once one escapes the ASCII repertoire, things get much more complicated))
-
graphic character (or maybe character component) (no spacing characters/code points, even zero-width ones).
"visible character" is, AFAIK, an invention of RFC 2234 and it (and 4234 and 5234) all say "visible (printing) characters" and do so in a comment, not a normative definition. That does nothing to strengthen the case for "visible" even if one believes that "printing" or "printable" are wrong. Hence, and given the above, describing it as the "current technical terminology in use" is something of a stretch.
While I think we are agreed that we don't want to go down the path toward incorporating the specifications for non-ASCII addresses or headers in 5321bis/ 5322bis (although I think we should discuss the possible appropriateness of some informative references), I think we should avoid making any changes to 5321 or 5322 that would either require adjustments in RFC 6530-6531 or associated documents or make them more confusing, at least without strong justification. I don't know whether "visible" would, but note that there seems to be some interest in narrowing the permitted code points in mailbox local-parts (which interacts a bit with the question of quoted strings there) and, if we start refining those rules, we may have to go at least partway down that path.
aamelnikov
owner:resnick@episteme.nettype_defect| by alexey.melnikov@isode.comNoted by Oleg Andriyanov:
Section 3.2.4 says:
qtext = %d33 / ; Printable US-ASCII %d35-91 / ; characters not including %d93-126 / ; "\" or the quote character obs-qtext
According to the Open Group's definition of the "print" class of characters in a locale 1, the SPACE character (%d32) is printable as well. So either it should be included in the "qtext" definition or the comment should state explicitly that it is excluded from "qtext" along with backslash and double quote.
----- Verifier (Barry Leiba) notes -----
There are many places in the document that refer to "printable US-ASCII characters", and it's clear from the context of them that SPACE was not included there. This issue does need to be looked at when we revise this document to advance it to Internet Standard.
Issue migrated from trac:37 at 2022-01-31 12:36:39 +0000