Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-smtp-limits-07> for your review
John C Klensin <john-ietf@jck.com> Tue, 09 January 2024 15:45 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A076C14F6FC; Tue, 9 Jan 2024 07:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60vO3Em0hOFK; Tue, 9 Jan 2024 07:45:13 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F4BC48E0C7; Tue, 9 Jan 2024 07:44:28 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1rNEHC-000JG5-PO; Tue, 09 Jan 2024 10:44:26 -0500
Date: Tue, 09 Jan 2024 10:44:21 -0500
From: John C Klensin <john-ietf@jck.com>
To: rfc-editor@rfc-editor.org
cc: superuser@gmail.com, auth48archive@rfc-editor.org
Message-ID: <8B5031F1A7B9BFE6E03BC7D8@PSB>
In-Reply-To: <20240109070859.359DF143F5A4@rfcpa.amsl.com>
References: <20240109070859.359DF143F5A4@rfcpa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/ugifRt7Hb8BOrvDehCm7Yggd1C8>
Subject: Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-smtp-limits-07> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jan 2024 15:45:17 -0000
Hi. I will try to go carefully through the document later today but, to answer the questions below.... --On Monday, January 8, 2024 23:08 -0800 rfc-editor@rfc-editor.org wrote: > John, > > While reviewing this document during AUTH48, please resolve > (as necessary) the following questions, which are also in the > XML file. > > 1) <!--[rfced] Limits vs. LIMITS > > Section 3 states: > The name of the extension is "Limits". Servers > implementing this extension advertise an additional > "LIMITS" EHLO (LHLO in LMTP) keyword. > > "Limits" is used several times (abstract, introduction, etc.). > Should the document title be updated, or is it preferable to > let "LIMITS" remain in that location? For comparison: > > Document title: > The LIMITS SMTP Service Extension > > Section 3 title: > The "Limits" SMTP Extension > --> At least most of this difference is either the result of Ned writing at different times or my editing subsequent to his passing being inconsistent. If Murray feels strongly about this, I will defer to him, but the IANA registry for SMTP extensions [1] shows extension names. If we take that as guidance, the document title is correct, the Section 3 title should be identical (upper case, no quotes) and other instances should be upper case and no quotes when they are referring to the extension name and lower case (no quotes and no leading capital "L") when they are talking about limits or limit values rather than the extension. If it works for you, I'd prefer that you go through and make those changes and let me check them afterwards. While Ned and I probably knew what we intended, if the intention is not clear to you, it probably implies a sentence that should be flagged and rewritten. > 2) <!--[rfced] Regarding your note about using "(deceased)", > an update since our reply in November: We recommend not using > the organization element in this manner. (We plan to update > the web portion of the style guide accordingly.) > > We suggest removing "(deceased)", as the information is > already included in the Acknowledgments of this document. > (This would be simliar to how it was handled in RFC 9360.) > Please let us know if this is acceptable. --> Not only acceptable but, IMO, just right. The only reason you are seeing "(deceased)" was that XML2RFC, at least at the time, was insisting on contact information and the Internet Drafts submission process did not allow the Secretariat to override that. In that context, "deceased" was the closest I could get to explaining that sending messages to Ned would be useless at best and potentially upsetting to his family. So, yes, drop it and drop any address or other contact information for him along with it. And, please fix the style manual to cover this sort of situation. If XML2RFC is unfriendly to the idea, I hope you will have better success than I did at getting it fixed. > 3) <!--[rfced] FYI, we inserted the word "an" before "entire > transaction". Please review whether that is the intended > meaning. > > Original: > Pipelining allows entire transaction to be sent without > checking responses and in some cases it may be possible to > send multiple transactions. > > Current: > Pipelining allows an entire transaction to be sent without > checking responses, and in some cases it may be possible > to send multiple transactions. --> Yes, absolutely. Apologies for not catching it sooner; I obviously did not review portions of Ned's text that seemed ok and about which no questions were raised closely enough. > 4) <!--[rfced] FYI, regarding the Acknowledgments, we have > changed the format of the "two parts" from subsections to > list items. Please let us know if you prefer otherwise. > --> I think this is strictly a stylist matter and will therefore defer to you. Neither subsections nor titled bullet items seem right to me, but those are all of the options that I think we have. Which one is less bad is a matter of taste. In looking at it, I notice another matter of taste that I had noticed before and ignored. The first line of Ned's Acknowledgments section started "A lot of". Over the years, I've found myself liking that phrasing less and less, especially remembering that I hung around a few jewelers and silversmiths who thought "lot" was a weight measure, not a quantity one, as a child. So, had I written it, I hope I would have gone back and changed it to "many". But that was Ned's text which I was trying to preserve as much as possible, so I let it go. If you have a preference, let's discuss. best, john [1] https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-2
- [auth48] AUTH48: RFC-to-be 9422 <draft-freed-smtp… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… John C Klensin
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… Alice Russo
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… John C Klensin
- [auth48] [AD] Re: AUTH48: RFC-to-be 9422 <draft-f… Alice Russo
- Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9422 <dra… John C Klensin
- Re: [auth48] [AD] AUTH48: RFC-to-be 9422 <draft-f… Alice Russo
- Re: [auth48] [AD] AUTH48: RFC-to-be 9422 <draft-f… Alice Russo
- Re: [auth48] [AD] AUTH48: RFC-to-be 9422 <draft-f… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… John C Klensin
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… Alice Russo
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… John C Klensin
- Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-… Alice Russo