 |
Newsgroups: comp.mail.imap
Followup-To: comp.mail.imap
From: Sam <s...@email-scan.com>
Date: Tue, 07 May 2002 00:16:13 -0000
Local: Mon, May 6 2002 8:16 pm
Subject: Re: Any suggestions of which IMAP server is better?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 In article <Pine.LNX.4.50.0205061508530.8118-100...@shiva1.cac.washington.edu>, > It it curious that you feel this way, yet felt obliged to come out with an Is that supposed to validate it, somehow? Since when did anything the IESG > IMAP server product. > In any case, the IMAP WG and the IESG did not feel this way, since both > bodies approved the document. 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 This is not a conclusion, but an observation. There's a key conceptual >> protocol is defined as an unstructured glop of regular expressions. > This is an irrelevant conclusion. difference between the two processes. > Attacking the form in which the IMAP Not the form, but the actual substance. You can dress it up with many > protocol is defined 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 And misrepresenting my arguments does not disprove the protocol's design > permit whitespace between BODY and [. faults. >> Right. If you want to know if there's anything in the folder, wow, what a I guess I'm just a perfectionist: I consider an implementation flaw to be >> 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". the equivalent of a bug. >> > Example 3: "Pine fails to quote certain special characters in the login What exactly is irrelevant about not having any kind of a separation, >> > 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. 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 > Attacks on the form in which the IMAP Once again you are building a strawman. The form used for defining IMAP is > protocol is define do not disprove an assertation that the characters do > not need to be quoted. 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 However it is the matter at hand, which I keep bringing up. Everytime I > 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. 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 Well, a wise man learns from history. Reading and understanding existing >> presense, or absence, of whitespace delimiters. > What other protocols specify is also a red herring. 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 Well, I hope that I'll never grow to have such as close mindset. In the > explicit presence, or absence, of whitespace delimiters. 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 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 Maybe there'd be less bellyaching on the subject, once the underlying root > I doubt that an apology (or even begrudging And which is absolutely, positively, and unquestionably, silly. That's it. > acceptance) would be forthcoming; and it distracts from the main issue, > which is that IMAP has explicit and strict requirements for whitespace. 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 Well, you wrote it yourself: >> > 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 > Something can not simultaneously be defined in a standard and be A non-empty Well, there you go. By using a non-empty reference name for LIST, you are Henceforth, let it be known that Pine failing to work with a particular In that case, I do not then understand how Pine should then be considered a At least that's what I always thought a reference implementation should > Before asking "why, originally, Pine's LIST requests were designed for And that does not answer, in any way, why a supposed reference > 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 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 Something that's required simply for the sake of requiring it, can't be a >> > 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 very good reason. Even a "good reason". I have another great idea: let's go out and design various protocols, parts Gee, it's so easy to define a protocol, these days... It appears that -----BEGIN PGP SIGNATURE----- iD8DBQE81xzH3ejdWUS0ltARAsl3AJ9AeWBTXPdVGAu+NZ7p4JTfMUoSxwCaAxkN You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||