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

[Stuart Brandt <[e-mail]>]

Based on yesterday's last call feedback, there seems to be 2 areas where 
wording of the draft lacked clarity for reviewers. The following are 
proposed changes that I will make once the submission tool reopens. 
Feedback is welcomed.

A) Lack of clarity on state diagram impacts relative to UID REPLACE

Current...
    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.

Proposed...
    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.  Additionally, the
    REPLACE extension intentionally follows the convention for UID
    commands found in [RFC3501] section 6.4.8 in that the UID variant of
    the command does not support use from the authenticated state.

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.