Hi all,
On 18/10/2024 06:29, John C Klensin
wrote:
I tend to agree.As discussed in the earlier part of the review response, this is the second part, covering the "Nits" and "Matters of Personal Taste" sections of the review. --On Friday, October 11, 2024 23:56 -0400 Donald Eastlake <d3e3e3@xxxxxxxxx> wrote:... Nits ----General comment: I wrote this response one point at a time and think I got less patient with some of the suggestions as I went along. I suggest that someone (you, me, Murray, the IESG more formally) forward this note to the RPC along with the post-review version of the document. This is particularly important with the last two items in this list. Many of the suggestions below are stylistic matters and, for me at least, the RPC's stylistic preferences trump yours, mine now, and mine and that of a WGs in (for many of the cases) 2001.Section 1.1, 3rd paragraph: The words that occur to me immediately when I think of this feature of SMTP is "store and forward". Consider replacing the first sentence with "An important feature of SMTP is its ability to sequentially transport mail across a network multiple times, behavior usually referred to as "store and forward" or "SMTP mail relaying" (see Section 3.6).Three issues: (1) As I think I described in my earlier note, some SMTP systems do not accumulate all of an incoming message before opening a connection to send the message on. Those systems are not classical store and forward ones as I think that term is generally understood. (2) If you read the subsequent sentence, part of the point is traversal of multiple networks, not just multiple times across (or within) the same network. (3) The WG has generally been quite reluctant to change old text that has not been demonstrated, for a decade or two or more, to cause problems. Given the two previous issues, this case illustrates a core part of the reason which is the risk of inadvertently causing new errors or sources of confusion.
I saw this implemented in the latest posted draft.Section 1.2, 1st paragraph: Suggest adding a paragraph break between "... Appendix F." and "This document ..."Although I'd normally prefer to leave this sort of thing to the RPC, seems reasonable. Change made in working draft. They might, of course, change it back.Section 2.1, last paragraph, first line: "suggested" -> "discussed" Seems like more than a suggestion to me.I've changed this but it feels like the sort of editorial style issue that the RFC Series has traditionally left to author discretion.
As a participant I tend to agree that "carefully" is superfluous, but I don't think it causes any issues either. So I wouldn't lose sleep over this one way or another.Section 2.3.6: I think the word "carefully" should be deleted here as superfluous.I'm going to ask for comments from the WG on this one. It is decades-old text (see above) and I can imagine substantive reasons why it might have been felt necessary.
As a participant: I think including EXPN in the section name will improve the document. I think it would be helpful to implementors when searching for information on EXPN.Section 3.5.2: Name of section should include EXPN.While I can see your reasoning, that name (and even the section number) dates from RFC 2821. See above. WG?
Section 4.1.1: Suggest removing the parenthesis around the parenthetical. It seems like a fine top-level sentence and a reader might wonder why it is in parenthesis. For example, they might somehow think that it weakens the "SHOULD".I think I agree but, historically, RFC 2821 used a version of the sentence without the "SHOULD". RFC 5321 introduced the SHOULD (and retained the parentheses). That trailing white space really should (sic) not be there so maybe this is a weak "SHOULD". WG?
We can test whether there are any implementations of this, but I suspect not many.
If this is a weak SHOULD, do you suggest any changes?
Personally I am Ok with the text as is.
I read "required destination mailbox" as "not allowed to be empty, like empty return path in MAIL FROM". So I would leave it as is.Section 4.1.1.1, first 2 words: "These command" -> "EHLO and HELO"Unchanged since RFC 2821 and an editorial style matter.Section 4.1.1.3, 2nd paragraph: I think the word "required" should be deleted here as superfluous. It also reads a bit oddly.Unchanged since RFC 2821. And I'm unwilling to decide that is is superfluous given some very odd historical cases. WG?
I agree. "Trace field" is defined elsewhere in documents, so I think the text is good as is.Section 4.1.2, 2nd paragraph, page 46: There are peculiar extra spaces in the fourth line of this paragraph, at least in the .txt version. (I understand that extra white space is needed in the next to last line of the paragraph.)I cannot find anything in the XML that should have caused that. Punting to the RPC.Section 4.2.4.1, last sentence: delete parentheses.The parentheses are there because the section is about 502. I think they should come out only if the section were retitled "Reply Code 502 in Relation to 501 and Other Codes" or something like that.Section 4.4.1, first sentence: Use of "field" here feels wrong. A field is usually part of a line. Suggest using "line".Terms like "header field" and "trace field" are used for consistency with draft-ietf-emailcore-rfc5322bis and terminology in email dating back to before RFCs 821 and 822. In addition "Received:" Header Fields often (I dare say usually) span more than one line. I believe a change in terminology, especially if rfc5322bis were not changed, would be a sources of confusion, not clarity.
Preference level seems correct to me.Section 5.1, page 75, first paragraph: "... the SMTP server ..." -> "... an SMTP server ..."Given that the balance of the sentence, I think the phrase is about a specific server and "the" is correct. Refer to RPC.Section 5.1, page 75, 3rd paragraph: "... preference label," -> "... preference value," (They are numbers, not strings.)Actually, after reading the sentence several times, I think neither is correct and "preference level" was intended. Note "preference level" is used two sentences earlier. Change made; WG please check this.
[snip]Section 8.1.1.1: Delete occurrences of "Paragraph 2".RPC issue. Although I don't remember whether this particular one was discussed, there have been several iterations with them about citations and cross-references from this document.Sections 8.1.1.3 and 8.3: There are many references to "Paragraph 2, Item …" in these sections. The "Paragraph 2" seems superfluous extra words since the sections have only one numbered list in each of them and I would have said there is actually only one paragraph in each of these sections and the list of items is part of that paragraph.See above.
I agree. Thank you Donald for the thorough review!Thanks. Despite the many places where I disagree with the issues you identified and your suggestions for addressing them, I very much appreciate the careful and thoughtful review.
Best Regards,
Alexey
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
