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

From: [email-masked]
Date: Mon, 04 Apr 2022 09:30:14 -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-03.txt
	Pages           : 56
	Date            : 2022-04-04

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/archive/id/draft-ietf-emailcore-rfc5322bis-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5322bis-03

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Pete Resnick <[email-masked]>
Date: Mon, 04 Apr 2022 12:03:41 -0500

The significant change here is reverting from "visible" to "printable" 
in sections 2.2 and 2.2.1, making it clear that "printable" does not 
include space, and then using VCHAR throughout the rest of the document.

There's one other choice, but I'm not sure it's worth it: If I were to 
say "graphic characters (section 4.3 of [ANSI.X3-4.1986])", that would 
be closest to what we're looking for (see 
http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf). That said, it's 
not perfect: Section 4.2 of that document says that the space character 
"is interpreted both as a graphic character and as a control character". 
If you think using "graphic" instead of "printable" is significantly 
better, do say.

pr

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

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2022 15:36:05 -0400

>If you think using "graphic" instead of "printable" is significantly 

I'd leave it alone.  It's horrifying enough that #'&%)!@*? is a valid
header field name.  The other changes look fine.

Not suggesting a change here but do you remember why it refers to
ANSI X3.4-1986 rather than RFC 20 which is a copy of X3.4-1968?  The
differences between the two are insiginificant.

R's,
John

PS: I wonder how many message parsers do the right think (i.e., nothing)
with unmatched quotes in header field names.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 04 Apr 2022 14:43:06 -0500

On 4 Apr 2022, at 14:36, John Levine wrote:

> header field name.

I'm personally always in favor of "principle of least change".

> The other changes look fine.

Ack.

> differences between the two are insiginificant.

No mention of it in the archives. I'm guessing because it was not 
labeled as "Standard" back then.

> with unmatched quotes in header field names.

Heh. A fun thing to test, I suppose.

pr

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Apr 2022 00:39:02 -0400

--On Monday, April 4, 2022 12:03 -0500 Pete Resnick
<resnick=[email-masked]> wrote:

> The significant change here is reverting from "visible" to
> "printable" in sections 2.2 and 2.2.1, making it clear that
> "printable" does not include space, and then using VCHAR
> throughout the rest of the document.

IMO, just right.
 
> There's one other choice, but I'm not sure it's worth it: If I
> were to say "graphic characters (section 4.3 of
> [ANSI.X3-4.1986])", that would be closest to what we're
> looking for (see
> http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf). That
> said, it's not perfect: Section 4.2 of that document says that
> the space character "is interpreted both as a graphic
> character and as a control character". If you think using
> "graphic" instead of "printable" is significantly better, do
> say.

No.  I think that just gets more more tangled up in knots.  If
you want to be clear about what characters are allowed, either
enumerate them or use VCHAR (which enumerates them). 

Two suggestions, one of which I've suggested earlier and that I
notice John Levine picked up in a separate note (but I _am_
suggesting a change):

(1) Reference RFC 20 either in addition to or instead of
X3.4-1986.  Your supposition about "standard" might be correct
or it might have been that the reference to NIC 7104 might have
been better at the time 822 was written.  Dave might remember
but I can't imagine it makes much difference now.  Today, the
main point is that, unless one has a handy library that keeps
copies of old standards around in case someone might want to do
a comparison (I do; I imagine that you and John L., probably do;
but, in general...) copies of X3.4-1986 (and X3.4-1968) are
really hard to find.

(2) In any event, if you are going to reference X3.4-1986 at
all, please get rid of the anchor "[ANSI.X3-4.1986]" and replace
it with, e.g., "[ASCII]" (like 2822).  I don't note where the
"[ANSI.X3-4.1986]" notation came from, but it seems designed to
confuse some people and annoy others.

The other advantage of using RFC 20 is that there actually are
differences (although probably not significant for the purposes
of this document) between the 1968 version and the the 1986 one
(which is now formally designed as "ANSI INCITS 4-1986[R2017]".
Unless you find the relationships among 
   USAS X3.4-1968
   ANSI X3.4-1986 and 
   ANSI INCITS 4-1986[R2017]
and a few other forms amusing and un-confusing, that is another
reason to cite RFC 20 and be done with it, with the citation
anchor as [RFC20] or [ASCII] as you prefer as long as "RFC 20"
is in the body of the reference.

   john

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 5 Apr 2022 13:43:20 +0900

In general, I'd prefer [US-ASCII] to just [ASCII] for the anchor.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Apr 2022 01:39:47 -0400

> In general, I'd prefer [US-ASCII] to just [ASCII] for the

Martin, for the anchor, I really don't care as long as it isn't
complicated and confusing like "[ANSI.X3-4.1986]".   I prefer
[ASCII] or [RFC20] to [US-ASCII], but not by much.  As you have
probably noticed, I completely gave up on similar debates with
2821 and 5321 and went to numeric anchors.

I'm much more concerned about the term used to refer to the CCS
in running text.

But, out of curiosity, why do you prefer [US-ASCII]?  AFAICT, it
does not convey any extra information.  In particular, it is not
as if "ASCII" is ambiguous because there are things like
JP-ASCII, CH-ASCII, GB-ASCII, or other such things floating
around.  There aren't.

   john

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 5 Apr 2022 15:44:12 +0900

Hello John,

On 2022-04-05 14:39, John C Klensin wrote:
> But, out of curiosity, why do you prefer [US-ASCII]?

My short answer is
https://www.iana.org/assignments/character-sets/character-sets.xhtml
(first entry).

The US-ASCII label is firmly and widely established.

> AFAICT, it

Yes, there are no such labels. And the ISO 646 variants for which they 
might have been used aren't in wide use anymore. But as far as I have 
heard from people with experience in this area that goes back farther 
than mine, these ISO 646 variants were the reason the label US-ASCII was 
introduced.

Regards,   Martin.