Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-00.txt

From: [email-masked]
Date: Tue, 06 Oct 2020 10:28:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Revision of core Email specifications WG of the IETF.

        Title           : Internet Message Format
        Author          : Peter W. Resnick
	Filename        : draft-ietf-emailcore-rfc5322bis-00.txt
	Pages           : 56
	Date            : 2020-10-06

Abstract:
   This document specifies the Internet Message Format (IMF), a syntax
   for text messages that are sent between computer users, within the
   framework of "electronic mail" messages.  This specification is a
   revision of Request For Comments (RFC) 5322, itself a revision of
   Request For Comments (RFC) 2822, all of which supersede Request For
   Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
   Messages", updating it to reflect current practice and incorporating
   incremental changes that were specified in other RFCs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5322bis/

There is also an HTML version available at:
https://www.ietf.org/id/draft-ietf-emailcore-rfc5322bis-00.html

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Hector Santos <[email-masked]>
Date: Wed, 07 Oct 2020 10:17:43 -0400

On 10/6/2020 1:28 PM, [email-masked] wrote:>
> 	Filename        : draft-ietf-emailcore-rfc5322bis-00.txt

Thanks Peter for your work with RFC5322bis.

I have allocated some review time for the RFC5322bis and RFC5321bis 
drafts. Some quick notes with my initial read of RFC5322bis.

1) IMF is a 20 yr+ technology with millions of operations and 
countless thousands of people who have some level of technical 
relationship with it. I am not advocating any big change but I think a 
summary section "Minimum Requirements" section would be very useful to 
technical readers and implementators already familiar with SMTP and 
IMF and seek only a summary outline.  If you search for words like 
requirements, minimum, not much there.  Search for "require" and you 
get closer to the 3.6. Field Definitions table which reads at a 
minimum, the Date: and From: are required to have one only one field 
instance. I may also suggest it make help to make a compatibility note 
here that previous specs, namely, RFC822 required the "To: or CC:" 
field and some receiver MAY add the To: at reception which matches the 
RFC5321 RCPT TO: field entered during the transport.

2) Line Limits

I think section "2.1.1. Line Length Limits", when read thoroughly and 
with some technical experience, explains the difference between the 
998 and 78 character lines.  But for a newer person, you have to pause 
to think about it.  Maybe using terms like physical or protocol vs 
display and indicate device implementation examples can help:

Protocol Line limit: MUST be 998 or less in transport and storage.

Display Line limit: For text-based terminal display compatibility, 
consider 78 characters displays. For GUI-based displays, wider display 
capabilities are available.  For mobile devices, smaller screen widths 
are a challenge for MUA developers since 78 characters may still be 
too wide.

3) Printable vs Visible

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" <tm> software and eyeballs.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 07 Oct 2020 11:56:16 -0500

> drafts. Some quick notes with my initial read of RFC5322bis.

I appreciate your kind words, and thanks for the review.

> RFC5321 RCPT TO: field entered during the transport.

I'd suggest that this kind of "advice to implementers" and other such 
explanation is really best suited to the AS document. As a general rule, 
we don't do "conformance requirements" in the IETF (though we do see it 
on occasion), but we do like to tell people how best to use a technical 
specification in their implementation, and that kind of info is 
well-suited for an AS. (Note that I'm using AS in the RFC 2026 section 
3.2 sense, which is a bit different than what is commonly meant by 
"applicability statement".)

> are a challenge for MUA developers since 78 characters may still be 

This is one where I feel like people seemed to have gotten this right 
given the current text, so I don't think we should change the document 
unless we believe that people have messed this up. We can always add 
some explanatory text to the AS. I think lots of things in the "helpful 
advice to new folks" could work well in there.

> Friendly Interface" <tm> software and eyeballs.

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.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2020 16:46:18 -0400

>	Filename        : draft-ietf-emailcore-rfc5322bis-00.txt

In the interest of moving things along, I see a question about
whether we should change the "fields" ABNF per erratum 2950.

That one's easy: no. The author of the erratum misunderstands how ABNF
works.  In particular there is no promise that ABNF will produce a
unique parse for any valid string, only that it will match every valid string.

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Oct 2020 19:07:27 -0400

--On Wednesday, October 7, 2020 11:56 -0500 Pete Resnick
<[email-masked]> wrote:

>> 3) Printable vs Visible
>> 
>> 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 
> 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.

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.

   john

[1] I wonder if "whitespace" is appropriate any more.  Is there
such a thing as "blackspace" (or "brownspace", "redspace",
"yellowspace", or "greenspace") and does its existence or not
make one or the other inappropriate?

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Oct 2020 10:34:52 -0400

> at least partway down that path.

(I must stress this is just input bits for synergism).

My philosophy, having written at least 5-6 MUAs since the 80s;

1) What is important is that field data is #1 "readable." Iow, whether 
carbon or silicon, it is interpreted and understood the same way. 
There are number of times that a print or visible character is not 
readable.  It may be understood by all silicons, but maybe not by all 
carbons. I can see where the former would be the focus when only 
considering the BIS work for MTA and MDA (port 25, non-auth), but not 
MSA (port 587, auth), the Transport and the IMF data. But consider, I 
don't think our MTAs and MDAs are performing OCR with the "visible" 
US-ASCII field data to determine their value. But even with screen 
readers, it needs to be "readable" US-ASCII first in order to 
electronically perform text to speech.

