Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-replace-02: (with COMMENT)

[Stuart Brandt <[e-mail]>]

Thanks for the feedback. Comments inline.

On 10/23/2018 5:16 PM, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-extra-imap-replace-02: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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?

The syntax of REPLACE identifies the source message's Mailbox by means 
of the currently selected Mailbox, thus requiring Selected state.

An optional source-mailbox parameter could be added to the syntax just 
for the UID REPLACE case, but other UID command variants such as those 
discussed in RFC3501 section 6.4.8 chose not to introduce UID specific 
syntax for specifying source-mailbox in order to support actions from 
Authenticated state alone. I'd prefer not to forge new ground in that 
area with this particular specification.

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