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-----
> It it curious that you feel this way, yet felt obliged to come out with anIs 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. TheThis 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 IMAPNot 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
> does not disprove an assertation that IMAP does notAnd misrepresenting my arguments does not disprove the protocol's design
> permit whitespace between BODY and [.
>> Right. If you want to know if there's anything in the folder, wow, what aI 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 loginWhat 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 IMAPOnce 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 properlyHowever 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
>> I defy anyone to cite any text-based wire protocol that demands explicitWell, 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 demandWell, 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.
Perhaps you would then understand why so many IMAP clients implement IMAP
> 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 begrudgingAnd 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 thatWell, 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
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 forAnd 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 inSomething 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-----
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.