2) SFI "Speech Friendly Interfacing" <tm> was always a *strong* and 
never neglected consideration for my MUA work. There are important W3C 
Web Accessibility Initiative (WAI) resources at 
https://www.w3.org/WAI/ to help with modern SFI/WAI design 
considerations. RFC5322bis should consider an "Awareness" section on 
this topic, perhaps highlighting the key RFC5322bis fields that SHOULD 
be SFI/WAI compatible, obviously the main mail headers (From, to, 
date, subject) that are normally "visible", i.e. displayed but not 
always readable.

For me, imeo, using "Printable" was better than the new "Visible" in 
bis but when considered for correctness, I would think "readable" is 
the key intention for both automation and human eyeballs.

I agree, this is not something to waste time a lot of time on, but i 
don't think 'visible" would be quite correct for a modern 2020 version 
of RFC5322BIS codification. I agree with Klensin in this regard.

> make one or the other inappropriate?

For my product lines, I have penciled in new documentation and 
reference guide work to clean up terms like "white/black list" 
terminologies in the mail system.  RFC5322Bis does not need to worry 
about these common mail filtering terms, nor mail filtering in general.

For WhiteSpace, it is something to consider, fun discussion on 
alternatives, but how much change? Tough one.

I think 'whitespace" isn't related to a color but just relates to two 
specific characters that produce a "visible" and "printable" blank 
space.  Consider when reading mail in Dark Mode or any other fore/back 
ground text color profile, the "blank" space could have a white, black 
green, yellow, blue, etc, background color. So maybe the alternative 
to whitespace is "blank space?"  Tough one.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 11 Oct 2020 11:06:53 +0200

On Fri 09/Oct/2020 16:34:52 +0200 Hector Santos wrote:
> [...]
> I think 'whitespace" isn't related to a color but just relates to two specific 
> characters that produce a "visible" and "printable" blank space.  Consider when 
> reading mail in Dark Mode or any other fore/back ground text color profile, the 
> "blank" space could have a white, black green, yellow, blue, etc, background 
> color. So maybe the alternative to whitespace is "blank space?"  Tough one.

Oh Gosh...  Could we please stick to well established terms without trying to 
be overly correct, especially since it is obvious that no racist meaning is 
involved?   Thanks.

BTW, a production rule in "Command Argument Syntax" (Section 4.1.2 of 
rfc5321bis) has a "blackslash".  As an exception, that may be fixed...

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Sun, 11 Oct 2020 11:06:39 -0400

On 10/11/2020 5:06 AM, Alessandro Vesely wrote:
>> I think 'whitespace" isn't related to a color but just relates to
>> two specific characters that produce a "visible" and "printable"
>> blank space.  Consider when reading mail in Dark Mode or any other
>> fore/back ground text color profile, the "blank" space could have a
>> white, black green, yellow, blue, etc, background color. So maybe
>> the alternative to whitespace is "blank space?"  Tough one.
>
>
> Oh Gosh...  Could we please stick to well established terms without
> trying to be overly correct, especially since it is obvious that no
> racist meaning is involved?   Thanks.

Thanks? I get the point but lets realize it is this exact position 
that is considered problematic. It is not currently the general 
sentiment to just "ignore" as many in the industry are aware of the 
sensitive nature of such technical terms and have or planning to do 
address such terms like black/white listing, master/slave.

https://en.wikipedia.org/wiki/Blacklisting#Computing

That said, I do believe RFC5322bis and RFC5321bis are ok in this case.
"WhiteSpace" is not a filtering concept. I don't think it needs to change.

> rfc5321bis) has a "blackslash".  As an exception, that may be fixed...

For Klensin...

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Oct 2020 14:04:41 -0400

--On Sunday, October 11, 2020 11:06 +0200 Alessandro Vesely
<[email-masked]> wrote:

>>> [1] I wonder if "whitespace" is appropriate any more.  Is
>>> there such a thing as "blackspace" (or "brownspace",
>>> "redspace", "yellowspace", or "greenspace") and does its
>>> existence or not make one or the other inappropriate?
>> 
>> [...]
>> 
>> I think 'whitespace" isn't related to a color but just
>> relates to two specific  characters that produce a "visible"
>> and "printable" blank space.  Consider when  reading mail in
>> Dark Mode or any other fore/back ground text color profile,
>> the  "blank" space could have a white, black green, yellow,
>> blue, etc, background  color. So maybe the alternative to
>> whitespace is "blank space?"  Tough one.
 
> Oh Gosh...  Could we please stick to well established terms
> without trying to be overly correct, especially since it is
> obvious that no racist meaning is involved?   Thanks.

Sorry... I had intended my comment to be humorous, cynical, or
worse, not to take us down a path in which the seriously
considered making changes.  For better or worse, "whitespace" is
very well-established term of art and trying to change it in
this one document would have consequences far more severe than
any damage I can imagine.  If we were to go down that path, we
would also have the opportunity to debate whether U+2422 or
U+2423 should be treated as space charcaters.  Or, we we really
wanted to talk about "black" and "white" we could discuss the
status of U+25A0 and U+25A1.  I think even starting to discuss
such things leads rapidly to insanity.  Without speaking for
others, I'm got little extra sanity to spare.

> BTW, a production rule in "Command Argument Syntax" (Section
> 4.1.2 of rfc5321bis) has a "blackslash".  As an exception,
> that may be fixed...

Arggh.  Simple typographical error.  I can't even guess why it
got past me, past the RFC Editor, and past everyone who has read
this document over the years.  In any event, fixed in the
working copy of 5321bis -- I do not intend to re-port just for
that issue unless the WG Chairs tell me to do so, but it will be
corrected in the next version to be posted.  Thanks for the
careful reading.

  john