Dropping portions of Alexey's notes on which he and I agree or no special additional action need be taken. Anyone who disagrees with the issues on which Alexey and I agree or where text has already been changed in rfc5321bis-32 should respond to Alexey's note or start a new thread (preferably dropping the Last Call and SECDIR lists from the distribution). Items identifies with "Ticket #??" should either be assigned ticket numbers or someone should explain to me why they are not needed. Todd, since Alexey is on holiday, can you take care of that? More inline below... thanks, john --On Monday, October 21, 2024 15:19 +0100 Alexey Melnikov <aamelnikov@xxxxxxxxxxx> wrote: >... >>> Section 2.3.5, last paragraph (before the final two bullet >>> points): The first sentence of this paragraph is of questionable >>> grammar and, in any case, extremely hard to parse. Assuming I >>> have parsed it correctly, how about "Unless further restricted in >>> this document, domain names used in SMTP are names that can be >>> resolved to MX or address (A or AAAA) RRs (see also Section 5), >>> or to CNAME RRs that can be resolved to an MX or address RR." >> >> Good catch. This sentence resulted from too much patching (my >> notes show at least four partial rewrites since its predecessor >> first went into the document) and should have been caught and >> rewritten earlier. Let me consider your proposed new text, but I >> will rewrite this somehow in the working version. Unless >> instructed to the contrary, that version will appear before the >> IESG starts its deliberations. If it seems controversial, I'll >> follow up on this part of your review. > > I created a new issue for this: > <https://github.com/ietf-wg-emailcore/emailcore/issues/98>. > > John, I am happy for you to propose an alternative or just > implement Donald's suggestion above. Donald's fix appears to me to prohibit a CNAME RR that points to another CNAME RR. That, in turn, interacts with the DNSDIR review discussion on that subject. So I think I need to await further discussion and directions. >>> Section 2.3.12, first sentence: Appears to have missing text >>> and/or have grammatical errors and is hard to parse. How about >>> something like : "This document distinguishes between two >>> concepts: (1) an "SMTP session (aka "mail session") that starts >>> when a connection is made between client and server and ends when >>> than connection terminates", and (2) a "mail transaction that is >>> started and terminated by particular SMTP commands." >> >> Another good catch with the original being more complicated by a >> wording (near-typographical) error. I think even your proposed fix >> may be too complicated and obscure (although far better than the >> original). How about: >> >> 'This document distinguishes between an "SMTP session" and a >> "mail transaction". An SMTP session, often called a "mail >> session", starts when a connection is made between client and >> server, ending when that connection is terminated. A "mail >> transaction" is started and terminated by particular >> commands, most often MAIL and RSET or QUIT (the latter also >> instructs the server to close the SMTP session).' > > Speaking as a participant: this looks reasonable to me. > > New ticket > <https://github.com/ietf-wg-emailcore/emailcore/issues/99>. Tentatively incorporated in working version of -33. >... >>> Section 4.1.4, page 49, 3rd paragraph: This "MAIL MUST NOT be >>> sent" text seems confusing at a minimum. To most readers MAIL is >>> "being sent" with every RCPT command, with the DATA command, and >>> with every new line of mail content. Please re-word it so it's >>> something about "initiating" the sending of mail or the like. >> >> This is much like several cases where the WG decided to not change >> the text because the same wording (in this case, with the exception >> of removing discussion of SEND, SOML, and SAML) has been present >> since RFC 2821 and no actual issues with interoperability or even >> confusion have been demonstrated in more than 23 years. I'm open >> to suggested text and discussion in the WG, but I fear that any >> improvements would be subject to confusion on other points. As I >> reread it, I could see changing "MAIL MUST NOT be sent" to "message >> content MUST NOT be sent". Would that help? (Question addressed >> to the WG and community, not just Donald). > Actually, I think this changes the meaning. I read the original > sentence as > > MAIL FROM command MUST NOT be sent if a mail transaction is > already open ... > > I.e. that this is prohibition on SMTP clients to reset a > transaction with another MAIL FROM. > > The above suggests that this is confusing enough, so needs to be > clarified. Ticket #?? >... >>> Section 4.2, page 51, first complete paragraph: For the IETF, what >>> is the difference between a Standard and a Standards-Track >>> specification? It seems like bad practice to put IANA assignment >>> criterion in the middle of body text like this. >> >> To the first question, IIR, back when we had a fantasy about the >> (then) three-level Standards process being actively used, those >> levels were "Proposed Standard", "Draft Standard", and "Standard", >> with an expectation that the distinction would be taken seriously. >> The preference for "Internet Standard" to refer to the latter came >> much later. I'd like instructions from the WG or some sort of >> community consensus, but I am open to >> (i) Leaving the text alone >> (ii) Putting "Internet" in front, i.e., making that "new >> Internet Standards or Standards-Track specifications" >> (iii) Dropping "Standards or". >> >> However, for (iii), note that many in the IETF, including some IESG >> decisions, have argued or assumed that BCPs are really >> standards-track documents. Because of that, the current text is >> possibly deliberately ambiguous and we should be careful what we >> wish for because an alternative to it could require a very >> careful, and possibly contentious, revision. > > I don't remember anybody interpreting a BCP as a Standards-Track, > so I personally prefer (iii). Murray should comment if he disagrees. >... >>> Section 4.2.2: OK, but what are these "Functional Groups"? Some >>> sort of subheadings (not necessarily part of the hierarchical >>> numbering) are needed. >> >> These groupings, and the use of that terminology without a further >> breakdown or description or subheadings, come straight out of RFC >> 821. That is more than 40 years with no evidence that it has been >> the source of a problem. It might be that the difference in >> formatting between RFCs 821 (and 2821) and their successors is >> helpful. The formatting in the current document is identical to >> that in RFC 5321 (2821 followed the 821 model but was probably >> prepared using xml2rfc version 1 (i.e., the RFC 2629 version) and >> translated to nroff). I have figured out how to make xml2rfc >> restore that earlier layout but, if we want to do that, the WG is >> going to need to very carefully review the new groupings since >> there are codes that do not appear in RFC 821 or even in RFC 2821 >> and the ordering of some of the existing codes was changed (even >> between 2821 and 5321). > > I think the latest version of the draft restored the grouping. It restored groupings but, given new codes and rearrangement of existing ones, others need to confirm that is what is wanted. Ticket #?? >... >>> Section 8.3, item (9): Appears to have an open technical question >>> that should be resolved. >> >> Whoops. No idea how that slipped through except that the WG has >> sometimes been moving too slowly or intermittently. I've made a >> note in the working draft. WG?? > > Speaking as one of the editors of RFC 6710, I think the only change > needed is to rename "SMTP PRIORITY extension Priority Assignment > Policy" sub-registry to "SMTP MT-PRIORITY extension Priority > Assignment Policy". Ticket #?? >... -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
