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

["Murray S. Kucherawy" <[e-mail]>]

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>
>
>
>
>