Subject: Re: [imap5] In response to the Crispinogram.

From: Gilles LAMIRAL <[email-masked]>
Date: Wed, 28 Jul 2010 00:08:06 +0200

Hello,

It's been 2 years since you invited me on this discussion.
I joined the mailing list 2 years ago but I had no time to enter the subject.
I'm currently reading it and I will tell you my points of view.
I'll certainly change them since you are all imap pertinent experts.

May be it's too late to discuss. No problem. Tell me and
I'll stop loosing your time and mine.

I'm sorry in advance for my bad english.

You'll be surprised about the way I designed and maintained imapsync.
I wrote it without reading the RFCs, just partially when someone
reported "imapsync breaks the RFC". It uses a Perl library to deal
with imap. You can think it's worthless to read someone ignoring
RFCs. You can. I'm currently reading them too.

imapsync is stateless, slow and ugly, all those features are by "design".

Now let's go on the imap5 discussion.

> On Wed Aug 20 16:42:30 2008, Mark Crispin wrote:
>> Perhaps the author of imapsync didn't know about MULTIAPPEND.  Or
>> perhaps he was waiting for other IMAP servers to adopt it.

I didn't know about MULTIAPPEND.

> Let's just ask him, it'll cut the speculation.
> Gilles - would you say that atomicity is a critical thing for IMAP? 

Atomicity is not a critical thing for IMAP.
Why?
- Anything can fail at any time in so many ways: servers, clients, links, bad implementation etc.
- Critical sections are better coded and useful when they're small, simple and fast.
- When something fails we retry or correct them.

So important things are ways to know and verify things went well.

> Would you like MULTIAPEND semantics in the base spec of a revision?

MULTIAPEND is nice with the following conditions:
1) a huge mailbox with many small messages.
2) a link where IP packets are huge on a very long link, when responses
    are lagging (satellite transmissions may be this way) .

Probabilistic rule:
the more MULTIAPEND is used with many or huge messages
the more it can fail, the more it uses bandwidth.

> And just as important, would you like to join this mailing list? 
> mailto:[email-masked]?subject=subscribe

Done.

-- 
Au revoir,                             09 51 84 42 42
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06

---

From: Gilles LAMIRAL <[email-masked]>
Date: Thu, 29 Jul 2010 03:40:19 +0200

Hello,

Reading the entire history discussion I don't understand why
it ended without a whisper nor conclusion like: no way to
imap5. So I continue.

For imap experts it seems the term mailbox means folder in
standard user vocabulary and mailbox in user brain is an
account for imap experts.

I found this message useful to re-centre and continue the
discussion.

 > I think this exchange highlights the challenge we have in
 > finding an acceptable basis for including or excluding
 > features.

Yes.

 > My own view is that web hits and anecdotal (personal)
 > references and intuitions are not likely to be very
 > accurate or even very helpful in getting the group to
 > converge on a set of desired features and characteristics.

People talk about what they know, we can't avoid personal
references and intuitions. The other way is statistics. Both
can help.

 > One thing I've noticed about quite a bit of the
 > discussion, so far, is that it is in terms of IMAP
 > protocol constructs.  Obviously some of that detail is
 > necessary, but I suspect it is the wrong granularity for
 > initial focus.

Yes. Let's begin with top views, top needs.

 > Examples of statements that strike me as being at the
 > right level (but without commenting on whether I
 > personally agree or disagree with the specifics) are:

I comment them. I add some.

 >> I wonder if mobile devices are included in the mass
 >> market definition?

Yes.

Webmails too are in the mass market definition.

 >> I want to transfer a mailbox in its entirety, and I don't
 >> want to deal with cleaning up from partial failure.

Use a good client or take the easy way: restart from the
beginning. That what you'll have to do without partial
failure anyway. Partial failure well done economises
bandwidth and time.

 >> IMAP5 needs a method for atomic addition of multiple
 >> messages to the store

No. Too complicated to manage on both sides, client and
server.

The atomic data in messages delivery and reading systems is
"one message". As a client writer I would be happy if just
atomic delivery of one message could be well and easily
supported.

What does I mean by well and easily supported?

1) If I put a message and I get it back then the message
stays the same. As is, byte to byte.

2) I need a way to verify integrity on stored messages I've
just put a second or a hundred years ago.
May be two ways:

   a) Give me the last value you computed and the date you did it.
   b) Do it now.
   c) What UTC time is it in your clock?

3) If you say a message is 2_718_281 bytes long, don't send
me more or less when I get it. Or tell me you don't know its
size.

 >> I think stable, fairly predictable, numeric references
 >> are good, I'm not keen on any other form.

