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

From: [email-masked]
Date: Mon, 29 Mar 2021 11:14:10 -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-01.txt
	Pages           : 56
	Date            : 2021-03-29

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-01.html

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

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: Jeremy Harris <[email-masked]>
Date: Tue, 30 Mar 2021 19:31:56 +0100

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

I suggest it is time that Section 4 was deleted.
-- 
Cheers,
   Jeremy

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Mar 2021 11:55:35 -0700

> I suggest it is time that Section 4 was deleted.

Presumably, that requires that there be no significant, continuing use 
of those constructs.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Pete Resnick <[email-masked]>
Date: Tue, 30 Mar 2021 14:00:08 -0500

> I suggest it is time that Section 4 was deleted.

Whatever I might think about the merits of that idea, I am pretty sure 
there is no way to do that within the charter of the WG:

---
This working group will conduct a limited review and revision to the 
base
email specifications, and will publish new versions of these documents 
at
Internet Standard status, per RFC 6410. The limited review is restricted
to corrections and clarifications only, with a strong emphasis on 
keeping
these minimal and avoiding broader changes to terminology or document
organization. In addition to processing existing, verified errata and
errata marked as "held for document update", the WG may address
newly-offered errata. However, no new protocol extensions or amendments
will be considered for inclusion into 5321bis and 5322bis documents,
unless they are already published as IETF Stream RFCs and are at
sufficient maturity level to move to Internet Standard.

---

pr

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

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2021 18:47:59 -0400

It appears that Pete Resnick  <[email-masked]> said:
>-=-=-=-=-=-

How about saying they MAY be accepted rather than MUST?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Mar 2021 15:53:52 -0700

> How about saying they MAY be accepted rather than MUST?

What is the evidence that deployed support for those constructs has 
reduced enough to mean that a failure to implement them will not 
significantly injure interoperability?

d/

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2021 20:42:00 -0400

> What is the evidence that deployed support for those constructs has reduced 
> enough to mean that a failure to implement them will not significantly injure 
> interoperability?

Good question.  I've looked at the relatively small amount of mail I 
receive and don't see things like text tiem zones or spaces before the 
colon in a header but I would be nice if someone bigger had some data.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Hector Santos <[email-masked]>
Date: Wed, 31 Mar 2021 10:36:09 -0400

> https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-01.html

Hi Peter, thanks for your work.

I don't see anything outstanding from the diff that stood out.

A fresh reading of this draft, I found myself stopping at 2.2.1 and 
2.2.2, wasting time trying to find examples of an unstructured and 
structured header field.

I think it would really go "easier" (smoother flow) on the reader 
(especially for new mail engineer) if there was a simple example shown 
for an unstructured and a structured header field for section 2.2.1 
and 2.2.2 respectively.

There is an example for a Long Header Field in section 2.2.3. So 
perhaps the idea of a simple example of the two sections preceded it 
would not be out of line.  It will better help to understand the 
subtle difference between unstructured and structured header fields 
and also provide a heads up on the finer details for structured header 
fields for the rest of the document.

Is the "Subject" header field of an unstructured or structured header 
field?

Is it unstructured because its data is taken "as is" without 
additional parsing?

Do optional header field comments only applied to structured header 
fields?

For example, the subject line:

    Subject: [Emailcore] I-D Action: 
draft-ietf-emailcore-rfc5322bis-01.txt  (comment, treat as meta?)

Mail apps, i.e. perhaps a gateway, importer or even an MUA, could 
potentially be doing some parsing of the Subject field.

To me, the bottom line, the key difference is that structured header 
fields require additional parsing of the header field body before it 
can used.

I know many of the cogs will say "Nahh, its fine. No examples 
needed."   I suggest consider the new reader, the newer SMTP 
developer.  This is big document with many subtle details. So in my 
tech reading opinion, "Being Specific Is Terrific" always helps to 
provide readers a faster understanding of key tech concepts.

The suggestion is to simple examples in these sections, 2.2.1 and 
2.2.2, trying to avoid getting into lengthy details about the examples.

2.2.1 Unstructured Header Field Bodies

...

Example of an unstructured header field bodies:

      Subject: support-case-id: 20210401.120011.003

While this may appear structured to the application developer, it is 
not for SMTP operations.

2.2.2 Structured Header Field Bodies

...

Examples of a structured header field bodies:

      Date: Mon, 29 Mar 2021 11:14:10 -0700
      Message-id: <[email-masked]>
      Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10)
           for [email-masked]; Mon, 29 Mar 2021 13:14:16 -0500

Thanks

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

---

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Mar 2021 15:59:36 -0500

> I don't see anything outstanding from the diff that stood out.

Excellent. Thanks.

> 2.2.2, wasting time trying to find examples of an unstructured and 

Do note that this is the explanatory section of the document, so I think 
this falls into the category of "nice to have", but as I stated to the 
previous comment, I don't think this is really in scope for this limited 
update. FWIW, I don't think there would be any harm in adding additional 
examples in the AS document. But as always, if the chairs make the call 
that this falls within scope and there is WG consensus to do so, glad to 
come up with an example or two (or steal yours).

pr