[Imap-protocol] re: GMail

[Dave Cridland]

On Mon Oct 29 23:34:29 2007, Mark Crispin wrote:

> On Mon, 29 Oct 2007, Tim Showalter wrote:

>> I withdraw the comment.  (I made it based on something I read on  

>> this list some number of years ago, and I've never read the IMAP3  

>> document. Good thing, too. :-) )

> 

> It's instructive to read the IMAP3 document (RFC 1203), if only to  

> see a dead-end branch in IMAP's evolution.

> 

> RFC 1176 was a very minor update from RFC 1064, basically adding  

> the FIND command (a nascent form of LIST).  Much of RFC 1203 is a  

> strong reaction against the IMAP architecture (complete with a  

> diatribe to the effect that IMAP will die unless IMAP3 is adopted),  

> especially the unsolicited data model (e.g., it tags FETCH  

> responses).

> 

> 

I think that tagged intermediate responses can be useful, as it  
happens, but not for FETCH - this does, as you say, break the data  
model. They'd have been useful for SEARCH, SORT and THREAD, though.


>> What's the real difference between having strictly-increasing  

>> client capabilities, or revising the base spec?  In both cases,  

>> we're bundling some arbitrary set of protocol changes and  

>> requiring client/server support for all of them.

> 

> I think that there is much more opposition to adding to a base  

> specification than to a service level.  A new base specification  

> purported kills the previous one; whereas a service level might get  

> ignored at a particular point.

> 

> Sometimes how you call things does matter!

> 

> 

Calling things a Profile can work too.



>> Thinking about this a little more, I think there's an argument to  

>> be made for limiting capabilities and trying to decrease the  

>> number of different available capability sets, but we probably  

>> also need some amount of forking near the cutting-edge of protocol.

> 

> I agree completely!

> 

> 

As do I, but I'm wary of discarding extensions as well. Extensions  
can be developed incrementally, whereas profiles, service levels, etc  
take a lot more effort.



>> But if UTF8 is the first one, and it's successful and widely  

>> adopted, whatever the next wave is, should require UTF8.

> 

> I think that upgrading IMAP for UTF-8 is essential, and was  

> foreseen with the publication of RFC 2060.

> 

> 

Mostly foreseen - certainly the lack of any encoding for keywords has  
bitten us. Otherwise, we have a relatively clear upgrade path, and  
EAI has taken advantage of some of this.



>> But I'm very concerned about the complexity here.  It's apparently  

>> hard to implement correct IMAP clients and servers now.

> 

> I agree completely!

> 

> 

I don't think it's hard to implement a client correctly; although I  
do think it'd hard to take full advantage of the protocol. But this  
is largely a result of the lack of design documentation in the later  
IMAP specifications. Reading the earlier ones, whilst they're not as  
polished as the later specifications, was very useful to me. (In  
particular, the unsolicited data model is not adequately explained in  
RFC3501, but is better explained in RFC1176 and RFC1064 - the fourth  
paragraph of RFC1064's "The Protocol" section ought to be required  
reading.).



>> I'm not at all convinced of the wisdom of any of these approaches,  

>> but I am enjoying the discussion.

> 

> I think that we are all groping towards something that will address  

> the problem without causing the Law of Unintended Consequences to  

> come down hard upon us... ;-)


Certainly anything we do requires a significant amount of thought.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade