IMAP4 Response Code for Command Progress Notifications.
draft-ietf-extra-imap-inprogress-06

Feel free to ignore or use the suggestions as you find opportune.

I found the abstract reading slightly unnatural. Maybe change slightly the styling:

[existing]
   This document defines a new IMAP untagged response code,
   "INPROGRESS", that provides structured numeric progress status
   indication for long-running commands.

[proposed]
   This document defines a new IMAP untagged response code,
   "INPROGRESS", designed to provide a structured, numeric 
   progress status indication for commands that take a long time 
   to execute by the server.

Thanks to Scott Hollenbeck for the ARTART review.

https://datatracker.ietf.org/doc/review-ietf-extra-imap-inprogress-04-artart-lc-hollenbeck-2024-02-08/

It does not appear that his suggestion was applied, I believe applying it could improve the document.

I see no Operational Considerations section, so I wanted to confirm that it is not expected that clients
not implementing this talking to servers that do implement this would somehow cause a failure. I assume
as this is part of the "OK" response that valid clients would not break on receiving "OK INPROGRESS",
but has any testing be done on this?

Thank you to Meral Shirazipour for the GENART review.

** Section 4.  Editorial.
   If the server
   elects to send notifications, it is RECOMMENDED that these are sent
   every 10..15 seconds.

Is the “..” notation intended to convey “every 10 to 15 seconds”.  Maybe “10-15 seconds”.

** Section 4.
   PROGRESS and GOAL SHOULD be counts of the kind of item being
   processed - in most cases, messages counts.  If that is not possible,
   the counts SHOULD be percentages, with progress varying between 0 and
   99 and goal fixed at 100.

What happens if neither a message count or percentage is used?  The first sentence states that it is possible that progress is not expressed as a message count.  The second sentence seems to cover a non-mandatory alternative in the form of percentages.  Should the second sentence be a MUST?

** Section 6.
   The details of the response code are not expected to disclose any
   information that isn't currently available from commands output.  The
   progress details could be obtained anyway by a series of sending
   commands with different workloads - either by constructing data sets
   or searching in the appropriate way into them.

It might be more than command outputs.  A client might try to infer server load by the timing of command execution.  INPROGRESS shouldn’t leak more than is possible with other commands.

Thank you for writing this document -- it seems like it will provide a helpful feature to users. Also much thanks to Dan Romascanu for the helpful OpsDir review (https://datatracker.ietf.org/doc/review-ietf-extra-imap-inprogress-04-opsdir-lc-romascanu-2024-02-12/)

I had a few nits to offer, to help further improve the document:
1: The server can provide the progress notifications details with different degrees of completeness:
s/notifications/notification/

2:  [5 second later]
s/second/seconds/

3: If that is not possible, the counts SHOULD be percentages, with progress varying between 0 and 99 and goal fixed at 100.
"and goal fixed at 100" sounds clumsy, but I don't really know how to fix it -- perhaps just "the goal fixed at 100."?

4: "as that would mean the command completed and that the proper tagged response should be emitted instead."
s/the command completed/the command has completed/ - I think?
s/and that the/and so the/ -- I think?

5: "The details of the response code are not expected to disclose any information that isn't currently available from commands output. "
s/commands output/the command's output/

6: "The progress details could be obtained anyway by a series of sending commands with different workloads - either by constructing data sets or searching in the appropriate way into them."
I don't really know how to fix this, but "searching in the appropriate way into them." doesn't really seem to make much sense to me. Perhaps just s/into them// ?

7: "like GOAL = 0, GOAL/VALUE < 0, GOAL/VALUE >= 2^32. (these are not possible"
s/\.//