Re: [Extra] Proposed update to draft-ietf-extra-imap-replace-02

["Chris Newman" <[e-mail]>]

On 24 Oct 2018, at 18:30, Stuart Brandt wrote:
> B) Lack of clarity in final paragraph of the section 2
>
> Current...
>    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.
>
> Proposed...
>    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.  Server
>    developers are encouraged to implement REPLACE as an atomic 
> operation
>    to simplify error handling, minimize operational concerns, and 
> reduce
>    potential security problems.  For systems where this is not 
> possible,
>    communication with the requesting client must ensure no confusion 
> of
>    message store state.  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.

This is a good improvement. I consider it important to avoid an atomic 
behavior requirement to increase chances of implementation, but the new 
wording does a better job of stating the technical goal.

		- Chris