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

[Eric Rescorla <[e-mail]>]

OK, do you think you could make that clearer along the lines as you have
done here.

-Ekr


On Tue, Oct 23, 2018 at 8:10 PM Stuart Brandt <[e-mail]> wrote:

> Thanks, Eric. Comments inline.
>
> On 10/23/2018 8:17 PM, Eric Rescorla wrote:
> > Eric Rescorla 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:
> > ----------------------------------------------------------------------
> >
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D12061
> >
> >
> >
> > COMMENTS
> > S 2.
> >>       handling a REPLACE command, a server MUST NOT generate a response
> >>       code for the STORE +flags \DELETED portion of the sequence.
> >>       Additionally, servers supporting the REPLACE command MUST NOT
> infer
> >>       any inheritance of content, flags, or annotations from the message
> >>       being replaced.  Finally, the replaced and replacing messages
> SHOULD
> >>       NOT be present in the mailbox at the same time.
> >
> > I don't think I understand this text. What would it look like for them
> > to be present at the same time.
> >
>
> This wording was a compromise from the original
> draft-brandt-imap-replace-00 that had much stronger language around the
> atomicity of REPLACE.  In discussions just prior to IETF93, the strict
> atomic guarantee was considered a hindrance to adoption by server
> implementors. The "SHOULD NOT" here is intended to *discourage* server
> implementors from allowing clients to discover and therefore act on both
> original and new messages, but acknowledges that in some cases it may be
> unavoidable.
>
> To answer your question more directly, it would look like it looks today
> without the REPLACE extension -- 2 independent messages existing
> concurrently for a moment in time along with the potential issues
> highlighted in the Overview section.
>