Hi John, On Tue, Oct 22, 2024, at 5:45 AM, John C Klensin wrote: > 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. Good point, I didn't spot that. I think we will have to discuss this on the mailing list and/or in Dublin. >>>> 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 #?? https://github.com/ietf-wg-emailcore/emailcore/issues/101 >>... > >>>> 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 #?? https://github.com/ietf-wg-emailcore/emailcore/issues/102 >>... >>>> 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 #?? https://github.com/ietf-wg-emailcore/emailcore/issues/103 Best Regards, Alexey -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
