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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Oct 2018 14:16:54 -0700

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?

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

---

From: Stuart Brandt <[email-masked]>
Date: Tue, 23 Oct 2018 22:18:49 -0400

Thanks for the feedback. Comments inline.

> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Oct 2018 21:23:58 -0500

> area with this particular specification.

I probably should have made it clear: I also prefer to not forge such new
ground in this specification.  But does it make sense to make a nod to this
reality in the document and note that this restriction is also applied to
UID REPLACE for consistency?

Thanks,

Benjamin

---

From: Stuart Brandt <[email-masked]>
Date: Tue, 23 Oct 2018 23:13:33 -0400

> UID REPLACE for consistency?

Makes sense. Would the nod be more helpful when discussing state impacts 
(section 3.5) or when discussing UID REPLACE syntax (section 3.3)?

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 Oct 2018 12:45:34 -0500

> (section 3.5) or when discussing UID REPLACE syntax (section 3.3)?

It feels more natural to me in Section 3.5, but I have no claim to be an
authority in this matter :)

Thanks,

Benjamin

---

From: Stuart Brandt <[email-masked]>
Date: Thu, 25 Oct 2018 19:06:02 -0400

Thanks for the continued feedback, Benjamin. I'm glad you suggested 
section 3.5 because that's exactly where I added additional text in the 
-03 update today. Hopefully the additional text addresses your original 
feedback.

- Stuart