--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/emailcore-review.txt	Wed Feb 05 15:56:31 2025 +0000
@@ -0,0 +1,97 @@
+Document: draft-ietf-emailcore-rfc5321bis-40
+Intended RFC status: Proposed Standard
+Review type: artart - Last Call review
+Reviewer: Henry S. Thompson
+Review Date: 2025-02-05
+Result: Ready with minor issues
+
+*Summary*
+
+This is a non-trivial update to a major standard
+
+*Substantive points*
+
+*Minor points*
+
+8.1.4:
+
+  I had to do some hunting to understand what was being referred to by
+  'Strings' in the last paragraph.  Maybe expand this slightly to read
+
+   As new clauses are defined, they may, in principle, specify
+   creation of separate registries (specific to them) if the Strings
+   allowed by the syntax summary consist of reserved terms or keywords
+   rather than less restricted strings.
+
+D:
+  I find the use of the word 'deprecated' in this appendix confusing
+  and, it seems to me, inconsistent.
+
+  In the first para., we find
+
+   "A few features of RFC 821 have proven to be problematic and SHOULD
+    NOT be used in Internet mail"
+
+  So far so good, in my experience of how 'deprecated' is used.
+
+  And in D.1 we find
+
+   "Its use is deprecated; SMTP systems SHOULD NOT use it unless ..."
+
+  Also OK by me.
+
+  But in D.4 we find
+
+   "It is deprecated and MUST NOT be used."
+
+  In my experience that amounts to a contradiction.  Deprecation, I
+  thought, is meant for something which the spec. currently allows,
+  but is considered to be outdated and probably SHOULD NOT be
+  used. Support in future versions cannot be counted on.
+
+  Since the ABNF doesn't allow this, and it hasn't been supported for
+  a long time, it's way past time for deprecation, in my opinion.  At
+  most a note back in 4.1.3 saying that #-literals haven't made sense
+  for a long time and MUST NOT be used.
+
+  Similarly in D.5 we find
+
+   "It is deprecated and MUST NOT be used."
+
+  Since the ABNF no longer allows anything other than 4-digit years,
+  deprecation is not appropriate IMO.  It would make sense to me iff
+  back in 4.4.5 wording was added saying it SHOULD NOT be produced,
+  but MAY be accepted for backward-compatibility for the time being.
+
+*Nits*
+
+8.1.1.3 (1):
+  "EHLO Keyword: The textual name of the SMTP service extension"
+  Needs a full-stop.
+
+8.1.3:
+  '"Additional Registered Clauses (keyword and
+    values)'  Needs a close-quote.
+
+8.3.3.2:
+  '"Additional verbs", "MAIL/RCPT Parameter Values" ...' reads
+  awkwardly to me, I'd prefer
+  '"Additional verbs" and "MAIL/RCPT Parameter Values" ...'
+
+8.3.3.3:
+  'Note: Implementation support for VRFY is required in servers but
+           its listing in the EHLO response is optional".'
+  Either spurious close-quote or missing open-quote.
+
+9:
+  "chetti contributed" and the long note that precedes it.
+  Would "chetti [sic] contributed ..." be a possible compromise?  [If
+  not, nothing needs to be said, I certainly don't want to require any
+  further discussion of what has already consumed more time than it
+  deserves.]
+
+C.1:
+  "by Smith at host bar.com, and to Jones ..."
+  Reads aqkwardly to me. Just
+  "by Smith at host bar.com to Jones ..."
+  seems OK to me.