[Imap-protocol] IMAP MOVE extension

[Witold Kręcicki]

On Monday 14 of June 2010 16:31:54 Dave Cridland wrote:

> > Tb, which is one of the most popular IMAP clients (at least for

> > desktops)

> > already includes this functionality (as XAOL-MOVE). So client

> > authors are

> > willing to trade.

> 

> No, that means one client is willing to trade.

Including the fact that it's just for one IMAP server, and the fact that it's 
one of the most popular clients - it's a lot.


> It cannot be implemented in the same style as other IMAP commands -

> you're introducing both the new concept of partial failure *and* an

> additional expunge command.

This 'new concept of partial failure' is not what I wanted, but I am being 
convinced that it is needed by the discussion on this list (because in -some- 
implementations it can't be done atomically). IMHO it should be all-or-
nothing, but that's a case of making everyone happy.

What's wrong with additional expunge (or expunge-like) command?


> > What other cases can there be that are not included here (and are

> > not corner-

> > cases that are not covered by IMAP specs and exists in eg. EXPUNGE

> > or COPY

> > commands)? I really though on that and (not including cases in

> > which COPY

> > could also fail) can't think of anything else.

> 

> I included three in my message.

Could you state them once again? I'm sorry but there's just too much traffic in 
this thread and I can't find them... 


> > > I note that in the case of success, you refer to messages in the

> > > UIDPLUS response code after they've already been expunged. A

> > > conformant client might struggle with that a bit, since it's

> > 

> > already

> > 

> > > dropped the messages locally.

> > > 

> > > Perhaps this needs to say that COPYUID is sent as an untagged OK

> > > prior to any EXPUNGE being sent referring to any message in the

> > 

> > set.

> > 

> > > I'd imagine that for some implementations, this would lead to a

> > > sequence of COPYUID/EXPUNGE pairs, which is unfortunate, when it

> > > could have been a single COPYUID/VANISHED.

> > 

> > Caching EXPUNGE responses waiting for final OK seems to be the

> > answer.

> 

> No, that's not acceptable - untagged responses MUST be handled

> independently of the command(s) (if any) in progress. That's an

> absolute requirement.

Then that's something to think about...
 

> > > And these are just the issues I've spotted now. I don't know how I

> > > can make this clearer - this is a very complex extension to design

> > > such that it'll work safely in all implementations.

> > 

> > It doesn't have to work in all implementations, and making it work

> > is a

> > implementator, not specification designer, work.

> 

> That's a ludicrous statement. It's a protocol designer's job to

> ensure that the protocol is as implementable as possible.

But it's not protocol designer's job to ensure that it's easily implementable 
in ALL the existing implementations. That's simply impossible task.


> > > a) The extension is, in principle, a good idea.

> > > 

> > > b) However, it's the kind of fundamental semantic that needs to be

> > > defined such that it is implementable in all existing

> > 

> > implementations.

> > What semantic is this missing that is not missing for COPY &

> > EXPUNGE commands

> > possible failures?

> 

> See above - you clearly state that "it doesn't have to work in all

> implementations", whereas I'm saying no, it does - yet here, you

> claim it does.

No. 
1. In some implementations it would be really hard to implement, I totally 
understand that.
2. In eg. Maildir store I can't find any cases in which there are failures 
possible that wouldn't have chance to occur with single COPY or EXPUNGE 
commands.


-- 
Witold Kręcicki

Grupa o2 Spółka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, Sąd Rejonowy dla m.st. Warszawy, 
Kapitał zakładowy 377.298,00 zł., NIP 521-31-11-513