IMAP REPLACE Extension
RFC 8508

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

Alvaro Retana No Objection

Benjamin Kaduk No Objection

Comment (2018-10-23 for -02)
Section 1

(RFC 8174 provides an updated version of the BCP 14 boilerplate that can be
used instead of the RFC 2119 boilerplate.)

Section 3.5

   Unlike the APPEND command which is valid in the authenticated state,
   the REPLACE and UID REPLACE commands MUST only be valid in the
   selected state.  This difference from APPEND is necessary since
   REPLACE operates on message sequence numbers.

The stated justification applies only to REPLACE.  What is the
justification for disallowing UID REPLACE from the authenticated state?

Section 4.3

   (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS
   specification means that the client first receives an EXPUNGE for a
   message and afterwards APPENDUID for the new message.  [...]

nit: This comma is either spurious or missing a partner (if "as described
in the UIDPLUS specification" is supposed to be a parenthetical).

Martin Vigoureux No Objection

(Adam Roach; former steering group member) Yes

Yes ( for -02)
No email
send info

(Alexey Melnikov; former steering group member) Yes

Yes ( for -01)
No email
send info

(Ben Campbell; former steering group member) Yes

Yes (2018-10-23 for -02)
Thanks for this effort. I am balloting "yes", but I have some minor (mostly editorial) comments:

§1: Is there a reason not to use the new boilerplate from RFC 8174?

§3.4: "the intermediate states produced do not occur,"
That seems an odd statement; one might say that if a state did not occur it was not produced. Would it make sense to just say "the intermediate states do not occur"?

§3.5: "Unlike the APPEND command which is valid..."
Missing comma before "which".

(Alissa Cooper; former steering group member) No Objection

No Objection (2018-10-24 for -02)
Please take a look at the Gen-ART review.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -02)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection (2018-10-23 for -02)
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12061



COMMENTS
S 2.
>      handling a REPLACE command, a server MUST NOT generate a response
>      code for the STORE +flags \DELETED portion of the sequence.
>      Additionally, servers supporting the REPLACE command MUST NOT infer
>      any inheritance of content, flags, or annotations from the message
>      being replaced.  Finally, the replaced and replacing messages SHOULD
>      NOT be present in the mailbox at the same time.

I don't think I understand this text. What would it look like for them
to be present at the same time.

(Ignas Bagdonas; former steering group member) No Objection

No Objection ( for -02)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection ( for -02)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection (2018-10-23 for -02)
I'm curious about one point - 

   In its simplest form, the REPLACE command is a single-command
   encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a
   message, except that it avoids any of the quota implications or
   intermediate states associated with the 3 command sequence.  In
   handling a REPLACE command, a server MUST NOT generate a response
   code for the STORE +flags \DELETED portion of the sequence.
   Additionally, servers supporting the REPLACE command MUST NOT infer
   any inheritance of content, flags, or annotations from the message
   being replaced.  Finally, the replaced and replacing messages SHOULD
   NOT be present in the mailbox at the same time.

I can imagine that having the replaced and replacing messages present at the same time is better than having the replaced message deleted and the replacing message not stored due to quota limits when pipelining APPEND, STORE, EXPUNGE, but is SHOULD the right level of requirement language here? Is MUST just a non-starter?

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -02)
No email
send info