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

[Stuart Brandt <[e-mail]>]

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

>
> Thanks,
>
> Benjamin
>