Subject: [imap5] questions

From: Mark Crispin <[email-masked]>
Date: Fri, 1 Aug 2008 09:05:13 -0700

Reviewing the traffic so far:

[1] Why are you doing IMAP5 instead of POP4?  Yes, the POP4 proposal was
crackpot, but until such time as you have a good and convincing answer you
are doomed to coming up with an even worse mess than what IMAP has today.

Specifically, you will soon face the tribe of "IMAP5 will die unless it has such
and such feature that I want."  Every bad idea that was rejected for IMAP4 will
re-rear its ugly head in IMAP5.

You had better look at RFC 1064 and see what was really core in IMAP.

[2] The proposal to remove BODYSTRUCTURE seems completely wrong
headed to me, and suggests to me that you should do POP4 instead of IMAP5.
The BODYSTRUCTURE is complex because MIME structure is complex.
"A fetch item to return the part numbers" basically betrays linear thinking.

[3] Use UTF-8 URIs for mailbox names, with one and only one schema for
how it works.  If any lesson is learned, that one should be learned.

[4] If you don't have BAD, then you don't have a way to distinguish the case
of "I know what you want done, but I can't do it" vs. "I don't know what you
want."  This is an important distinction that POP lacks.  The other important
thing that both POP and IMAP did was break away from small numbers and
the resulting switch/case statements that lead to interoperability issues.

[5] Death to LOGIN and PREAUTH.  Death to LSUB.  Death to LIST
entirely; this functionality does not belong in IMAP.  That also gets rid of
the entire single-use/dual-use issue.  Put this in a different protocol where it
belongs.

[6] If you remove MSNs, you suddenly remove an entire class of clients
from what is supposed by IMAP5.  You also remove an important means to
do synchronization; clients do use this because I have heard that from client
authors.

Now, I recognize that a large number of people lack the intelligence to use
MSNs and UIDs effectively, and perhaps that designing a protocol for the
stupid is a necessary thing.  But that principle must be stated and reflected
elsewhere in the protocol; and you have not done this.

Furthermore, if you design for the stupid, you must also design for the
defiant.  If you fail to do that, you have learned absolutely nothing
from my experience in the past 22 years.

Once again, why are you doing IMAP5 instead of POP4?  You haven't
answered that.

[7] No real argument about making flags simpler; although in the past 5
years people actually acquired a clue as to how to do \Recent and what
it is good for.  You do realize that client-based filters will have to have
something to replace \Recent if it is gone, don't you?

[8] Mandatory SIEVE support?  And this is supposedly simpler?

[9] Mandatory regex support?  And this is supposedly simpler?  What
happens when Google tells you that they have a better idea of how to
do search (which they have done) and thus are going to ignore you?

[10] Who will be your adult supervision to say "no" to crackpot ideas?
It won't be me.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

_________________________________________________________________
Keep your kids safer online with Windows Live Family Safety.
http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_family_safety_072008
_______________________________________________
imap5 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/imap5

---

From: Randall Gellens <[email-masked]>
Date: Sat, 2 Aug 2008 16:21:52 -0700

>  are doomed to coming up with an even worse mess than what IMAP has today.

Fundamentally, the POP model is like a post office box: mail gets 
delivered there until the user picks it up.  The authoritative set of 
existing messages lives in the client (even with LMOS and UIDL).  By 
contrast, in IMAP the server maintains the authoritative mail store.

>  re-rear its ugly head in IMAP5.

That's why I'd like to restrict IMAP5 to taking stuff away rather 
than adding things.  We've spent many years adding things, some quite 
useful, some which fixed fundamental interop problems, and some which 
provide a more efficient way to do something the client could already 
do.

IMAP is now full of possible extensions, complex magic states, a set 
of areas in which a fairly deep understanding of the protocol is 
needed to know why certain things are so.

