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

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

Alice,

Summary: with one tiny additional change (an adjustment to the
Acknowledgments), I think we are, pending Murray's signoff,
done.  Details inline below.



--On Monday, January 22, 2024 14:00 -0800 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.)

Good.  And sorry for the confusion, please thank Jean for me. 
 
> 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").

For this document, fine.

With one exception, I think I'm finished with it.  That
exception is that the second paragraph of the second bullet in
the Acknowledgments includes "from people not listed above".
But Phil Pennock is listed above, so:

Old:
	from people not listed above that resulted in document
	changes were received from Amanda Baber (for IANA),
	Linda Dunbar, Paul Kyzivat, and Phil Pennock.

New: 
	from people not listed above that resulted in document
	changes were received from Amanda Baber (for IANA),
	Linda Dunbar, and Paul Kyzivat.

I once again regret that conventions have seemed to discourage
acknowledgments to you and your colleagues.  If that has
changed, I should be writing something because this document has
been considerably improved due to your efforts, a contribution
much greater than that of some who were explicitly listed.

Finally, reading through the draft one more time, other things
that might be improved occur to me but, both out of deference to
Ned's text and because we should get this done and move on, I am
suppressing those inclinations.

thanks again,
   john

 
> 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-param
>>>> et ers.xhtml#mail-parameters-2
>>>> 
>>> 
>> 
>> <rfc9422-20240119-draft.xml><rfc9422-20240119-draft.txt>
>