Subject: Re: [Extra] Bringing REPLACE back

From: "Chris Newman" <[email-masked]>
Date: Mon, 02 Jul 2018 20:45:39 -0700

I'm not a fan of adding parallel commands when there's a documented 
syntax extension model, especially for the APPEND command. I'd suggest a 
syntax more like this (following RFC 4466 model):

A004 APPEND Drafts (\Seen \Draft) UIDREPLACE 2000 {350} ...

Also the ABNF is simpler (and you don't have to fix the incompatibility 
of your ABNF with RFC 4466):
   capability   =/   "REPLACE"

   append-ext   =/   "UIDREPLACE" SP uniqueid

If you extend the command rather than adding a parallel command, then 
interaction with certain extensions (like CATENATE and UIDPLUS) becomes 
much simpler.

Other notes:
* the example is inconsistent -- the APPENDUID response should always 
have a UID higher than the replaced UID.
* this needs to document interaction with the OBJECTID extension.
* this needs to state whether this is available in AUTHENTICATED state 
vs. SELECTED state. I think it's slightly simpler if the UIDREPLACE 
extension is only available in SELECTED state, but I can implement it 
either way.
* I'd also prefer that this only support UIDs and not use message 
sequence numbers. Having an APPEND-like command that has pipelining 
sequencing problems like non-UID FETCH seems like it would add 
unnecessary complexity to the protocol.
* your example is inconsistent with the text in section 4.3; however I'm 
unsure that restriction is really helpful -- it might be better to 
encourage clients to robustly handle either order.

Although I don't plan to implement this in the near term, I'd much 
prefer it be standardized if the need arises so I support adoption by 
EXTRA. I think the extension has subtleties that will benefit from 
standards processing.

		- Chris

On 30 Jun 2018, at 12:37, Stuart Brandt wrote:

> An updated draft-brandt-imap-replace-03.txt is now available
>

---

From: Stuart Brandt <[email-masked]>
Date: Tue, 03 Jul 2018 07:36:17 -0400

Thanks, Chris. Comments below

> interaction with certain extensions (like CATENATE and UIDPLUS) becomes

Use of REPLACE for the 3 command sequence is consistent with use of MOVE 
(rfc6851) for a similar 3 command sequence. It also avoids state machine 
confusion since REPLACE, unlike APPEND, is not valid in authenticated 
state (see section 3.5).

> have a UID higher than the replaced UID.

I thought I had covered this with 2000 being the replaced UID and 2001 
being the new UID. Did I get the syntax wrong?

> * this needs to document interaction with the OBJECTID extension.

Will do. Since REPLACE is an encapsulation of APPEND/STORE/EXPUNGE and 
since APPEND is going to inherently involve different message 
structure/bodyparts, the replacing message should have both a new 
MAILBOXID and new EMAILID.  If client1 replaces message1 with message2, 
then client2 doesn't actually *have* message2 in its cache, so it will 
need to FETCH message2 if it wants to populate its cache.

It would be good if we could solve this issue of having to reFETCH large 
attachments that already exist in a client's cache, but it seems like 
that might require an OBJECTID like extension targeted at bodyparts 
rather than full messages.

> extension is only available in SELECTED state, but I can implement it

Is there something additional needed in section 3.5?

> unnecessary complexity to the protocol.

I too would prefer to not deal with sequence numbers, but I didn't want 
to break new ground in that regard compared to other IMAP commands and 
extensions.

> encourage clients to robustly handle either order.

Good catch. Thanks.

---

From: "Chris Newman" <[email-masked]>
Date: Sat, 14 Jul 2018 17:07:19 -0400

On 3 Jul 2018, at 7:36, Stuart Brandt wrote:
> Use of REPLACE for the 3 command sequence is consistent with use of 
> MOVE (rfc6851) for a similar 3 command sequence. It also avoids state 
> machine confusion since REPLACE, unlike APPEND, is not valid in 
> authenticated state (see section 3.5).

Ok. I'm still not a fan of more use of message sequence numbers, but so 
this isn't a show stopper for me.

> being the new UID. Did I get the syntax wrong?

Sorry, you're correct; I got it backwards (just used to "1" being the 
UID in examples and the long number being the uidvalidity ;-).

> MAILBOXID and new EMAILID.  If client1 replaces message1 with 
> message2, then client2 doesn't actually *have* message2 in its cache, 
> so it will need to FETCH message2 if it wants to populate its cache.
>
> It would be good if we could solve this issue of having to reFETCH 
> large attachments that already exist in a client's cache, but it seems 
> like that might require an OBJECTID like extension targeted at 
> bodyparts rather than full messages.
>

Sorry, I missed that.

> I too would prefer to not deal with sequence numbers, but I didn't 
> want to break new ground in that regard compared to other IMAP 
> commands and extensions.

If you're stuck with the ["UID" + top-level] command, then I can 
understand that position.

		- Chris