Skip to main content

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

Yes

Murray Kucherawy

No Objection

Deb Cooley
Erik Kline
Jim Guichard
John Scudder
Zaheduzzaman Sarker
Éric Vyncke

Note: This ballot was opened for revision 05 and is now closed.

Mahesh Jethanandani
(was No Objection) Yes
Comment (2024-03-31 for -05) Sent
Thank you for the document.

There are a few nits that would be nice to fix.

s/receive progress update/receive a progress update/
s/reach at the completion/reach after the completion/
s/keepalive with indication/keepalive with an indication/
s/command completed/command is completed/
s/relation with specific/relation to specific/
s/from commands output/from the command output/
Murray Kucherawy
Yes
Deb Cooley
No Objection
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Comment (2024-03-29 for -05) Not sent
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.
Jim Guichard
No Objection
John Scudder
No Objection
Orie Steele
No Objection
Comment (2024-03-28 for -05) Not sent
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.
Paul Wouters
No Objection
Comment (2024-04-03 for -05) Sent
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?
Roman Danyliw
No Objection
Comment (2024-04-02 for -05) Sent
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.
Warren Kumari
No Objection
Comment (2024-04-03 for -05) Not sent
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/\.//
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection