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
