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

[Alice Russo <[e-mail]>]

Murray, 
Thanks for your reply. We have noted your approval on the AUTH48 page for this document (https://www.rfc-editor.org/auth48/rfc9422). 

John, 
Another question:  Is it OK to change to all-caps "MAIL Parameters" to match how it appears on the IANA page (https://www.iana.org/assignments/mail-parameters)?  We typically aim for the document to match the IANA page as closely as possible; my mistake for missing this earlier.

Section 7.2

OLD: The IANA has created a new registry in the Mail Parameters group for ...
NEW: The IANA has created a new registry in the "MAIL Parameters" group for ...

Thank you.
RFC Editor/ar

> On Feb 2, 2024, at 9:48 PM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> Alice and John,
> 
> Apologies, I didn't realize this was waiting on me.  Gmail is kind of bad at pointing out new stuff sometimes.
> 
> These changes are approved.
> 
> -MSK, ART AD
> 
> On Thu, Feb 1, 2024 at 10:10 AM Alice Russo <[e-mail]> wrote:
> Murray,
> This is a reminder that we await approval from you regarding the item below. I should have written "please review and let us know if you approve the changes in Section 3, 3.3, 3.5, and corresponding reference updates."
> 
> The files have been updated to show 'February 2024'; available from the same URLs (please refresh).
> 
> Thank you.
> RFC Editor/ar
> 
>> On Jan 22, 2024, at 2:00 PM, Alice Russo <[e-mail]> wrote:
>> 
>> Hi John, Murray (as AD),
>> 
>> * Murray, please review the changes in Section 3, 3.3, 3.5, and corresponding reference updates. For context, John wrote:
>>> I think the citation to a section of RFC 5321 in the
>>> introduction to Section 3 is normative (as is the citation at
>>> the end of Section 2) while the others are informative.  I have
>>> laid things out accordingly, but feel free to adjust.
>> 
>> 
>> Re:
>>> I have made the changes to the [RFCnnnnA] form, paralleling the
>>> precedent that Alexis found.
>> 
>> Thank you for sending the updated XML, John. (Actually, it was Jean that pointed out the usage in RFC 8753.) 
>> 
>> We are OK with moving forward with the current document, which references [RFC5321a],  [RFC5321b], and [RFC5321c]. As for changing to numbered citations, we decided to leave them as they are (i.e., symRefs="true").
>> 
>> The revised files are here (please refresh):
>> 
>>   https://www.rfc-editor.org/authors/rfc9422.txt
>>   https://www.rfc-editor.org/authors/rfc9422.pdf
>>   https://www.rfc-editor.org/authors/rfc9422.html
>>   https://www.rfc-editor.org/authors/rfc9422.xml
>> 
>> Only the most recent set of changes:
>>   https://www.rfc-editor.org/authors/rfc9422-lastdiff.html
>>   https://www.rfc-editor.org/authors/rfc9422-lastrfcdiff.html (side by side)
>> 
>> The set of changes made during AUTH48 state:
>>   https://www.rfc-editor.org/authors/rfc9422-auth48diff.html
>> 
>> 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)
>> 
>> Re:
>>> I also caught a typo and fixed it. 
>> 
>> Nice catch.
>> 
>> 
>> Re: A ("LIMITS" usage)
>>> I've concluded, pending Murray's input, that we
>>> should, with one exception in Section 3.1 that seemed
>>> particularly problematic, just leave it alone.
>> 
>> Ack.
>> 
>> 
>> Re: C (Sections 4.1 - 4.3)
>>> I have not changed it back in the attached XML.
>> 
>> We are in agreement about not using <sourcecode>; accordingly, the example (in Section 4.2) has been changed back.
>> 
>> Please let us know any further changes or if the document is approved for publication. 
>> 
>> Thank you.
>> RFC Editor/ar
>> 
>> 
>>> On Jan 19, 2024, at 4:19 PM, John C Klensin <[e-mail]> wrote:
>>> 
>>> Alice and others,
>>> 
>>> In the interest of not having this drag on further and
>>> especially after noticing that the section number citations in
>>> running code do not read smoothly and consistently either, I
>>> have made the changes to the [RFCnnnnA] form, paralleling the
>>> precedent that Alexis found.
>>> 
>>> I am blind-copying Alexis on this note as a contribution to the
>>> larger conversation but assume she does not want to get dragged
>>> into the details of this draft).   I've also made my comments on
>>> the "how to cite a section" issue as a top post; everything else
>>> is inline in your message to me.
>>> 
>>> Murray, see comment at the end of my response to "A-" below.
>>> Everything else is, IMO, routine editorial stuff or tied up with
>>> the citation discussion immediately below.
>>> 
>>> Having made the changes, it is clear that the current version of
>>> the RFCXML vocabulary is not friendly to that format.  First,
>>> one ends up with, e.g.,
>>>  Section 2.2, RFC 5321,
>>> rather than 
>>>  RFC 5321 Section 2.2
>>> which I think would be better.  If you (collectively) agree,
>>> then <refcontent> may need some attributes similar to what now
>>> appear in <xref> to fine-tune ordering of information or a new
>>> element is needed to put text after <seriesInfo> and before
>>> date.  In addition, if it were possible to use <xref> as an
>>> element of <reference> it would eliminate that problem, make
>>> life much easier for you as well as authors, and even, with
>>> appropriate tooling, allow
>>> 
>>> [RFC5321a] SMTP, _ibid._, Section 2.2
>>> 
>>> which is, IMO, really what we want here (plus or minus brackets
>>> around "SMTP"). It would also make editing a rfc9422bis to
>>> reflect rfc5321bis and _its_ section numbers much easier.   It
>>> you wanted to include a <target> URL with the Section
>>> references, it would also make having that point to a section
>>> more clear and more obvious.
>>> 
>>> I think the citation to a section of RFC 5321 in the
>>> introduction to Section 3 is normative (as is the citation at
>>> the end of Section 2) while the others are informative.  I have
>>> laid things out accordingly, but feel free to adjust.
>>> 
>>> I have left comments in the XML that act as reminders of the
>>> original version of the citations in running text (all including
>>> "[JcK]".  You should remove them.
>>> 
>>> There are some additional comments about details in "D-", below.
>>> 
>>> Finally on this subject, if citation anchors in the form of
>>> "[RFC1234a]" offend your sense of aesthetics (they don't do much
>>> for me either), feel free to change them to numbered citations,
>>> e.g., "[1]", which is what I have done in rfc5321bis and its
>>> predecessors for other reasons.  In some respects, using "SMTP"
>>> as an anchor rather that "RFC5321" is a step in the same
>>> direction.
>>> 
>>> Aside: From my point of view, the very complex set of attributes
>>> for <xref> that are designed to enable section numbers and so on
>>> represent a process failure -- the conversation I'm trying to
>>> stimulate about what to do about such things should have come
>>> first and, if those attributes without changes to
>>> <reference>push authors in that direction, their presence is
>>> very close to a policy decision. 
>>> 
>>> I also caught a typo and fixed it. 
>>> 
>>> The good (I hope) news is that, unless there are disagreements
>>> that affect the document with some of the above or changes noted
>>> in the XML, we are probably done with the attached version.  One
>>> warning: I've looked rather closely at the text output
>>> (attached) but only glanced at the HTML and PDF prior to making
>>> my last set of changes (i.e., I've changed the XML and
>>> regenerated the text about a half-dozen times, but have
>>> regenerated the HTML and PDF only once.  I trust that, if there
>>> were major issues with either of those versions, you would have
>>> spotted, or will spot, them.
>>> 
>>> best,
>>>  john
>>> 
>>> 
>>> 
>>> --On Thursday, January 11, 2024 14:26 -0800 Alice Russo
>>> <[e-mail]> wrote:
>>> 
>>>> 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.
>>> 
>>> Good catch.  That got fairly messed up.  Have rewritten.   I
>>> have no idea whether "LHLO for LMTP" or "LHLO in LMTP" are
>>> better although my "ear" prefers the former.  Feel free to
>>> change if you have a different preference.
>>> 
>>> I did catch one place where I think I disagree with your
>>> choices, "fixed" it, and then started wondering if I/we really
>>> want to open another can of worms (and further trespass on Ned's
>>> text).  When we sorted out the case distinctions, I was assuming
>>> that there were two uses of the term in the document: the
>>> extension name and running text.  There is actually a
>>> distinction around the latter, were some uses are terms of art
>>> and others are just text.  So for example, when the text says in
>>> Section 3.6 "Servers return updated limits ...", it really means
>>> "Servers [MAY/SHOULD/MUST] return a new LIMIT response that MAY
>>> have different parameter values".  However, after looking at
>>> other instances, I've concluded, pending Murray's input, that we
>>> should, with one exception in Section 3.1 that seemed
>>> particularly problematic, just leave it alone.  If anyone
>>> disagrees, speak up.  Otherwise, if problems are encountered in
>>> practice, I guess I'm on the hook for 9422bis.
>>> 
>>> 
>>>> B- Acknowledgments: Decided to leave "A lot of" as is. I see
>>>> your point; seems sufficiently clear in this context. 
>>> 
>>> Ack.
>>> 
>>>> 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.
>>> 
>>> I am fine with this; would probably feel different if there were
>>> multiple or very long comments.  For future reference should
>>> this come up with a more complex case, I've made rfc5321bis do
>>> what I wanted with, e.g.,
>>> 
>>>             <dt>ehlo-param     =</dt>
>>>             <dd>
>>>            1*(%d33-126)<br/>
>>>              ; any CHAR excluding &lt;SP&gt; and all<br/>
>>>              ; control characters (US-ASCII 0-31 and 127<br/>
>>>              ; inclusive)
>>>         </dd>
>>> 
>>> If that strikes you as painful and ugly, especially because it
>>> is using <br/> to control what should be line wrapping, and
>>> hence works well in text with 12pt fixed-pitch fonts but less
>>> well elsewhere, welcome to the club.   The only good solution I
>>> can imagine would look a little like
>>> 
>>>    <dd>
>>>      ....
>>>      <syntaxComment> 
>>> 			any CHAR excluding &lt;SP&gt; and all control
>>>         characters (US-ASCII 0-31 and 
>>>         127 inclusive)</syntaxComment>
>>> 
>>> but, as you know, I'm enough of an advocate of Goldfarb's
>>> original thinking that I get irritated every time I see RFCXML
>>> used to force specific formatting, especially when I am forced
>>> to do it myself.
>>> 
>>> 
>>>> 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.
>>> 
>>> I have a slight preference for the original.   I prefer the
>>> simplicity (and compactness) too.  Some of my preference, too,
>>> is not very strong and is mostly philosophical, interacting with
>>> the document content markup versus metadata markup issues as
>>> well as getting a tad closer than I like to format markup.  Rant
>>> on request, but lets go back to the non-sourcecode form.
>>> 
>>> I have not changed it back in the attached XML.
>>> 
>>>> Side note: For any conclusion here, we'll be sending a mail to
>>>> IANA to request the text in the registry be updated
>>>> accordingly.
>>> 
>>> Ok
>>> 
>>>> 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.
>>> 
>>> See a few other notes but, especially, the material at the top
>>> of this one, but your examples may reinforce my preference for
>>> moving that materials out of the citation (and adjoining text)
>>> and into the reference.  Using your examples...
>>> 
>>>> Current: Section 4.5.3.1.8 of SMTP [SMTP]
>>>> Perhaps: RFC 5321, Section 4.5.3.1.8 [SMTP]
>>> 
>>> If forced to pick between these two, I'd pick the first.  Closer
>>> to what I was taught in English Writing 101 and at least the
>>> citation anchor seems to be attached to SMTP although not the
>>> full clause.   For the second, "[SMTP]"
>>> appears to be attached to the Section, not the full statement,
>>> and hence should probably be more like my "[RFC5321c]" in the
>>> attached draft.
>>> 
>>> Actually, there is a hybrid solution, which I've seen in some
>>> journals.  One could argue that I actually used the hybrid in
>>> the revised first sentence of Section 3, where, without the
>>> section number, the sentence just does not feel right to me.
>>> For the more general case, it would look more like either of
>>> your strings above, but with "[RFC5321c]" (or, more likely)
>>> "[99]", instead of "[SMTP]".  But, pragmatically, you don't want
>>> to go there without enough changes in the markup to permit the
>>> part in the text to be automagically generated from the
>>> <reference> when the <xref> citation goes in.  You'd certainly
>>> want "ibid" there too.  But that would get very close to the
>>> aspirations for content markup at the time the GML/SGML papers
>>> first appeared.
>>> 
>>> 
>>>> 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-paramet
>>>>> ers.xhtml#mail-parameters-2
>>>>> 
>>>> 
>>> 
>>> <rfc9422-20240119-draft.xml><rfc9422-20240119-draft.txt>
>> 
>