The following protocol-compliance bugs are confirmed to be present in a server which identifies itself as: * OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information.
These bugs have been reported on multiple occasions. I do not care what the author of Courier (or his groupies) thinks about me, other client authors, or the IMAP specification. I care that about compliance with the IMAP specification and interoperability between IMAP clients and servers.
These are not esoteric problems. These bugs cause real problems for IMAP clients.
Bug 1: Does not parse IMAP atoms correctly
Accepts in atoms the following characters which are not valid in atoms: "(", ")", "*", "%" Rejects in atoms the following characters which are valid in atoms: "}"
Bug 2: Does not parse number ranges (n:m) correctly
If n is greater than m, it treats the range as no messages at all. The specification requires an inclusive range.
This is particularly important in UID clients using "*" for m, which may not know that n is larger. Not returning anything to a FETCH n:* implies that there are no messages in the mailbox.
Bug 3: Does not implement THREAD=ORDEREDSUBJECT correctly
Does not sort the threads by the sent date of the first message in the thread as required by the specification; instead, the threads are sorted by subject.
In article <Pine.LNX.4.50.0206050910320.6814-100...@shiva0.cac.washington.edu>, Mark Crispin <m...@CAC.Washington.EDU> writes:
> Bug 1: Does not parse IMAP atoms correctly
> Accepts in atoms the following characters which are not valid in atoms: > "(", ")", "*", "%"
A bug/design flaw in the protocol specification.
> Bug 2: Does not parse number ranges (n:m) correctly
> If n is greater than m, it treats the range as no messages at all. The
That's right, Einstein. That's what a null set contains. A range with a starting position greater than the ending position is a null range. Kids learn this stuff in grade school mathematics, I believe.
> specification requires an inclusive range.
An inclusive null range is still a null range.
> Bug 3: Does not implement THREAD=ORDEREDSUBJECT correctly
> Does not sort the threads by the sent date of the first message in the > thread as required by the specification; instead, the threads are sorted > by subject.
THREAD=ORDEREDSUBJECT is not defined by any RFC, it's still an experimental draft only, subject to change.
Mark Crispin <m...@CAC.Washington.EDU> writes: > Bug 1: Does not parse IMAP atoms correctly
> Accepts in atoms the following characters which are not valid in atoms: > "(", ")", "*", "%" > Rejects in atoms the following characters which are valid in atoms: > "}"
In article <courier.3CFE4C13.00003...@ny.email-scan.com>, Sam <s...@email-scan.com> writes:
> In article <Pine.LNX.4.50.0206050910320.6814-100...@shiva0.cac.washington.edu>, > Mark Crispin <m...@CAC.Washington.EDU> writes:
>> Bug 3: Does not implement THREAD=ORDEREDSUBJECT correctly
>> Does not sort the threads by the sent date of the first message in the >> thread as required by the specification; instead, the threads are sorted >> by subject.
> THREAD=ORDEREDSUBJECT is not defined by any RFC, it's still an experimental > draft only, subject to change.
> Yawn.
Oh, just for the hell of it, I looked up what happened with the experimental THREAD extension. And, the threads are definitely sorted by the sent date.
a thread orderedsubject iso-8859-1 all * THREAD (351 420 709 855) ... ... (262 177 182 206) ...
Picking the first thread I spot with messages not in numerical order, and what do I see?
a fetch 262 (body[header.fields(date)]) * 262 FETCH (BODY[HEADER.FIELDS ("date")] {41} Date: Wed, 29 May 2002 22:08:59 -0500
) a OK FETCH completed. a fetch 177 (body[header.fields(date)]) * 177 FETCH (BODY[HEADER.FIELDS ("date")] {41} Date: Thu, 30 May 2002 14:55:32 +0200
) a OK FETCH completed.
Pulling the source code confirms the logic. That module wasn't touched in two years, so it's not clear to me where's the beef here.
You know, I should've followed my initial instinct, and instead of being diplomatic in my initial response, I should've stated that you were full of shit. As always. And I would've been right. That's what I thought at first too, since I knew that I did everything correctly. But, I thought, perhaps something had changed in the intervening years, since the last time I looked at the draft, that I didn't know about. But no, that wasn't the case. ORDEREDSUBJECT's definition hasn't changed at all, unfortunately. It would've been nice to have it rewritten with a little bit more clarity, but we aren't so lucky, I suppose. It's still as confusing, redundant, and nonsensical as it always was.
So, to compensate for my missed opportunity to flame Crispin, when I had a good excuse for doing so, I'll make up for it by flaming the draft. Reviewing the whole mess brought back fond memories. It was always amazing how much obfuscation, plain nonsense, and self-contradictory claims, was possible to cram into a single paragraph:
ORDEREDSUBJECT The ORDEREDSUBJECT threading algorithm is also referred to as "poor man's threading." The searched messages are sorted by subject and then by the sent date.
Well, if you first sort the messages by the subject, and then you sort all the messages by the sent date, then the first sort wasn't needed at all, was it? Since you'll re-sort the whole thing by sent date anyway, you don't need to do the first sort. But, I'm fairly sure this meant to state that the subject is the primary sort key, and the sent date is a secondary sort key, so that's going to be it. That's probably the likeliest meaning of that. ... The messages are then split into separate threads, with each thread containing messages with the same extracted subject text ...
Well, I just had to quote the sole logical occupant of the otherwise illogical paragraph, just so I wouldn't be accused later of selectively editing out this stuf. Praise gawd, this sentence mostly makes sense...
... Finally, the threads are sorted by the sent date of the first message in the thread.
And this sentence definitely wins the prize for Gobbledygook Of The Year[tm], because it manages to not make any sense in two different ways. And that's not an easy accomplishment. First-ly <cough> each thread is already sorted by the sent date anyway, due to sent date being the secondary sort key in the first place. Second-ly <cough> "sent date of the first message in the thread" is obviously not a property of each message in the thread, so saying that it should be used as a sort key, when sorting each thread, makes no sense whatsoever. So, the double-whammy is that, for starters, the threads are already sorted by the sent date of each message in the thread, and the specification of the sort key is completely non-sensical.
So, who knows what that is all about. Certainly not me. The entire definition of ORDEREDSUBJECT threading consists of this lone, contradictory, and confusing paragraph (which, sadly, doesn't differ from the typical logic factor of your drivel). Perhaps others who have all the necessary secret decoder rings can make sense of all that. I don't have any secret decoder rings, I only have to go with what I read. If history's a teacher, it'll probably take two or three revisions before any of this reaches a state where most people can clearly understand it. I'll worry about it then. Right now, as far as I'm concerned, everything's working the way it should work, or at least the way it reads.
So that's my sermon for today. I thought about sprucing it up with my legendary humor, and wit. But that would've taken up too much time, and this particular Crispinrant wasn't worth it. I'll save the yuks for next time. Promise.
Consider a user who has a password of bar}zap. This can be sent as an atom. However, a LOGIN command which attempts to transmit it as an atom will result in:
* OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information. . login foo bar}zap . NO Error in IMAP command received by server.
Whether or not } should be an atom_special is besides the point. The specification says that it is not an atom_special, therefore it is permitted to have an atom containing this character.
On Wed, 5 Jun 2002, Sam wrote: > A bug/design flaw in the protocol specification.
That is besides the point. Fix your server to comply with the protocol specification.
> That's right, Einstein. That's what a null set contains. A range with a > starting position greater than the ending position is a null range. Kids > learn this stuff in grade school mathematics, I believe.
There is nothing in the protocol specification that says that one value is a "starting position" and the other is an "ending position". The exact wording in the specification is "delimits between two numbers inclusive."
Courier's implementation breaks UID clients (no, not Pine) which send n:* where n is one greater than the previous maximum UID. If n is larger than the UID for the last message in the mailbox, Courier returns no data. The correct response in this case is to return data for the last message. Courier's incorrect response is interpreted by these UID clients as indicating that there are no messages in the mailbox.
> THREAD=ORDEREDSUBJECT is not defined by any RFC, it's still an experimental > draft only, subject to change.
The THREAD specification is a document of the IETF IMAP Extensions Working Group, which you have made no effort to participate in. There is no likelihood that the semantics of THREAD=ORDEREDSUBJECT are going to be changed, as the only matter left under discussion is the semantics of collation of non-ASCII strings.
Courier's implementation of THREAD=ORDEREDSUBJECT is incompatible from every other implementation. There is no need for this incompatibility.
There is no need for any of Courier's other incompatibilities (including the two discussed above) either.
I don't care if you don't like me or the IMAP specification. However, you owe it to your users to fix your bugs that cause incompatibilities and interoperability failures with other IMAP implementations.
In article <Pine.LNX.4.50.0206051121080.15249-100...@shiva0.cac.washington.edu>, Mark Crispin <m...@CAC.Washington.EDU> writes:
> Consider a user who has a password of bar}zap. This can be sent as an > atom. However, a LOGIN command which attempts to transmit it as an atom > will result in:
> * OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information. > . login foo bar}zap > . NO Error in IMAP command received by server.
> Whether or not } should be an atom_special is besides the point. The > specification says that it is not an atom_special, therefore it is > permitted to have an atom containing this character.
In article <Pine.LNX.4.50.0206051124510.15249-100...@shiva0.cac.washington.edu>, Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Wed, 5 Jun 2002, Sam wrote: >> A bug/design flaw in the protocol specification.
> That is besides the point.
No that's very much the point. A bug, and especially a design flaw, needs to be fixed. To blindly follow a broken, flawed, design is illogical, and stupid. You want to keep doing the same stupid thing, all over and over again? Fine, it's your job now. You can have it. I'll do something else instead.
> Fix your server to comply with the protocol > specification.
The server complies with the protocol specification, without complying with its stupid design flaws.
>> That's right, Einstein. That's what a null set contains. A range with a >> starting position greater than the ending position is a null range. Kids >> learn this stuff in grade school mathematics, I believe.
> There is nothing in the protocol specification that says that one value is > a "starting position" and the other is an "ending position".
That's how a numerical range is defined: starting value and and ending value. Again, review your grade school Mathematics course book, for additional information.
When the rules of mathematics are changed to show that 4 is less than 3, then I'll make corresponding changes to my code, but not until then.
> Courier's implementation breaks UID clients (no, not Pine) which send n:* > where n is one greater than the previous maximum UID.
Clients that do that are already broken, by the time they've ever gotten this far. I do not place much priority on accomodating broken clients. If you want to do that yourself, fine, that's your call, and a privilege. But it is not my privilege either to waste the rest of my life chasing after every bug in every broken client.
> If n is larger than > the UID for the last message in the mailbox, Courier returns no data. > The correct response in this case is to return data for the last message.
It's not. A null set is a null set. Pretending that a null set isn't a null set is absurd.
>> THREAD=ORDEREDSUBJECT is not defined by any RFC, it's still an experimental >> draft only, subject to change.
> The THREAD specification is a document of the IETF IMAP Extensions Working
Am I supposed to be impressed, or something? Just want to make sure I have the scenario right.
> Group, which you have made no effort to participate in.
Thanks, but I'd rather watch the paint dry, on my porch. IETF is good at formalizing de-factor standards, but as far as developing and producing new standards go, the IETF is a major waste of time.
> There is no > likelihood that the semantics of THREAD=ORDEREDSUBJECT are going to be > changed, as the only matter left under discussion is the semantics of > collation of non-ASCII strings.
> Courier's implementation of THREAD=ORDEREDSUBJECT is incompatible from > every other implementation.
Every implementation is incompatible with every other implementation, by the virtue of the fact that there is no firm, stable, specification. Especially when the specification is still vague, and unclear on a number of points. But that's been covered elsewhere. In any case, if the collation order is changed, then all the vaporware implementations will suddenly become incompatible with each other either anyway. In the immortal words of Bugs Bunny: biiiiiiiig deal...
> There is no need for this incompatibility.
> There is no need for any of Courier's other incompatibilities (including > the two discussed above) either.
The only incompatibles present at this time are incompatibilities with protocol bugs, and design flaws. I place no priority whatsoever on trying to reimplement all the design flaws, and protocol bugs. Doing so only encourages further sloppy coding practices and implementations in other products.
> I don't care if you don't like me or the IMAP specification.
I don't care if you do not like my server either. Not unless, of course, there's some humor value in it.
> However, you > owe it to your users to fix your bugs that cause incompatibilities and > interoperability failures with other IMAP implementations.
I might owe something to my users, but since you're not one of them you really are no position to demand anything, no matter who you think you are. Neither are you in any position to pass judgment on something that you really do not have much first hand knowledge about. You might still choose to do so, since everyone is entitled to a privilege of being able to blather without a clue. Including you.
>>> That's right, Einstein. That's what a null set contains. A range with a >>> starting position greater than the ending position is a null range. Kids >>> learn this stuff in grade school mathematics, I believe.
>> There is nothing in the protocol specification that says that one value is >> a "starting position" and the other is an "ending position".
> That's how a numerical range is defined: starting value and and ending > value. Again, review your grade school Mathematics course book, for > additional information.
Trying to be a bit constructive, and since the IMAP spec is up for last call: How about clarifying the wording that there is no sorting required in a article number range? Perhaps even illustrate it with a weird example such as "*,5:3,8,*,9:11". Considering that at least 5 different servers implement message ranges incorrectly, perhaps the source of the confusion is the specification.
IMHO the word "range" should not be used in this context. "set" is better.
On Wed, 5 Jun 2002, Sam wrote: > Oh, just for the hell of it, I looked up what happened with the > experimental THREAD extension. And, the threads are definitely sorted by > the sent date. > a thread orderedsubject iso-8859-1 all > * THREAD (351 420 709 855) ... > ... (262 177 182 206) ...
> Picking the first thread I spot with messages not in numerical order, and > what do I see?
Yes, the messages within a thread are sorted by the sent date. However, the threads themselves are not sorted by the sent date of the first message in the thread. Read the specification for ORDEREDSUBJECT carefully, specifically what comes after "Finally":
[...] The searched messages are sorted by subject and then by the sent date. The messages are then split into separate threads, with each thread containing messages with the same extracted subject text. Finally, the threads are sorted by the sent date of the first message in the thread.
Courier does not do the final step, leaving the threads sorted by the subject.
In article <ilu1ybl33r0....@latte.josefsson.org>, Simon Josefsson <simon+i...@josefsson.org> writes:
> weird example such as "*,5:3,8,*,9:11". Considering that at least 5 > different servers implement message ranges incorrectly, perhaps the > source of the confusion is the specification.
The gentleman wins a cigar.
> Trying to be a bit constructive, and since the IMAP spec is up for > last call: How about clarifying the wording that there is no sorting > required in a article number range? Perhaps even illustrate it with a
And what exactly is going to be gained by that? Why have two different ways to say the same thing? What possible value is there in specifying a bass-ackwards range? n:*? Well, why don't YOU (for some general values of "you") learn how to code properly. If you know what you're doing, you don't need "FETCH n:*" to check for new mail. This is just a stupid way to do something when you don't know how to do this right. Somehow, plenty of people have figured out how to do this right, without feeling an urgent need to list message IDs backwards, or throw "n:*" at the server, and figure out what comes back.
On Wed, 5 Jun 2002, Simon Josefsson wrote: > Trying to be a bit constructive, and since the IMAP spec is up for > last call: How about clarifying the wording that there is no sorting > required in a article number range?
Already done.
> IMHO the word "range" should not be used in this context. "set" is > better.
Unfortunately, "set" means something else. However, "range" is not used in the Formal Syntax for precisely this reason.
On Wed, 5 Jun 2002, Sam wrote: > The server complies with the protocol specification, without complying with > its stupid design flaws.
This is
> > There is nothing in the protocol specification that says that one value is > > a "starting position" and the other is an "ending position". > That's how a numerical range is defined: starting value and and ending > value. Again, review your grade school Mathematics course book, for > additional information.
A grade school Mathematics course book is not normative for the IMAP protocol specification or, as far as I know, any other protocol specification. Nowhere in the IMAP specification does it say that n:m syntax refers to "starting value and ending value".
The IMAP specification says "between two numbers inclusive".
> > Courier's implementation breaks UID clients (no, not Pine) which send n:* > > where n is one greater than the previous maximum UID. > Clients that do that are already broken, by the time they've ever gotten > this far.
The other client and server implementors do not agree with you.
> I might owe something to my users, but since you're not one of them you > really are no position to demand anything, no matter who you think you are.
Most unfortunately, I have to communicate with the broken Courier IMAP server in order to retrieve my invoices and payment records from my ISP. So I *am* one of your users.
I want to retrieve them to an embedded device, but Courier's bugs preclude interoperability with that device's IMAP client. I am obliged to access that server with Pine (which, if one is careful, can work with Courier), transfer the messages to a UW or Cyrus server, and then transfer them to the embedded device.
In article <Pine.LNX.4.50.0206051319170.21025-100...@shiva0.cac.washington.edu>, Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Wed, 5 Jun 2002, Sam wrote: >> Oh, just for the hell of it, I looked up what happened with the >> experimental THREAD extension. And, the threads are definitely sorted by >> the sent date. >> a thread orderedsubject iso-8859-1 all >> * THREAD (351 420 709 855) ... >> ... (262 177 182 206) ...
>> Picking the first thread I spot with messages not in numerical order, and >> what do I see?
> Yes, the messages within a thread are sorted by the sent date. However, > the threads themselves are not sorted by the sent date of the first > message in the thread. Read the specification for ORDEREDSUBJECT > carefully, specifically what comes after "Finally":
Read the rest of my post, and fix your document. The part after "finally" is ambiguous (in addition to the part before it), with more than one possible way to interpret it. Next time you feel the urgent need to blather your head off, stop and think if perhaps your own scribblings need to be fixed so they don't require a secret decoder ring.
> [...] The searched messages are sorted by > subject and then by the sent date. The messages are then split > into separate threads, with each thread containing messages > with the same extracted subject text. Finally, the threads are > sorted by the sent date of the first message in the thread.
> Courier does not do the final step, leaving the threads sorted by the > subject.
No, you need to bone up on your English (funny that). The threads are sorted by sent date (you pick a thread, and you'll find that's how the thread is sorted by), it's the collection of threads that you imply should be resorted by sent date.
But then, this opens up another bunch of problems:
...
All servers and disconnected clients MUST use exactly this algorithm when threading. Otherwise there is potential for a user to get inconsistent results based on whether they are running in connected or disconnected IMAP mode.
...
Well, that's the end of that, then. Nice try, but no cigar. Plenty of messages will now have the same sent date (think cron jobs), therefore you can throw this pie-in-the-sky idea right out of the window, because you now have an ambiguous final ordering anyway.
That's why, when faced with two possible interpretation of that whole paragraph, the interpretation where the sort order referred to the threads' internal sort order made more sense. The collection of threads, at least, used a clear, unambiguous, subject ordering so far. Therefore, the most logical intepretation is to conclude that this is a reference to each thread's internal sort order. Which will still be ambiguous but at least the magnitude of the mess is smaller, and the thread index itself is in an unambiguous order.
In article <Pine.LNX.4.50.0206051324020.21025-100...@shiva0.cac.washington.edu>, Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Wed, 5 Jun 2002, Sam wrote: >> The server complies with the protocol specification, without complying with >> its stupid design flaws.
> This is
>> > There is nothing in the protocol specification that says that one value is >> > a "starting position" and the other is an "ending position". >> That's how a numerical range is defined: starting value and and ending >> value. Again, review your grade school Mathematics course book, for >> additional information.
> A grade school Mathematics course book is not normative for the IMAP > protocol specification or, as far as I know, any other protocol > specification.
A good grasp on mathematics is an absolute requirement for implementing any kind of a computing procedure, or an algorithm. Otherwise, you'll have a real problem figuring out whether you want to use the ++ or the -- operator, in each case, won't you?
This just has to be the loopiest thing I've heard in quite some time. You know, if I were to use that as sig material, people would DEFINITELY get the wrong idea. No, just think about it. You walk off the street, not knowing anything about this, and just see this sig quote on some random Usenet post. What would you think the original writer intended to say?
Well, you're in luck because I'm not that big on sigs. If I were, you'd never hear the end of it.
> Nowhere in the IMAP specification does it say that n:m > syntax refers to "starting value and ending value".
Neither does it say that n:m refers to the "ending value and a starting value" either. So, people that prefer to think logically will therefore conclude that n:m refers to a numerically increasing range, because logic tends to be forward-thinking (in a metaphysical sort of way), and logic
> The IMAP specification says "between two numbers inclusive".
"inclusive" doesn't tell you anything useful, in this case. An "inclusive" increasing numerical sequence, and an "inclusive" decreasing sequence are two completely different thinks, so a mere reference to "inclusive" does not disambiguate anything.
>> > Courier's implementation breaks UID clients (no, not Pine) which send n:* >> > where n is one greater than the previous maximum UID. >> Clients that do that are already broken, by the time they've ever gotten >> this far.
> The other client and server implementors do not agree with you.
Well, I'm sure there aren't any client or server implementators out there who would admit to the fact that their code is broken. However, it doesn't change the fact that it is.
>> I might owe something to my users, but since you're not one of them you >> really are no position to demand anything, no matter who you think you are.
> Most unfortunately, I have to communicate with the broken Courier IMAP > server in order to retrieve my invoices and payment records from my ISP. > So I *am* one of your users.
Well, _THAT_ definitely has to be the funniest thing I've read in at least a couple of years.
But don't worry about it. According to you, maildir-based IMAP service is horribly inefficient. After all, that's what you've been saying for years. Some blather to that effect can still be found in UW-IMAP's source code, I believe. Not that I care, of course, I'm just pointing out a relevant fact. And if you're going to deny that, I'll just go back to Google and prove that as well.
So... you really don't have anything to worry about, since any day now your ISP is going to dump that horribly inefficient, and slow, server, and go back to using the fast, reliable UW-IMAP server. Or Cyrus. Or DK-IMAP.
Don't worry, I'm confident that you won't have to suffer such an indignity for much longer.
> I want to retrieve them to an embedded device, but Courier's bugs preclude > interoperability with that device's IMAP client. I am obliged to access > that server with Pine (which, if one is careful, can work with Courier), > transfer the messages to a UW or Cyrus server, and then transfer them to > the embedded device.
Well, one rule I recommend that everyone should follow is to carefully consider anyone that you choose to piss on. Make sure that they will never ever be in a position to piss back on you.
I follow that rule myself. Really, I do. This is actually not the rule itself, only a sanitized version. The real rule uses a somewhat more crude choice of words. But I have an image, and a dignified reputation to maintain, so I won't use it. (STOP, read the other thread before having another cow, g'd-emnit, do I have to spell out everything, every time?)
I'm dying to know if that ISP uses qmail too. That would definitely be the icing on the cake. I think I can make a fairly good guess what ISP this is (there aren't that many, after a brief process of elimination and enumeration). If I'm right, I know that their mail transport is qmail-ldap, baaaa-ha-ha...
If I'm right, and if the parties concerned are lurking in here, I thought that I should let y'all know that I've set up a script on the @courier-mta.com mailbox that automatically "deletes" the headers from any mail that includes a copy of any missive received by customer support, that relies on the author's stature and claimed credentials in badmouthing their choice of server software...
> > Whether or not } should be an atom_special is besides the point. The > > specification says that it is not an atom_special, therefore it is > > permitted to have an atom containing this character.
> The specification is wrong.
The specification is not as wrong as you are saying, just that it is the choice of the author of the specification. Whether it is a good or a bad choice, if you refer to a specification, you have to follow it, unless you claim your server explicitely as non-IMAP compliant.
In article <etPan.3cff3940.6b8b4567.4...@paralaplage.irisa.fr>, DINH Viet Hoa <dinh-coeur.viet-fleurbleu.hoa-yingy...@free-sourire2.fr> writes:
>> > Whether or not } should be an atom_special is besides the point. The >> > specification says that it is not an atom_special, therefore it is >> > permitted to have an atom containing this character.
>> The specification is wrong.
> The specification is not as wrong as you are saying, just that > it is the choice of the author of the specification.
If someone made a bad choice, I am not obligated to follow it.
> Whether it is a good or a bad choice, if you refer to a specification, you > have to follow it, unless you claim your server explicitely as > non-IMAP compliant.
Look: everyone in front of you is jumping off a cliff. It's your turn now.
On Thu, 6 Jun 2002, DINH Viet Hoa wrote: > The specification is not as wrong as you are saying, just that > it is the choice of the author of the specification.
It wasn't just a choice. It was explicit design that atom_specials would include only those characters that MUST be atom_specials. To wit:
1) "(" is in atom_specials to distinguish from a start of a parenthesized list. There are cases where either an atom or a parenthesized list can appear.
2) ")" is in atom_specials to distinguish from an end of a parenthesized list. Atoms can occur within a parenthesized list.
3) "{" is in atom_specials to distinguish from a literal size count. There are cases where either an atom or a literal (or a quoted string) can appear.
4) SPACE is in atom_specials because it is used as a delimiter between objects including atoms.
5) CTL is in atom_specials because these are non-graphical characters.
6) list_wildcards is in atom_specials in order to disallow unquoted wildcards in mailbox names (except in the LIST and LSUB commands, where wildcards are appropriate).
7) quoted_specials is in atom_specials to distinguish from a quoted string. There are cases where either an atom or a quoted string (or a literal) can appear. This also enables the special naming of system flags vs. keyword flags.
There is no reason for "}" to be in atom_specials. "}" can be part of an atom without ambiguity with any other IMAP syntax. {23} can not be an atom, because it is a literal size count, but 23} can be.
IMAP syntax is not decided by cosmetics (e.g. arguments such as "{ is special so } should be"), nor IMAP syntax decided by anything not explicitly declared as normative by the IMAP specification.
> Whether it is a good or a bad choice, if you refer to a specification, you > have to follow it, unless you claim your server explicitely as > non-IMAP compliant.
I agree. Failure to follow a specification, even those parts that you feel are mistakes, is harmful to everybody. This lesson has been learned, painfully, many times in the past 30 years.
If one feels that there is a mistake in a specification, the proper way is to address it in the standards body for that specification. Disregarding a portion of the specification as a "mistake", and disparaging the standards body as "a waste of time", is cowboy behavior.
In article <Pine.LNX.4.50.0206060627390.15543-100...@shiva0.cac.washington.edu>, Mark Crispin <m...@CAC.Washington.EDU> writes:
> If one feels that there is a mistake in a specification, the proper way is > to address it in the standards body for that specification.
Left sock, meet my right sock. Right sock, meet my left sock. Now that we know each other, the show is on.
> Disregarding > a portion of the specification as a "mistake", and disparaging the > standards body as "a waste of time", is cowboy behavior.
That was a nice show, <clap> <clap>. The peanut gallery is impressed.
For all those sitting in the back row: this is a crude, slightly subtle, attempt to shuffle off all the pesky troublemakers into a small closet, and out of the public view. On they're on your own turf, cousin Billy-Bob, and his brass knuckles will "fix" the problem.
> > The specification is not as wrong as you are saying, just that > > it is the choice of the author of the specification.
> If someone made a bad choice, I am not obligated to follow it.
I remember that when I was implementing this part, I also wondered why '}' was missing but Mark gave me the same answer. I found *no* problems in the justification of Mark Crispin's choice. And I really see nothing difficult with the problem of '}' and no really additionnal cost in performance.
It seems that you are the only one to complain about the specification of IMAP protocol. All the grammar seems right to me. I found no ambiguity.
In article <etPan.3cff7ca8.6b8b4567.712e@homer>, DINH Viet Hoa <dinh-coeur.viet-fleurbleu.hoa-yingy...@free-sourire2.fr> writes:
> It seems that you are the only one to complain about the > specification of IMAP protocol.
... in public.
> All the grammar seems right to me. > I found no ambiguity.
There aren't really that many people to start with, who might be in a position where they might complain. And most people would choose simply to plow ahead, because they would deem -- reasonably -- that it would be a waste of time. And I tend to agree, with one exception: if someone starts dissin' in public, then I'm not going to remain seated in the peanut gallery. I'll be happy to contribute my own thoughts on the subject, and I could prove them too. If someone wants to dish things out, they'll just have to take some of their own.
Sam wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> In article <etPan.3cff3940.6b8b4567.4...@paralaplage.irisa.fr>, > DINH Viet Hoa <dinh-coeur.viet-fleurbleu.hoa-yingy...@free-sourire2.fr> > writes:
>> Whether it is a good or a bad choice, if you refer to a specification, >> you have to follow it, unless you claim your server explicitely as >> non-IMAP compliant.
> Look: everyone in front of you is jumping off a cliff. It's your turn > now.
He may jump or he may stay back. The only thing he can't do is stepping into a rabbit burrow and claim to be a cliff jumper.
BTW, I'm using courier imap, I'm happy with it and I agree that a mailserver should not try to fix broken MUAs. Nevertheless, Sams's approach to interprete specs is somewhat irritating (though I sympathize with it ;-), you just have to know. I guess it's a late result of that sheet pinned to the inside of his room's door with the one word printed upon. Theo
> > The specification is not as wrong as you are saying, just that > > it is the choice of the author of the specification.
> If someone made a bad choice, I am not obligated to follow it.
No of course not, you just say that you are not IMAP-compliant, then it's ok.
A similar example. The TV system in USA, NTSC is a bad choice (stupid compromises, Never Twice the Same Color or whatever it stands for). But you are totally free to make a receiver that uses better technology choices. (but you want be able to see much, but that doesn't matter since at least you are not implementing somones bad choices)
> Look: everyone in front of you is jumping off a cliff. It's your turn
now.
You are perfectly free to choose not to jump, but then you cannot call yourself a common hamster.
On Sat, 15 Jun 2002, 3-2-1 wrote: > On Tue, 11 Jun 2002, Terje Trane wrote: > > A similar example. The TV system in USA, NTSC is a bad choice (stupid > > compromises, Never Twice the Same Color or whatever it stands for). But you > > are totally free to make a receiver that uses better technology choices. > > (but you want be able to see much, but that doesn't matter since at least > > you are not implementing somones bad choices) > Why do you think NTSC is a bad Color TV System? > In contrast, I think it's the best in the world.
The "never twice the same color" stuff came from the bad old days of vacuum tube TV sets, where NTSC was indeed considerably less color-stable than PAL or SECAM sets. Even changing a channel required a complete readjustment to correct green (or purple) faces.
The advent of digital solid-state sets brought an end to that decades ago. Most people never adjust the color settings on their TVs from the factory defaults. A few dedicated videophiles get out the blue filters to adjust for color bars.
I admit to using a blue filter, but only to adjust the levels on the S-Video to RGB converter; my TV has RGB video input, but not S-Video. The TV's factory settings for TV and composite video are fine as-is even after 15 years.
Today, the argument for the superiority of PAL or SECAM has to do with the greater number of scan lines in the dozen or so TV systems used worldwide with PAL or SECAM color. However, those extra scan lines come at a cost: 50Hz instead of 60Hz update rate. I get a headache watching PAL in Europe because I can see the 50Hz flicker. As for SECAM...the less said the better; I can't see how anyone can claim that SECAM is any good.
> Do you know a better one?
Supposedly, the Brazilians (at least I think that it's Brazil) have the ultimate in analog. They use the 60Hz TV system M used in the Americas (including the US), South Korea, Japan, the Philippines, and a few other countries, but with PAL color encoding. It's called PAL-M.
However, with modern TVs, I doubt that there is a noticable difference between PAL-M and NTSC (which is only used with TV system M).
