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