[Imap-protocol] IMAP MOVE extension
witold.krecicki at firma.o2.pl
Mon Jun 14 08:06:08 PDT 2010
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.
1. In some implementations it would be really hard to implement, I totally
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
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
More information about the Imap-protocol