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

[John C Klensin <[e-mail]>]

Alice,

Yes, by all means.  Sorry for not catching that myself.  And
thanks for the updated instructions to IANA as well.

   john


--On Monday, February 5, 2024 11:27 -0800 Alice Russo
<[e-mail]> wrote:

> 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.htm
>>>   l (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.h
>>>>> tml (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-par
>>>>>> amet ers.xhtml#mail-parameters-2
>>>>>> 
>>>>> 
>>>> 
>>>> <rfc9422-20240119-draft.xml><rfc9422-20240119-draft.txt>
>>> 
>> 
>