As with the previous note, dropping issues on which Alexey and I agree and things that have been changed in rfc5321bis-32, retaining those that are still uncertain or in need of further action... As there, people who disagree with those conclusions or changes should respond to Alexey's note or, if more convenient, my original one, preferably dropping the SECDIR and Last Call lists. --On Monday, October 21, 2024 18:44 +0100 Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote: > Hi all, > > On 18/10/2024 06:29, John C Klensin wrote: >> 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 >>> ---- >... >>> 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 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. As chair, either tell me to move or or create ticket #??. >>> 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? > 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. I'm obviously not convinced that would not have some bad side effect even though I cannot identify any either. Ticket #?? >>> 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? While, conceptually, I think we both know what I meant by "weak SHOULD", BCP 14 does not identify such things, adding to my hesitancy to mess with this. > Personally I am Ok with the text as is. So am I. Ticket #?? >>> Section 4.1.1.1, first 2 words: "These command" -> "EHLO and HELO" >> Unchanged since RFC 2821 and an editorial style matter. Should I just drop this and move on or would you like to assign a ticket #?? >>> 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 read "required destination mailbox" as "not allowed to be empty, > like empty return path in MAIL FROM". So I would leave it as is. Agreed. Again, should I drop this and more on or do you think a ticket #?? is need to frame WG discussion. >... >>> 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. Two additional comments on this: (1) AFAICT, there is no 8.1.1.3. Was there something else? (2) Independent of that (and probably making it irrelevant), I discovered, or was reminded, when working through these issues for rfc5321bis-32 that these references are the text generated when using, in the XML, an <xref> to an anchor on a list item. Hence, if there is a problem, it is with the RFCXML vocabulary or xml2rfc implementation and should be taken up with RSWG or the Tools Team; it is not an issue specific to this document. >... -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
