Re: Mulberry gone, now what?
- From: Mark Crispin <MRC@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 7 Oct 2005 15:17:06 -0700
On Fri, 7 Oct 2005, Dave Cridland wrote:
Polymer should work with any IMAP4rev1 server. It might work with a plain IMAP4 server, but I'd treat any errors there as low priority.
I don't think that it makes much sense to work with IMAP4 (RFC 1730). IMAP4 was a false start. If you must fall back from IMAP4rev1 (RFC 2060/3501), it would be better to fall back to IMAP2 (RFC 1064/1176).
See http://dave.cridland.net/acap/polymer.html for example where it says:-Cool. Mark, see that? My webpage is a more important reference than the specification. ;-)
:-)
Latitude is definitely not intended to mean the specification is in any way problematic. IMAP is very highly specified. It does, however, provide various protocol features which allow server to behave reasonably differently within some areas, in order to support very different server-side mail spools. That's not a fault in the protocol, that's a benefit. (One that has, in many respects, outlived itself).
Agreed.
In addition, there's exciting choices like multiple commands in progress, unsolicited reponses at any time, etc.
I never considered these to be particularly important, but there was a small but very loud contigent (now long gone) that screamed for multiple commands in progress.
The original IMAP had commands (with no tags) and four responses: OK, NO, BAD, and *; * carried data, and OK/NO/BAD indicated command completion. RTT avoidance would be done via command pipelining, as in several other protocols.
Supposedly, the need for multiple commands in progress (and thus, for command tagging) was that a SEARCH might take a long while because the operator might have to find the right backup 9-track and mount it; so it was desirable to allow other commands to be executed out of order.
Needless to say, that was never a scenario that existed in real life. I have never seen a server execute commands out of order, much less a client expect command execution out of order.
As for unsolicited responses at any time, besides the BYE response (which is important), there was a hope to avoid the need both for polling and an IDLE command. As it turned out, NAT boxes effectively killed IDLE in its infancy. Long live polling.
These are minor little variations in the gran scheme of things, though. The vast bulk of IMAP is very tightly specified - in some cases so tightly specified that virtually nobody implements it correctly (witness the \Recent flag).
UW and Cyrus do... :-)
My exeperience using mutt with different IMAP servers is that it never works quite the same with different servers.Mutt is pretty basic in its IMAP support, so yes, server behaviour - such as hierarchy - is directly visible to the user.
Yes, and (as I said earlier) that was once considered to be a feature, not a bug.
Like, for instance, servers sending FETCH or EXISTS responses when no command is in progress, even if they don't support IDLE. It's legal, but nobody does it. Hardly any clients can cope, either, but Polymer can, just as it can cope with commands executing out of order.
This is a good example of Postel's robustness principle. The c-client library (thus programs based upon it such as Pine) can cope, but I wouldn't think of actually sending such. The most that UW imapd does in this regard is send unsolicited EXISTS, RECENT, and a FETCH carrying flags, but only while a command is in progress.
Note that the last entry is "Other Servers" - I do know that Polymer works perfectly well with UW-IMAP, for instance, because UW-IMAP conforms to RFC3501 etc. I've not put UW-IMAP on that list, because it happens that I don't have an account on such a server.
Can't you install it on your own system? It supports almost every UNIX variant (certainly all the modern ones). With some effort, you can also run it on Windows.
ftp://ftp.cac.washington.edu/mail/imap.tar.Z
for the current release version, and
ftp://ftp.cac.washington.edu/mail/imap-2005.DEV.tar.Z
for the alpha version of the next release (which adds UIDPLUS support).
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. .
- Follow-Ups:
- Re: Mulberry gone, now what?
- From: Dave Cridland
- Re: Mulberry gone, now what?
- References:
- Mulberry gone, now what?
- From: Yiorgos Adamopoulos
- Re: Mulberry gone, now what?
- From: kael
- Re: Mulberry gone, now what?
- From: usenet
- Re: Mulberry gone, now what?
- From: Mark Crispin
- Re: Mulberry gone, now what?
- From: usenet
- Re: Mulberry gone, now what?
- From: Dave Cridland
- Mulberry gone, now what?
- Prev by Date: Re: Mulberry gone, now what?
- Next by Date: Re: Mulberry gone, now what?
- Previous by thread: Re: Mulberry gone, now what?
- Next by thread: Re: Mulberry gone, now what?
- Index(es):
Relevant Pages
|