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.