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

[Stuart Brandt <[e-mail]>]

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


On 10/25/2018 1:45 PM, Benjamin Kaduk wrote:
> 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
>