Message reference.

- stable: yes
- predictable: no (or why not)
- uniqueness over folder names, over the universe, until the end
   of the universe: yes
- multiple references for the same message: no.
- numeric: no

 >> Suppose we view IMAP5 as three feature packages:
 >> IMAP5compat (make it easy for IMAP4 clients to upgrade)

Not upgrade, migrate.

Forget about IMAP4 made easy.
Just made easy is enough.

 >> IMAP5core (make it easy for basic mail clients to do
 >> basic operations)

Make it easy (as easy as possible, think hard to make it
easy) for any client and any server to do anything in the
protocol.

 >> IMAP5sync (features for managing a local cache, lemonade
 >> stuff)

Managing a local cache is basic feature as soon as there is
one message on a server, wanted by a client.

No lemonade.

 > These examples cover different levels of abstraction, but
 > none is stated as IMAP protocol details.  Instead, they
 > are in terms of some claim of higher-level utility or
 > purpose.

Good point.

 > Chris' "Here's a first strawman at a priority-ordered"
 > note was a really good attempt to get discussion to target
 > end-user utility, rather than immediately bog down in
 > protocol detail.  So it's a shame it got no responses.

You got no response too.

 > Really, folks.  If the list insists on debating protocol
 > details, at this stage, the effort is going to be useless,
 > because each debate about detail will lack any larger
 > framework within which tradeoffs can be considered.

Yes.

 > To drastically reduce is to leave out.  An argument that
 > something must be retained needs to deal with the fact
 > that it is already available in IMAP4.  If it's already
 > there, then anyone wanting it can use IMAP4.

Yes.

 > What problems is IMAP5 trying to solve that IMAP4 does
 > not?  (An answer like "IMAP4 is too complex" isn't
 > helpful.)

May be IMAP4 can do it already. Tell me.

1) What are the messages which changed since date X?

2) A folder with 654321 messages I already got was
renamed or moved. How can I avoid fetching them again?

3) ACLs. A clear and fixed definition.

 > What are the basic technical constraints on IMAP5 that
 > distinguish it from IMAP4?

No. You said that technique is too early in the discussion.
Since we're all technical people, technical thinking is
always in our mind. Always. We must forget technical
implementations or have all possibilities in mind (which is
a way to forget).

I did it with message reference.

 > What higher level functionality might a user want to do
 > that IMAP5 will *not* support?

Coffee.

 > In order for the group to make progress, I suggest that
 > the group's decisions about what to include needs to have
 > really massive/broad support, rather than merely having
 > one or two vigorous supporters and that no one person have
 > influence that is effectively equivalent to a veto.

Does ietf organise polls? poll as a statistic tool, not a
decision tool. Discussions until consensus are better.

The protocol has to permit/manage all the following
views and usages:

1) The end user view.
2) The client software view.
3) The server software view.
4) The sysadmin configuration view.
5) The sysadmin backup/recovery/migrate view.
6) The end user backup/recovery view.
7) The network manager view.
8) The redundancy over the network view.
.) ?

All on holidays?

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 30 Jul 2010 15:13:58 +0100

> it ended without a whisper nor conclusion like: no way to

Depending on what IMAP5 will be..

a) It could be very much like IMAP4, making it easy for clients to
implement (they'd want to support IMAP4 for a long time too). But since
it has to be mostly IMAP4-compatible, will it simplify things all that
much to be worth the trouble?..

b) Keep the IMAP4 parser (atoms, string, literals, etc) but otherwise do
larger changes to protocol. Might make it a bit (but probably not that
much) easier for clients than c):

c) Redesign the whole thing from scratch. But why would clients
implement yet another protocol that very few servers support, when they
need to support IMAP4 anyway?

But ever since your mails I started thinking about c), mainly just for
fun. Maybe I'll get something done, but I don't really expect anyone to
implement it, except maybe myself.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 30 Jul 2010 02:59:13 -0700

Hi Gilles,

I'm not sure that an IMAP "mailbox" maps to a user "folder" since in 
IMAP a mailbox can be what is thought of as a folder (it has 
children) or it can be closer to a file, but I suppose this depends 
on how one thinks of messages.

I think the main argument in favor of IMAP5 is indeed that IMAP4 is 
too complex, it is too hard for clients to get right, and is too 
confusing.  New, higher-order functionality only adds to the 
complexity by introducing too many options and code paths.

Also, I'm not sure what you mean by verify message integrity -- are 
you concerned that messages are being corrupted?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Everybody believes in something and everybody,
by virtue of the fact they believe in something,
use that something to support their own existence.
    --Frank Zappa