From: Sam Newsgroups: comp.mail.imap Subject: Re: Any suggestions of which IMAP server is better? Followup-To: comp.mail.imap Date: Tue, 07 May 2002 00:16:13 -0000 Organization: Kookbusters Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: knews 1.0b.0 (mrsam/980423) References: <3cd6538f$0$15143$afc38c87@news.optusnet.com.au> X-1: ------------------------------------------------------------------------ X-2: NOTE - spamtrap in use, valid address, legit mail accepted, but delayed. X-3: ------------------------------------------------------------------------ X-Goober-FAQ: http://www.killfile.org/~tskirvin/faqs/grubor.html X-SpeedBump-FAQ: http://www.ultranet.com/~eclipse/sbfaq.html X-NutScum-FAQ: http://www.netscum.org/ X-Grep-Bait-1: qmail, Archimedes Plutonium, turkey, Kibo, meow, Vulis, Grubor. X-Grep-Bait-2: "Some people are alive only because it is illegal to kill them." X-Complaints-To: newsabuse@supernews.com Lines: 233 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article , Mark Crispin writes: > It it curious that you feel this way, yet felt obliged to come out with an > IMAP server product. > In any case, the IMAP WG and the IESG did not feel this way, since both > bodies approved the document. Is that supposed to validate it, somehow? Since when did anything the IESG does automatically proclaimed to be logical, or consistent? Nobody's perfect, you know. Everyone makes mistake. >> IMAP does not have any kind of a formal grammar, or a lexical syntax. The >> protocol is defined as an unstructured glop of regular expressions. > > This is an irrelevant conclusion. This is not a conclusion, but an observation. There's a key conceptual difference between the two processes. > Attacking the form in which the IMAP > protocol is defined Not the form, but the actual substance. You can dress it up with many layers of make-up, but despite anyone's efforts, it's still the same wad of spaghetti, underneath. > does not disprove an assertation that IMAP does not > permit whitespace between BODY and [. And misrepresenting my arguments does not disprove the protocol's design faults. >> Right. If you want to know if there's anything in the folder, wow, what a >> brilliant idea: just open the folder and check. Don't assume that if the >> folder exists, it must be non-empty. > > You do not approve of Pine's behavior. That's fine. > > However, disapproval is not equivalent to "bug". I guess I'm just a perfectionist: I consider an implementation flaw to be the equivalent of a bug. >> > Example 3: "Pine fails to quote certain special characters in the login >> > userid and password." The characters in question are not atom-specials as >> > defined in the IMAP specification, and therefore do not need to be quoted. >> This goes back to point 1: the protocol's syntax, and grammar, is a mess. >> Good design, in practice, indicates that any protocol above some level of >> complexity should have a well-defined lexical syntax and grammar. I defy >> anyone to present a complete definition of IMAP's syntax or grammar. >> There is none. It's just a hairball of regular expressions. > > Another irrelevant conclusion. What exactly is irrelevant about not having any kind of a separation, whatsoever, between the lexical and the grammatical structure of the protocol? It is a very relevant point to make concerning the overall soundness, and well-formness, of the design. You know, even back in BASIC days, circa the '80s, they figured out that you have to stick a $ (or a %) to a variable name, so that the program could be parsed in a sane manner without leading to ambiguity between keyword names, and other parts of the language's grammar. Even back then they had the good sense to avoid treating any unrecognized keyword as a variable, requiring a $ (or a %) only when the variable name matches any reserved keyword. > Attacks on the form in which the IMAP > protocol is define do not disprove an assertation that the characters do > not need to be quoted. Once again you are building a strawman. The form used for defining IMAP is irrelevant, the actual IMAP definition is flawed. The form is indeed directly dictated by the underlying definition; however the real problem goes much further than that. > The question of whether the IMAP protocol's syntax and grammar is properly > defined is a red herring. I do not agree with your opinions on that > question, but I don't have to; that is not the matter at hand. However it is the matter at hand, which I keep bringing up. Everytime I do, you try to steer it off on a tangent, since you don't want to discuss it. Well, I do and if you don't, that's fine; perhaps someone else will care to address them instead of you. Go and appoint a spokesman, or something. >> I defy anyone to cite any text-based wire protocol that demands explicit >> presense, or absence, of whitespace delimiters. > > What other protocols specify is also a red herring. Well, a wise man learns from history. Reading and understanding existing protocols -- their faults and accomplishments -- is probably the best thing that anyone can do if they plan to build something of their own. Learn from others' mistakes, and all that. It is just unfortunate that too many people ignore the wealth of historical precendent and accumulated knowledge, before they go charging off, half-cocked, into darkness. > It is irrelevant whether any other text-based wire protocols demand > explicit presence, or absence, of whitespace delimiters. Well, I hope that I'll never grow to have such as close mindset. In the event I ever choose to design something new, as opposed to reimplementing something already exists, I hope that I'll have enough smarts to learn, study, and understand how similar things worked in the past; and that I'll be able to learn from their successes. Or their failures. > > I don't know what would be gained by citing protocols which have explicit > requirements for whitespace. Perhaps you would then understand why so many IMAP clients implement IMAP so poorly, as you, yourself, have often complained? Or why there are so comparatively few IMAP servers in existence? Come on, eight years down the road there should be more than just four POSIX IMAP servers out there (and only 24 knows IMAP servers in the entire world). How come there isn't anything like the "ESMTP Product Database" (not that I know of), that tries to help people to find an ESMTP application that they can use? Maybe there'd be less bellyaching on the subject, once the underlying root causes of both phenomenon (and they are certainly related) are understood. > I doubt that an apology (or even begrudging > acceptance) would be forthcoming; and it distracts from the main issue, > which is that IMAP has explicit and strict requirements for whitespace. And which is absolutely, positively, and unquestionably, silly. That's it. There's no other way of putting it. Mandating explicit whitespacing is just silly. I'd prefer to use something other than "silly" to describe it, but there are kids present. >> > Example 4: A complete non sequitor: "RFC 2060 clearly indicates that >> > a non-empty reference is non-standard behavior." I don't know where to >> > begin on this. >> It's really very simple: you define, yourself, that a certain form of the >> LIST command is implementation-defined: namely a non-empty reference >> parameter for LIST. Then you go ahead and have Pine spit out non-empty >> LIST references. > > The non-sequitor is in the claim that a standard-defined mechanism is > non-standard by virtue of having implementation-defined results. > > Something can not simultaneously be defined in a standard and be > non-standard. Well, you wrote it yourself: A non-empty reference name argument is the name of a mailbox or a level of mailbox hierarchy, and indicates a context in which the mailbox name is interpreted in an implementation-defined manner. ============================= Well, there you go. By using a non-empty reference name for LIST, you are relying on an implementation-defined server behavior. Therefore, it can no longer be claimed that Pine is designed to be interoperable with any IMAP server, since it clearly depends on the implementation-defined behavior of UW-IMAP's LIST command. Henceforth, let it be known that Pine failing to work with a particular IMAP server does not necessarily mean that the server breaks some particular aspect of the IMAP protocol. It might mean that the server simply does not reimplement a UW-IMAP specific extension to -- or an implementation-defined aspect of -- the IMAP protocol. In that case, I do not then understand how Pine should then be considered a reference implementation, when a key portion of its functionality depends on the UW-IMAP server's implementation-defined behavior. A reference implementation, by definition, should not rely on any particular implementation's behavior. At least that's what I always thought a reference implementation should be... > Before asking "why, originally, Pine's LIST requests were designed for > UW-IMAP-specific namespace and LIST semantics, instead of any IMAP > server's implementation?" it is first necessary to ask "were Pine's LIST > requests designed for UW-IMAP-specific namespace and LIST semantics, > instead of any IMAP server's implementation?" > > The answer to that question is "no". > > The reference argument to the LIST command was specifically designed and > added to the specification (necessitating the replacement of the former > FIND command with LIST) four years before Pine used that functionality. And that does not answer, in any way, why a supposed reference implementation relies on implementation-defined behavior. There's no need to generate long-worded paragraphs, in an attempt to avoid the subject. I think a simple answer should be possible here. >> > Example 5: "Netscape Communicator insists that the response in >> > HEADER.FIELDS is terminated by a blank line, supposedly the end of message >> > headers." Goodness knows that I am no fan of Netscape's client, but in >> > this case it is correct in expecting this [RFC 2060, page 42]. >> I have an idea: let's just add random empty lines to random commands, for >> no good reason. And because I said so, it must make sense, then. > > It is not "for no good reason". It is because RFC 2060 page 42 requires > it. Something that's required simply for the sake of requiring it, can't be a very good reason. Even a "good reason". I have another great idea: let's go out and design various protocols, parts of which have absolutely no logical basis to them whatsoever. Let's try to come up with the most ridiculous, laughable protocols, and when asked to justify why they're there we'll simply say that it's because the defining document states so. Gee, it's so easy to define a protocol, these days... It appears that logical thought, and reason, are no longer required... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt iD8DBQE81xzH3ejdWUS0ltARAsl3AJ9AeWBTXPdVGAu+NZ7p4JTfMUoSxwCaAxkN BDAyZnSeUc3zXmvRV1xqy7w= =Zj1s -----END PGP SIGNATURE-----