[ Due to the length of the document, this is a partial review that I am sending to the list manually. I will complete the review next week and will file that review through the Gen-ART tool so the system can consider the review completed. Apologies for breaking it up as such, but wanted to give as much heads up to the authors as I can. ]
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-21 IETF LC End Date: 2024-10-10 IESG Telechat date: Not scheduled for a telechat Summary: The I-D is ready with (minor) issues. Part 1 of the review is below. Part 2 will be posted next week. Major issues: 0 Minor issues: 6 (so far, may be updated) Nits/editorial comments: 5 (so far, may be updated) Minor - 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 for 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." - S4.1.1.4, fourth paragraph: "the receiver MUST send an OK reply." -- Should a status code be specified here at all? ("250 OK"?) 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.) - S3.3: consider s/5yz reply/500-class response/ (Note: the '?yz' construct appears in other places as well, so this may be too big a change. But just wanted to point it out for your consideration.) - 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. Thanks, - vijay
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
