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

[Benjamin Kaduk <[e-mail]>]

On Tue, Oct 23, 2018 at 11:13:33PM -0400, Stuart Brandt wrote:
> On 10/23/2018 10:23 PM, Benjamin Kaduk wrote:
> > On Tue, Oct 23, 2018 at 10:18:49PM -0400, Stuart Brandt wrote:
> >> 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.
> >
> > 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?
> 
> Makes sense. Would the nod be more helpful when discussing state impacts 
> (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