MBOX-Line: From witold.krecicki at firma.o2.pl  Mon Jun 14 08:06:08 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <15361.1276525914.496949@puncture>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006141431.47814.witold.krecicki@firma.o2.pl>
	<15361.1276525914.496949@puncture>
Message-ID: <201006141706.08343.witold.krecicki@firma.o2.pl>

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

