Re: [auth48] AUTH48: RFC-to-be 9422 <draft-freed-smtp-limits-07> for your review

[Alice Russo <[e-mail]>]

John,

Thank you for your careful replies; please see the follow-ups below.
The revised files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9422.html
  https://www.rfc-editor.org/authors/rfc9422.txt
  https://www.rfc-editor.org/authors/rfc9422.pdf
  https://www.rfc-editor.org/authors/rfc9422.xml

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9422-diff.html
  https://www.rfc-editor.org/authors/rfc9422-rfcdiff.html (side by side)

This diff file shows only the changes made during AUTH48 thus far:
  https://www.rfc-editor.org/authors/rfc9422-auth48diff.html
  https://www.rfc-editor.org/authors/rfc9422-auth48rfcdiff.html (side by side)

A- For LIMITS updates, please review and let us know any further changes. In particular, I'm not 100% sure about the removal of quotes in 'LIMITS EHLO (LHLO in LMTP) keyword' in Section 3.

B- Acknowledgments: Decided to leave "A lot of" as is. I see your point; seems sufficiently clear in this context. 

C- Sections 4.1 - 4.3: Updated to '"0" not allowed, six-digit maximum'.
I tried out the line break; however, with the indentation that comes with <dl>, this does not look good because the comment is not be under the first line.

A format option here is a sourcecode element in the XML file, as the value syntax is in ABNF. We've done this in Section 4.2 just so you can see how it looks; please let us know your preference, and we'll make them all match.  (The change is primarily in the HTML and PDF; the change in the text output is only a line break after "Value syntax:".) We prefer the simplicity of the output without the sourcecode element.

Side note: For any conclusion here, we'll be sending a mail to IANA to request the text in the registry be updated accordingly.

D- Reference style 
I've looked at 5321bis to see examples (e.g., "RFC 2181, Section 10.3 [32]"), but may not understand the implication of "references to Section numbers are part of the citation". If you want changes as follows or otherwise, please let us know.
  Current: Section 4.5.3.1.8 of SMTP [SMTP]
  Perhaps: RFC 5321, Section 4.5.3.1.8 [SMTP]


We will wait to hear from you again before continuing the publication process. 
This page shows the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9422

Thank you.
RFC Editor/ar

> On Jan 9, 2024, at 7:44 AM, John C Klensin <[e-mail]> wrote:
> 
> 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
> [e-mail] 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
>