Reviewer: Vijay Gurbani Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-emailcore-rfc5321bis-35 Reviewer: Vijay K. Gurbani Review Date: 2024-11-27 IETF LC End Date: 2024-10-10 IESG Telechat date: Not scheduled for a telechat This was an excellent I-D that encapsulates a lot of history and operational experience we have gathered with SMTP. It was fun, and indeed, a pleasure to read it! Summary: This I-D is ready with (minor) issues for publication as a Standard Track Document. Part 1 of the review was posted on Nov-21. For completeness, I am including the comments in Part 1 below; part 2 of the review is indicated by a "==== Part 2 ====" header below. Major issues: 0 Minor issues: 7 Nits/editorial comments: 7 (In the review below, I removed one nit from my Part 1 review, and this was the nit identified as [REMOVED] in the Nits section below. Minor issues: - Abstract: I am not sure what "other than strict" implies. Does it mean that the document also provides information on the use of SMTP for non-email related transport and delivery? If so, may be better to explicitly say so by perhaps a small example. - S1.2, second to last paragraph ("Section 2.3 provides ... "SMTP Server"."): Are there canonical definitions of "client" and "server"? We know that there are widely accepted definitions, but is there a normative IETF RFC that defines these terms? If so, we may want to include that. IMHO this is important because we use the temporal qualifier "current" in the paragraph; the issue is "current" with respect to what? Are these terms used as they have been historically (server provides a service at a known IP address and port, and client consumes that service by connecting to that IP address and port)? Or does IETF define the canonical meaning of these terms? - S2.3.1, last paragraph, sentence starting with "If the content conforms to other contemporary standards...": I find this sentence hard to understand; what is it that we are saying? Are we saying that we expect the content to be like other IETF standards where we have a number of headers (header-name COLON header-value), followed by a blank line (\r\n) followed by the data that consists the body? If so, then we should have references to the nebulous "other contemporary standards". As a developer, I would have no idea what I should be doing if the content DOES NOT conform to "other contemporary standards". - S4.1.1.1, second paragraph: I am curious ... if the information that helps identify the client was not widely supported, shouldn't we use a MUST NOT strength to discourage this behaviour from clients conformant to this specification? (The current normative strength is SHOULD NOT.) - S4.1.1.4, fourth paragraph: The specification states that "The SMTP model does not allow for partial failures at this point:", however, in the sixth paragraph starts with "The server must give special treatment to cases in which processing ... is only partially successful." I understand the intent of the fourth paragraph: the server sending a 250 OK takes responsibility of delivering the message to the recipients, and if it cannot, an "undeliverable mail" notification is sent (as per the sixth paragraph). But developers reading this may be a tad confused. Would it make sense to move the sixth paragraph to be under the current fourth paragraph, and start it with "Under certain circumstances, the server must give special treatment ... of the message." ==== Part 2 ==== - S4.3.1, last paragraph mentions "The table below". However, I do not see a table in that section... Nits: - Abstract: s/all or/all, or/ - S1.2: s/It obsoletes/This document obsoletes/ - S3.3, second paragraph: s/The latter terminates/The QUIT command terminates/ (Reason: former and latter are appropriate when you have two choices, here there are three.) - S4.1.1.9, out of curiosity, what is the use for the NOOP? Would it make sense to document why it is even there in SMTP? After all, this specification is written to clarify the original SMTP. ==== Part 2 ==== - S4.1.2: "reduction MUST NOT be applied" ==> This is cute :-) I do not know whether it was intentional to leave multiple spaces between "reduction" and "MUST NOT" (since we are talking about white space reduction). If it was intentional, no worries; but if not, then the white space can be reduced. - S4.5.1: "...the following minimum implementation MUST be provided by all receivers." Why the word "receivers" here? I would presume that all SMTP clients and servers (and intermediaries) will need to provide the commands listed here. As such, would anything materially change if we ended the sentence as "... the following minimum implementation MUST be provided by SMTP systems." - S6.2, third paragraph: s/the history of the network is/operational experience suggests/ [REMOVED] - S3.3: consider s/5yz reply/500-class response/ (Note: the '?yz' construct appears other places as well, so this may be too big a change. But just wanted to point it out for your consideration.) (Rationale: Upon further reading the I-D, it becomes clear that 5yz is baked into the protocol as 'y' and 'z' signify different information. So, I will like to take this nit out of consideration.) Thanks, - vijay -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
