I think we're waiting for approvals from the remaining three authors here. -MSK
On Mon, Feb 10, 2025 at 10:12 AM Alice Russo <aru...@staff.rfc-editor.org> wrote: > Alexey, > > Thank you for your reply. > > Re: #4, you wrote: > > I have slight preference to listing both in the Abstract. Is that Ok? > > > Yes. Updated "(RFC 3501/RFC 9051)" to "(RFCs 3501 and 9051)". Please > review. > > Re: #8, we went with the prose explanation (rather than notation) because > this isn't a pseudocode or note-like section. > > > The revised files are here (please refresh): > https://www.rfc-editor.org/authors/rfc9738.html > https://www.rfc-editor.org/authors/rfc9738.txt > https://www.rfc-editor.org/authors/rfc9738.pdf > https://www.rfc-editor.org/authors/rfc9738.xml > > This diff file shows all changes from the approved I-D: > https://www.rfc-editor.org/authors/rfc9738-diff.html > https://www.rfc-editor.org/authors/rfc9738-rfcdiff.html (side by side) > > This diff file shows the changes made during AUTH48 thus far: > https://www.rfc-editor.org/authors/rfc9738-auth48diff.html > https://www.rfc-editor.org/authors/rfc9738-auth48rfcdiff.html (side by > side) > > We will wait to hear from you again and from your coauthors > before continuing the publication process. This page shows > the AUTH48 status of your document: > https://www.rfc-editor.org/auth48/rfc9738 > > Thank you. > RFC Editor/ar > > > On Feb 4, 2025, at 10:30 AM, Alexey Melnikov <alexey.melni...@isode.com> > wrote: > > > > Dear RFC Editor, > > > > > > On 04/02/2025 06:25, rfc-edi...@rfc-editor.org wrote: > >> Authors, > >> > >> While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the XML file. > >> > >> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > >> the title) for use on > >> https://www.rfc-editor.org/search > >> . --> > >> > >> > >> 2) <!--[rfced] The acknowledgments mentions the editor of this document; > >> however, none of the authors has been listed as the editor (meaning > >> "Ed." would appear after their name). Should one person (or more) be > >> listed as the editor(s) of this document? > >> (If not, this sentence will be changed to "The authors of this > >> document".) > >> > > This is a very reasonable suggestion. > > > >> > >> Original: > >> Editor of this document would like to thank the following ... > >> --> > >> > >> > >> 3) <!--[rfced] Abstract: Does the updated text convey the intended > >> meaning? The idea is to not rely on "/" for meaning and to clarify how > >> the first set of commands (FETCH, SEARCH, STORE, COPY, MOVE) relates > >> to the second set (APPEND, UID EXPUNGE). > >> > >> Original: > >> The MESSAGELIMIT extension of the Internet Message Access Protocol > >> (RFC 3501/RFC 9051) allows servers to announce a limit on the number > >> of messages that can be processed in a single > >> FETCH/SEARCH/STORE/COPY/MOVE (or their UID variants), APPEND or UID > >> EXPUNGE command. > >> > >> Current: > >> The MESSAGELIMIT extension of the Internet Message Access Protocol > >> (RFC 3501/RFC 9051) allows servers to announce a limit on the number > >> of messages that can be processed in a single FETCH, SEARCH, STORE, > >> COPY, or MOVE command (or their UID variants), or in a single APPEND > >> or UID EXPUNGE command. > >> > >> [And similarly in the Introduction] > >> > > This is fine. > >> > >> --> > >> > >> > >> 4) <!-- [rfced] May the first sentences of the Abstract and > >> Introduction be updated to simply point to RFC 9051 rather than > >> RFC 3501, as RFC 9501 is the current version of IMAP? > >> > >> Because there is already an explicit statement in Section 1 > >> that the extension is compatible with "both IMAP4rev1 [RFC3501] > >> and IMAP4rev2 [RFC9051]", please consider whether in other > >> instances throughout the document the reference to RFC 3501 > >> may be updated to RFC 9051. > >> > >> Abstract > >> > >> Original: > >> The MESSAGELIMIT extension of the Internet Message Access Protocol > >> (RFC 3501/RFC 9051) allows ... > >> > >> Perhaps: > >> The MESSAGELIMIT extension of the Internet Message Access Protocol > >> (RFC 9051) allows ... > >> > > I have slight preference to listing both in the Abstract. Is that Ok? > >> > >> Introduction > >> > >> Original: > >> This document defines an extension to the Internet Message Access > >> Protocol [RFC3501] for announcing ... > >> > >> Perhaps: > >> This document defines an extension to the Internet Message Access > >> Protocol [RFC9051] for announcing ... > >> --> > >> > > The above is fine, as long as you keep the following sentence as is: > > This extension is compatible with both > > IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. > > > > > > > >> 5) <!--[rfced] Section 3.1: May this text be updated as follows? > >> Should "EXPUNGE" be "UID EXPUNGE" here? > >> > > Actually both are covered by this section. > > > >> > >> Original: > >> 3.1. Returning limits on the number of messages processed in a single > >> SEARCH/FETCH/STORE/COPY/MOVE/APPEND/EXPUNGE command > >> > >> Perhaps Option A: > >> 3.1. Returning Limits on the Number of Messages Processed in a Single > >> Command (SEARCH, FETCH, STORE, COPY, MOVE, APPEND, EXPUNGE) > >> > >> or Option B (to simplify): > >> 3.1. Returning Limits on the Number of Messages Processed in a Single > >> Command > >> > > I think I like Option B. > >> > >> --> > >> > >> > >> 6) <!--[rfced] FYI, line breaks have been added in order to fit the > >> line-width restrictions of the text output. Please let us know if > >> changes are needed. > >> --> > >> > >> > >> 7) <!--[rfced] This document mentions the "message set parameter" twice. > >> Will this be clear to the reader? > >> > > I think so, as there is only one parameter that matches the description. > >> We do not see mention of this term > >> in RFC 9051 or other RFCs. > >> > >> Current: > >> (For the MOVE command, the message set parameter needs to be ... > >> [...] > >> (For the STORE command, the message set parameter also needs to be ... > >> --> > >> > >> > >> 8) <!--[rfced] The first item uses notation; the second uses words. > >> May this be updated as follows for consistency? > >> > >> Original: > >> Operations on a mailbox that has <= N messages are not affected. > >> > >> In a mailbox with more than N messages: > >> > >> Suggested: > >> * Operations are not affected on a mailbox that has N messages > >> or fewer. > >> > >> * In a mailbox with more than N messages: > >> > >> Or (if you prefer notation): > >> * Operations on a mailbox that has <= N messages are not affected. > >> > >> * In a mailbox with > N messages: > >> > > Either alternative is fine. The latter? > >> > >> --> > >> > >> > >> 9) <!-- [rfced] Please review each artwork element and let us know if > any should > >> be marked as sourcecode (or another element) instead. > >> > >> FYI, we updated artwork to sourcecode type="abnf" in Section 5. Please > confirm > >> that this is accurate. > >> > > That is correct. > >> > >> The current list of preferred values for "type" is available at > >> > >> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types> > >> . > >> If the current list does not contain an applicable type, feel free to > >> suggest additions for consideration. Note that it is also acceptable > >> to leave the "type" attribute not set. > >> --> > >> > >> > >> 10) <!-- [rfced] Please review the "Inclusive Language" portion of the > online > >> Style Guide > >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >> > >> and let us know if any changes are needed. Updates of this nature > typically > >> result in more precise language, which is helpful for readers. > >> > >> Note that our script did not flag any words in particular, but this > should > >> still be reviewed as a best practice. > >> --> > >> > >> > >> 11) <!--[rfced] FYI, we have removed the index from this document, > >> as an index with a single entry does not seem useful. > >> --> > >> > > Ok! > > > > Best Regards, > > > > Alexey > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