If we can eliminate even some of this, we may end up with something 
just as useful but much simpler, and hence, easier for average 
implementers to get right (I'm not interesting the catering to the 
stupid ones who don't care anyway).

>  "A fetch item to return the part numbers" basically betrays linear thinking.

BODYSTRUCTURE is part of another fundamental difference between POP 
and IMAP: IMAP understands messages and can give the client 
information about and access to them and their constituent parts.  We 
should be sure we really want to do this before going down this path.

>  how it works.  If any lesson is learned, that one should be learned.

Yes, indeed.

>  want."  This is an important distinction that POP lacks.

Yes.

>  the entire single-use/dual-use issue.  Put this in a different 

What protocol do you suggest?  That's the problem.  We tried to move 
mailbox handling (including mailbox metadata and state) to ACAP a 
long time ago, leaving only message access in IMAP.

>  elsewhere in the protocol; and you have not done this.

Having both MSNs and UIDs makes the protocol much more complex. 
There are now two ways to refer to messages, two forms of many 
commands, restrictions on state changes that can be communicated to 
the client if it might be forming a command, etc.

I wouldn't claim that people who have bugs in this area are stupid. 
But I would suggest that maybe we can make the job easier.

MSNs do provide mailbox resynchronization, but so do UIDs.  Do we 
really need both?

>  from my experience in the past 22 years.

I'd rather design for the average implementer who wants to do a good 
job but isn't an expert in this.  I'm not sure how or why we'd design 
for the defiant, who presumably will what he or she pleases no matter 
what.  Designing for the very smart may be fun but has various 
limitations.

>  something to replace \Recent if it is gone, don't you?

My impression is that people want something that is close enough to 
\Recent that it's worth keeping, but I'm always open to to being 
wrong.

>  [8] Mandatory SIEVE support?  And this is supposedly simpler?

Lemonade is mandating Sieve support for the delivery agent.  I don't 
know if it needs to be in IMAP5 or not.  I could be convinced it 
doesn't.  Note that delivery agent support is different from 
ManageSieve support.

>  do search (which they have done) and thus are going to ignore you?

I think regular expressions are an idea whose time has come and gone. 
I tried to do it many years ago, but the difficulties and rat-holes 
are too numerous.

>  [10] Who will be your adult supervision to say "no" to crackpot ideas?

You'd get ice-cream on Thursdays!

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Whenever people agree with me I always feel I must be wrong.
                                              --Oscar Wilde
_______________________________________________
imap5 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/imap5

---

From: Mark Crispin <[email-masked]>
Date: Sat, 2 Aug 2008 21:50:10 -0700

> contrast, in IMAP the server maintains the authoritative mail store.

As much as I wish otherwise, I don't think that this distinction is valid
any more.

The majority of IMAP clients would seem to be happy with a POP3 with
the POP2 FOLD command restored and UIDL made mandatory.

> than adding things.

I agree; but I also believe that there is very little in RFC 1064 that can be
removed without causing pain.

>> the entire single-use/dual-use issue. Put this in a different
>> protocol where it belongs.

ACAP (and IMSP before it) became a mess because IMAP did the simple
management stuff well enough.  Thus, there was no responsible adult to
say "no" when crap got piled on into it.

If IMAP does not do any management stuff, suddenly you have a much
larger audience that can't live without the management protocol, and is
more likely to say "no" to the proposed addition of crap.

> the client if it might be forming a command, etc.

MSNs predate UIDs by many years.

IMHO, we should have done as POP3 did, and use MSNs for access
with UIDs being a message property.  The fluff is in the UID commands.

> I wouldn't claim that people who have bugs in this area are stupid.

I didn't say bugs.  I said people who lack the wit to use both together
intelligently.

> MSNs do provide mailbox resynchronization, but so do UIDs. Do we

By forcing clients to use UIDs only, you force a client to synchronize.
What about a client that doesn't want to synchronize?  What about a
client that just wants to say "you have n messages, and here they are"?

Please remember that not all clients synchronize or maintain persistent
state.  Without MSNs, a client that does not synchronize is doomed to
download the UID map each and every time.  This is the problem that
NNTP has.

> \Recent that it's worth keeping, but I'm always open to to being

That is my opinion as well.

> I tried to do it many years ago, but the difficulties and rat-holes

That was my conclusion 15+ years ago.  I'm glad to see that I am no
longer alone.

> You'd get ice-cream on Thursdays!

Not good enough I'm afraid.

_________________________________________________________________
Got Game? Win Prizes in the Windows Live Hotmail Mobile Summer Games Trivia Contest
http://www.gowindowslive.com/summergames?ocid=TXT_TAGHM
_______________________________________________
imap5 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/imap5

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 4 Aug 2008 00:18:52 +0300

> download the UID map each and every time.  This is the problem that

If we add SEARCHRES to base IMAP5, then:

1 fetch 1:5,10 envelope

equals to

2 search 1:5,10
3 fetch $ envelope

(MSNs should still be allowed as SEARCH parameters)

Yes, it makes it a bit more complex for such clients, but I think  
majority of clients today use only UIDs.
_______________________________________________
imap5 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/imap5

---

From: Mark Crispin <[email-masked]>
Date: Sun, 3 Aug 2008 20:20:23 -0700

> If we add SEARCHRES to base IMAP5

You are getting close, but not close enough.

I'll give up a secret from IMAP6:

What you want to do is abolish both the UID command and
sequence-set as anything other than a search-key.  Commands
which formerly took sequence-set would then take
 search-key / "(" *search-key ")"

() means "previous" which defaults to ALL.

The SEARCH (and ESEARCH) command, in turn, mutates into
a MAP command which returns a map in various output forms.

Don't say that I never give anybody anything.

_________________________________________________________________
Your PC, mobile phone, and online services work together like never before.
http://clk.atdmt.com/MRT/go/108587394/direct/01/