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.
> 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.
> 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.
> 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?
> 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?
> 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.
> 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.
> 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.
> Matters of Personal Taste
> -------------------------
>
> Section 2.3.10, last line: "both sides of them" -> "both of their
> sides".
>
> Section 4.2.4.2, 2nd line: "follows." -> "follows:"
RPC for both of the above.
> I dislike the square bracketed number style of references, as
> opposed to [RFCxxxx]. It's longer and, as long as the RFCs in the
> References section are in numeric order, which they always should
> be, not significantly faster or easier to look up.
At least two reasons for that here. One is historical precedent
going back to RFC 821 and earlier. The other is more substantive,
which is that some of the references point to parts of documents
rather than whole documents and to materials that are not numbered
RFCs, e.g., individual IANA registries and errata lists. For all
three of those cases, the obvious simplicity of "[RFCxxxx]" breaks
down.
In addition, since we switched to separate "Normative" and
"Informative" reference sections, RFCs may appear in order in the
separate groups, but not in order overall. For a typical document
with perhaps a dozen references, that probably makes no difference,
but this document contains 65 numbered references.
Bottom line: this has been an editor's preference issue for decades
with precedents dating, IIR, into the 1970s. This editor prefers
the form used and notes that, for some of the non-RFC references, the
anchors used in the XML would require careful scrutiny for
appropriateness and hence would add significant extra work.
> I would replace all references to ANSI X3.4-1968 with references to
> RFC 20.
The problem is that they are not identical. There have been a few
rather extensive discussion on the subject and what to do about them.
The discussion if further complicated by the fact that there are two
versions of RFC 20 with, I recall some subtle inconsistencies
introduced in the newer one. The citations as they now stand are
correct; trying to change them would require careful examination of
each to verify that the change could be made and what additional or
changed text would be needed. It is hard to believe that would be
worth the effort.
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.
john
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
