beware of "Courier-IMAP"
Mark Crispin
its author states that he has no intention to make Courier-IMAP compliant:
> It's completely absurd. The parser in Courier-IMAP is a straightforward
> parser, so I treat [ and ] as distinct lexical units, so they are rejected
> when sent as part of an unquoted string. I'm not going to insert a bunch
> of spaghetti code, and break something, just to comply with completely
> nonsensical portions of IMAP4rev1.
-- Mark --
* RCW 19.190 notice: This email address is located in Washington State. *
* Unsolicited commercial email may be billed $500 per message. *
Science does not emerge from voting, party politics, or public debate.
Nicholas Lee
"Mark Crispin" <m...@CAC.Washington.EDU> wrote in message
news:Pine.NXT.4.30.000310...@Tomobiki-Cho.CAC.Washington.ED
U...
> The Courier-IMAP server is non-compliant with the IMAP specification, and
> its author states that he has no intention to make Courier-IMAP compliant:
>
> > It's completely absurd. The parser in Courier-IMAP is a straightforward
> > parser, so I treat [ and ] as distinct lexical units, so they are
rejected
> > when sent as part of an unquoted string. I'm not going to insert a
bunch
> > of spaghetti code, and break something, just to comply with completely
> > nonsensical portions of IMAP4rev1.
I must say that I'm rather displease that you have posted these comments (to
myself from the author of Courier imap that I was discussing with you
privately) to an open forum.
In fact I'd say it was rather irresponible and out of context. I might even
go so far as to say you are misrepresenting the discussion and using
bully-boy tactics.
Nicholas
Mark Crispin
1) Courier-IMAP rejected an atom with a [ character.
2) The vendor of Courier-IMAP claims that it is a client bug (in my code,
no less) to send an atom with a [ character.
3) The vendor of Courier-IMAP acknowledges that the IMAP specification
permits this, but states "I'm not going to insert a bunch of spaghetti
code, and break something, just to comply with completely nonsensical
portions of IMAP4rev1."
I have an obligation to report non-compliant servers and defiant vendors
who refuse to implement the specification. It is unfair to the dozens of
other vendors -- all of whom implement IMAP according to specification --
to be burdened by bug reports caused by a vendor who openly defies the
specification and claims that everybody else is wrong.
It has also come to my attention that he posts a so-called "client bugs"
list, which misrepresent problems in his server (or simply his failure to
understand IMAP) as being bugs in various clients.
On Fri, 10 Mar 2000, Nicholas Lee wrote:
> I must say that I'm rather displease that you have posted these comments (to
> myself from the author of Courier imap that I was discussing with you
> privately) to an open forum.
>
> In fact I'd say it was rather irresponible and out of context. I might even
> go so far as to say you are misrepresenting the discussion and using
> bully-boy tactics.
-- Mark --
Nicholas Lee
"Mark Crispin" <m...@CAC.Washington.EDU> wrote in message
news:Pine.NXT.4.30.000310...@Tomobiki-Cho.CAC.Washington.ED
U...
> There is no misrepresentation. The facts are clear:
I think you've completed missed the point. My email to you was private. I
feel somewhat offended that you took certain comments from a third party
that I directed to your attention and placed those in a public forum.
Ignoring time for delivery you seemed to judge and reply to my email within
an hour. Then without waiting further response (I was asleep) 11 mintues
later posted a rather negative message regarding that third party's product
to this forum.
I state again, what your motives might be. Taking private communications
out of context and using them in a public forum is somewhat irresponible.
I'm somewhat dishearten by your actions in this matter, particular for a
member of your standing in the community.
The fact of the matter was that I was presenting an analysis for improvement
of the IMAP spec. This was given to me by the courier imap author in
response to difficults I had discovered while installing his product and
attempting to use it with both pine (4.21) and outlook express.
Nicholas
Sam
Hash: SHA1
In article <Pine.NXT.4.30.000310...@tomobiki-cho.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> I have an obligation to report non-compliant servers and defiant vendors
> who refuse to implement the specification. It is unfair to the dozens of
> other vendors -- all of whom implement IMAP according to specification --
> to be burdened by bug reports caused by a vendor who openly defies the
> specification and claims that everybody else is wrong.
Oh, you're full of it, Mark. There are numerous interoperability problems
between many different clients and servers, and you know it. When it comes
down to it, I think what's really eating you is that you've finally
accepting the fact that all the interoperatibility problems that have
surfaced over the years are simply due to RFC 2060 being a very poorly
written spec, both from a readability and a technical standpoint. Nobody
can read that and implement anything right off the bat. You do not see the
same level of interoperability problems with any other wire protocol, be it
ESMTP, POP3, or anything else for that matter.
And when someone gets caught in a middle of those interoperatibility
problems, and ends up agreeing with my analysis that RFC 2060 is poorly
designed, you go off the deep end. Well, Mark, that's just too bad, and I
guess you'll just have to learn how to deal with some constructive
criticism, without getting personal and going bonkers, like that.
I can't help but mention another incident several weeks ago where a similar
issue cropped up with another IMAP client -- Mulberry's Mac client. But,
unlike yourself, that fella was very polite and courteous, and, after
hashing it over in E-mail, a couple of times, he made a few tweaks to his
code, and so did I, and everyone lived happily ever after.
But, when someone on a huge ego trip decides to act like a total jackass in
public, I don't think that that's kind of a behavior is going to encourage
much cooperation.
It seems that what's really getting your goat, Mark, is your decade-old fed
with Dan Berstein, of which I really couldn't care less. For years you've
satisfied your enormous ego by refusing numerous requests to support
maildirs, with some flimsy excuse. That's how you got your kicks. And now
that's no longer necessary -- people now have a reliable alternative to
UW-IMAP that is not the bloated monster that it is, and that just bugs the
hell out of you.
> It has also come to my attention that he posts a so-called "client bugs"
> list, which misrepresent problems in his server (or simply his failure to
> understand IMAP) as being bugs in various clients.
Grow up, Mark. Stop acting like a baby.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE4ym8O+3BFaxHnGY0RAhykAJ9EixentV/kLOMEZ72waHWX+yHBkwCgnFYJ
uDwbAf2Dlk+3zlY4KaIvLh4=
=cXU4
-----END PGP SIGNATURE-----
Lawrence Greenfield
debated here, I'm not prepared to defend or attack Mark. However, the
technical problems he raises are real problems. The current IMAP we
have may not be the perfect IMAP in all people's views, but it's the
specification we have after long amounts of debate and give and take,
and interoperability is important and is achieved with complying with
the spec.
Building an interoperable IMAP server _is_ hard---that's why we have
documents like RFC 2683, an excellent document on real world
implementation recommendations by Barry Leiba.
Personally, I'm very pleased to see another free IMAP server---I think
that's definitely for the best. I'd like to see it interoperate with
as many clients as possible.
I pointed out several interoperability gotchas with Courier IMAP
around three weeks ago in personal e-mail. Some of the issues to
raise in the Courier IMAP BUGS file are legitimate client bugs. Some
are not---and most issues are clearly dealt with in the specification.
Here's some of the clearer issues (the quoted text is from the
imap/BUGS file distributed with courier-imap-0.27):
> 1) Pine chokes on whitespace between BODY and [
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822" [".HEADER" / ".TEXT"] SP nstring /
"RFC822.SIZE" SP number / "BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring /
"UID" SP uniqueid
The only way of generating a "BODY" followed by a [ is the
"BODY" section [ "<" number ">"] SP nstring
rule.
section = "[" [section-spec] "]"
Since "section" MUST begin with a [, there can be NO whitespace
between "BODY" and "[".
> 3) Occasionally Pine sends a FETCH request with an invalid UID.
> This usually happens after you resume a postponed message, and
> send it. It looks like other IMAP servers simply ignore this
> error condition, however Courier-IMAP will return an error
> message, which Pine shows briefly on the status line. This is
> similar to the Netscape Communicator bug (see below), but not as
> bad.
Section 6.4.8
A non-existent unique identifier is ignored without any error
message generated. Thus it is possible for a UID FETCH command to
return OK without any data or a UID COPY or UID STORE to return OK
without performing any operations.
> 1) Netscape Communicator insists that the response in HEADER.FIELDS is
> terminated by a blank line, supposedly the end of message headers.
Section 6.4.5
The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
specifiers refer to the [RFC-822] header of the message or of
an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
field-name (as defined in [RFC-822]) names, and return a subset
of the header. The subset returned by HEADER.FIELDS contains
only those header fields with a field-name that matches one of
the names in the list; similarly, the subset returned by
HEADER.FIELDS.NOT contains only the header fields with a
non-matching field-name. The field-matching is
case-insensitive but otherwise exact. In all cases, the
[RFC-822] delimiting blank line between the header and the body
is always included.
Larry
Sam
Hash: SHA1
In article <Pine.NXT.4.30.000310...@tomobiki-cho.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> The Courier-IMAP server is non-compliant with the IMAP specification, and
> its author states that he has no intention to make Courier-IMAP compliant:
>
>> It's completely absurd. The parser in Courier-IMAP is a straightforward
>> parser, so I treat [ and ] as distinct lexical units, so they are rejected
>> when sent as part of an unquoted string. I'm not going to insert a bunch
>> of spaghetti code, and break something, just to comply with completely
>> nonsensical portions of IMAP4rev1.
Now, now, Mark, what exactly are you trying to accomplish, here? If I was
really interested in prolonging this pissing match, I would probably go
ahead and publish the entire exchange that took place, not just a single
isolated paragraph out of context, so that everyone could see for
themselves what the fuss is all about.
But, I'm not.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE4ydL9+3BFaxHnGY0RAhLuAKCJGdBmoN6ibxViXnlzbaSwnGQIWwCgmjme
Ys5yIhGm/tOon2J4ZzGT6h8=
=mrU8
-----END PGP SIGNATURE-----
ra...@adsl-151-203-22-73.bellatlantic.net
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>In article <Pine.NXT.4.30.000310...@tomobiki-cho.cac.washington.edu>,
> Mark Crispin <m...@CAC.Washington.EDU> writes:
>
>> who refuse to implement the specification. It is unfair to the dozens of
>> other vendors -- all of whom implement IMAP according to specification --
>> to be burdened by bug reports caused by a vendor who openly defies the
>> specification and claims that everybody else is wrong.
>
>Oh, you're full of it, Mark. There are numerous interoperability problems
>between many different clients and servers, and you know it. When it comes
Mark and I have disagreed about technical details in the past, especially
incompatibilities.
Publishing a known-non-compliant product, refusing to fix it, and getting
pissy when the refusal gets published is a problem. While Mark may have been
rude to publish notes from a private email, it's certainly legal and may have
even been appropriate.
>down to it, I think what's really eating you is that you've finally
>accepting the fact that all the interoperatibility problems that have
>surfaced over the years are simply due to RFC 2060 being a very poorly
>written spec, both from a readability and a technical standpoint. Nobody
>can read that and implement anything right off the bat. You do not see the
>same level of interoperability problems with any other wire protocol, be it
>ESMTP, POP3, or anything else for that matter.
Oh, my great aunt Petunia, are you a newbie.... "Easy to read", "easy to
implement" does not mean reliable, workable, complete, or even consistent.
>But, when someone on a huge ego trip decides to act like a total jackass in
>public, I don't think that that's kind of a behavior is going to encourage
>much cooperation.
I'm sure you've noticed this yourself....
--
Nico Kadel-Garcia
nka...@bellatlantic.net
Sam
Hash: SHA1
In article <slrn8cm6f2...@adsl-151-203-22-73.bellatlantic.net>,
ra...@adsl-151-203-22-73.bellatlantic.net () writes:
> Mark and I have disagreed about technical details in the past, especially
> incompatibilities.
>
> Publishing a known-non-compliant product, refusing to fix it, and getting
> pissy when the refusal gets published is a problem.
I agree. The user who reported this problem concluded that it was a Pine
bug, and asked to have it fixed.
> While Mark may have been
> rude to publish notes from a private email, it's certainly legal and may have
> even been appropriate.
Mark Crispin published one paragraph out of a rather drawn out E-mail
exchange; this was totally misleading and didn't really have much to do
with anything, I don't really have a problem with hashing this out
publicly, but certainly not in this manner -- with intentional
misrepresentation, inflammatory rhetoric, and complete disregard for the
issues at hand, which quickly degenerates into a pissing match. Leave me
out of it, please.
As I wrote, it looks to me that Mark Crispin is simply looking to pick up
the age-old feud he -- and others -- been having with someone else. I'm
not interested.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE4yyuQ+3BFaxHnGY0RAiRIAKClf9MUpuEuXYnBthobr5pSK5AIFwCg3Kc8
eO/UyicuvC5OzsNKwxnjvqQ=
=93oV
-----END PGP SIGNATURE-----
Sam
Hash: SHA1
In article <2000031203...@smtp3.andrew.cmu.edu>,
Lawrence Greenfield <le...@andrew.cmu.edu> writes:
> Since I don't know the details of the e-mail exchange that is being
> debated here, I'm not prepared to defend or attack Mark. However, the
> technical problems he raises are real problems.
He did not raise any technical problems. He was upset simply because I
dared to question the gospel of RFC 2060; and when I explained what the
problems in that document were to someone else, that someone else agreed
with my conclusions, considered it to be a Pine bug, and asked to have it
fixed, noting that at least two other IMAP clients work just fine.
I was prepared to go over those same issues again, but, I suddenly realized
that this would merely prolong a meaningless pissing match, and I would be
wasting my breath. It doesn't really matter, in the grand scheme of things.
I have no interest in actively participating in a pissing match. I can't
help it if someone else is hell-bent on starting one, the only thing I can
do is avoid wasting my time in it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE4yyip+3BFaxHnGY0RAqLrAJ0dxAAGuy3KcLVWWSKDMfXeNxf6hwCcCfSs
nOUu3iZLI0ggYqCaAyKgVg0=
=HgyZ
-----END PGP SIGNATURE-----
Nicholas Lee
<ra...@adsl-151-203-22-73.bellatlantic.net> wrote in message
news:slrn8cm6f2...@adsl-151-203-22-73.bellatlantic.net...
> Publishing a known-non-compliant product, refusing to fix it, and getting
> pissy when the refusal gets published is a problem. While Mark may have
been
> rude to publish notes from a private email, it's certainly legal and may
have
> even been appropriate.
As much as I hate to post another OT message, I feel I have to disagree
here. Its not a question of whether posting private email conversations is
legal or not. Its just not good practice or netiquette. He took something
from private conversation out of context and used that in a public forum to
discredit someone. For a member of the community such as himself this is
just not good behaviour.
Nicholas
Yiorgos Adamopoulos
>discredit someone. For a member of the community such as himself this is
>just not good behaviour.
I see two problems here:
- Problem #1 is Mark jumping on the gun whenever someone posts something
"against" what he has documented as being IMAP, or NFS with the UW
toolkit, or maildir. Well, this is Mark's personality and it cannot be
changed, the same way as my or any other's personality cannot be changed.
Yes he is a flaming gun, but also whenever he flames, I see technical
arguments from his side (not to add tha I collect his flames - I sort of
have the same behavior in our local ntua.* newsgroups for different
reasons).
- Problem #2 is the IMAP spec and how some choose to implement it. Well,
here there are two choices. Choice #1 says, you follow the spec no
matter how you disagree with it, and certainly you do not break it.
Choice #2 says *write and implement your own spec*. Just as Bernstein
did (for example) with QMTP and Maildir. If you do not like what is
already there (and cannot convice the inventor to do otherwise) present
your alternative and let the community decide what to use. But if you
stick to implement the standard, you are inexcusable if you don't
(because you *claim* to implement it). Simply stating that the IMAP RFC
has nonsensical requirement does not prove anything. The RFC has the
requirement, so you are required to follow it no matter what.
Otherwise write (and implement) your own RFC. Nobody will stop you on
that.
I too am working on similar things and try to put my thoughts into code. I
do not think that I will ever state X is done the "wrong" way in protocol
Y. The standard is there and I either follow it, extend it or write my
own. But I do not break the existing, *especially* just because I do not
like the personality of the inventor.
--
${talks}
Sam
Hash: SHA1
In article <slrn8coi74...@ithaca.dbnet.ece.ntua.gr>,
ad...@dblab.ece.ntua.gr (Yiorgos Adamopoulos) writes:
> In article <95289681...@shelley.paradise.net.nz>, Nicholas Lee wrote:
>>discredit someone. For a member of the community such as himself this is
>>just not good behaviour.
>
> I see two problems here:
>
> - Problem #1 is Mark jumping on the gun whenever someone posts something
> "against" what he has documented as being IMAP, or NFS with the UW
> toolkit, or maildir. Well, this is Mark's personality and it cannot be
> changed, the same way as my or any other's personality cannot be changed.
> Yes he is a flaming gun, but also whenever he flames, I see technical
Well, that's fine, but as long as you do not cross the line that he has
crossed. It's one thing to be a flamehead -- which is a fine Usenet
tradition, after all, that is beyond all reproach -- but it's a completely
different situation when you take things out of context, and completely
misrepresent someone else in a totally underhanded and cowardly manner.
This is not flaming, this is something quite different.
> - Problem #2 is the IMAP spec and how some choose to implement it. Well,
> here there are two choices. Choice #1 says, you follow the spec no
> matter how you disagree with it, and certainly you do not break it.
> Choice #2 says *write and implement your own spec*. Just as Bernstein
> did (for example) with QMTP and Maildir.
You are not entirely 100% correct. DJB did break the letter of ESMTP.
Qmail advertises 8BITMIME, but doesn't do anything about it -- it will send
8-bit mail to non-8bit mailers without downshifting it to quoted-printable.
Now, I do have my own problems with Qmail, and DJB's reasons for doing that
happen to be 100% analogous -- he's stated that the whole 8BITMIME business
is just plain dumb -- yet you do not see me making a spectacle out of it on
Usenet and on private mailing lists. I have flamed DJB in the past over
this, but I draw the line at twisting someone else's words in order to
further my own personal agenda.
> If you do not like what is
> already there (and cannot convice the inventor to do otherwise) present
> your alternative and let the community decide what to use. But if you
> stick to implement the standard, you are inexcusable if you don't
> (because you *claim* to implement it). Simply stating that the IMAP RFC
> has nonsensical requirement does not prove anything. The RFC has the
> requirement, so you are required to follow it no matter what.
> Otherwise write (and implement) your own RFC. Nobody will stop you on
> that.
Well, this is what that crowd would _like_ for you to believe the issue is,
but it's not. It's a red herring. What's really happening is that people
are simply having a major cow because someone dared to diss IMAP4rev1,
that's all there is to it. Every time I run into something dumb in RFC
2060, and have to put in yet another workaround due to its weirdness, I
document it, and it's now grown to be quite a collection of bloopers.
Apparently, some egos got slightly bruised because of nothing more than
just a silly web page. And this latest issue will be just another footnote
in the next revision.
> I too am working on similar things and try to put my thoughts into code. I
> do not think that I will ever state X is done the "wrong" way in protocol
> Y. The standard is there and I either follow it, extend it or write my
The fact that something is a "standard" does not mean that everyone must
agree that it makes sense, and does not exempt the "standard" from being
subject to criticism. That may be what SOME people would like you to
believe, but I refuse to accept that line of thinking.
> own. But I do not break the existing, *especially* just because I do not
> like the personality of the inventor.
Congratulations -- you've completely fell for their trap. If I were to
have actually done what you've been led to believe I've done, neither Pine,
nor Outlook Express would work at all, with Courier-IMAP. Well, to be
technically correct, Pine would break with the next revision, because I
haven't yet revved since the conflict flared up (and I was never known for
making positive comments vis-a-vis Microsoft). But, it won't. One thing
I've realized is that I don't think that I really want to earn the same
reputation as UW-IMAP. In fact, I wrote Courier-IMAP precisely because of
UW-IMAP's reputation of ignoring repeated requests for compatibility with
software written by someone who's been feuding with UW-IMAP's authors.
And I'm certainly not going to go down the same path myself.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE4zIzU+3BFaxHnGY0RApcHAJoD1Q7Wj2S7B4il9u9GitSUo+l0WQCeOiUT
TkRrFm8kdX5A+kMxPYibFi4=
=nqgh
-----END PGP SIGNATURE-----
ra...@adsl-151-203-22-73.bellatlantic.net
>Well, this is what that crowd would _like_ for you to believe the issue is,
>but it's not. It's a red herring. What's really happening is that people
>are simply having a major cow because someone dared to diss IMAP4rev1,
>that's all there is to it. Every time I run into something dumb in RFC
>2060, and have to put in yet another workaround due to its weirdness, I
>document it, and it's now grown to be quite a collection of bloopers.
Then stop kvetching and *POST IT*. You're starting to sound like a meower....
--
Nico Kadel-Garcia
nka...@bellatlantic.net
Sam
Hash: SHA1
In article <slrn8cpnns...@adsl-151-203-22-73.bellatlantic.net>,
ra...@adsl-151-203-22-73.bellatlantic.net () writes:
> On 13 Mar 2000 06:38:17 GMT, Sam <s...@email-scan.webcircle.com> wrote:
>
>>Well, this is what that crowd would _like_ for you to believe the issue is,
>>but it's not. It's a red herring. What's really happening is that people
>>are simply having a major cow because someone dared to diss IMAP4rev1,
>>that's all there is to it. Every time I run into something dumb in RFC
>>2060, and have to put in yet another workaround due to its weirdness, I
>>document it, and it's now grown to be quite a collection of bloopers.
>
> Then stop kvetching and *POST IT*. You're starting to sound like a meower....
I have posted it on the project's web page, and it's included in the source
tarball. It's been out there for a while.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE4zOpy+3BFaxHnGY0RAjU3AJ0eoehJXqo5qkkk1+vvtSMikVPpjgCgvwC0
ueXxTeqfHvpi6h0BJiN6h5U=
=1zAg
-----END PGP SIGNATURE-----
Vladimir A. Butenko
<s...@email-scan.webcircle.com> wrote:
> Well, this is what that crowd would _like_ for you to believe the issue is,
> but it's not. It's a red herring. What's really happening is that people
> are simply having a major cow because someone dared to diss IMAP4rev1,
> that's all there is to it. Every time I run into something dumb in RFC
> 2060, and have to put in yet another workaround due to its weirdness, I
> document it, and it's now grown to be quite a collection of bloopers.
> Apparently, some egos got slightly bruised because of nothing more than
> just a silly web page. And this latest issue will be just another footnote
> in the next revision.
Look. Calm down, please. You are not the only person Mark attacted here
:-). And I'd agree that taking info from a personal E-mail and posting it
on a public forum is a BAD thing. But be professional. Try to separate
personal relations/customs/etc. from the technical side of the things.
a) Yes, IMAP standard is not perfect. But it is a complicated protocol,
and for the level of its complexity - it is written pretty well. I bet you
have never read LDAP RFCs :-). If you want a perfect standard, find
someone who DOES NOT implement his/her own server or client and make that
person re-write the standard. Otherwise some things that are obvious for
the implementor, but completely unknown for others inevitably slip
through. Mark did a very good job on the IMAP standard - again, just read
the LDAP RFCs that do not even care to explain you what the whole thing is
all about.
b) Standards are called standards because they are standards. Yes, both
client and server vendors sometimes do not get what the RFC author meant,
but if they then find that the standard really SAYS what he meant, they
should comply. Otherwise the whole sense of having a standard vanishes.
For example, our implementation of the ACAP server was found to be
incompatible with a client that was designed by one of ACAP spec
co-authors. But we did what the standard SAID, and the author itself
agreed, and had to change his code, or find a workaround, and finally we
started to talk about drafting a new version of the ACAP specs, because
the standard actually said not what the authors meant. That's how the
things work in the world of standards. And this is why all standards start
their lifes as drafts so everybody can try and comment and minimize the
risk of mis-understanding in future.
c) I personally do not like the way IMAP spec treat spaces. Most of the
client parsers simply scan spaces before any lexem, so only when we
started to deploy our servers in universities that use pine, the problem
of our server inserting spaces where the IMAP standard does not require
them came up. Yes, someone wrote to Mark, because Netscape, Outlook,
Mulberry had no problem - only pine had. And Mark posted a similar note
here, called "CommuniGate Pro IMAP bug". Whatever our feels were about
this way of handling things (instead of writing to our tech. team
directly, as all other vendors do) - from the TECHNICAL point of view Mark
was right, and the IMAP standard says nothing about a space in that place
- so we had to fix it immediately and release a new version out of
schedule. Because it was OUR fault, and if we say that we comply with
IMAP4rev1, we have to comply.
d) there are many other issues in IMAP specs that can be discussed. But
they should be discussed in the professional manner, and not in starting
the "pissing match" that you always say you do not want to participate in.
And till those issues are formulated in some IMAP5 or whatever, you either
follow the written IMAP4rev1 standard, or you say that your server does
not support that standard.
> The fact that something is a "standard" does not mean that everyone must
> agree that it makes sense, and does not exempt the "standard" from being
> subject to criticism. That may be what SOME people would like you to
> believe, but I refuse to accept that line of thinking.
Standards are not equal to the law. One may think that he can change the
laws one southern state by making oral sex on public, and then protesting
from the prison cell, demanding the change of that law. The RFC standards
are neither about the moral standards, nor about political issues, - they
are about interoperability. The "social activism" is not a working method
here. If you want to change the things without waiting for a new standard,
and/or you want to push the development of a new standard - it's doable
and it's simple: if you have a client vendor who also needs a different
protocol, you can:
a) present a new keyword in your IMAP CAPABILITY response:
COURIERMODE, for example.
b) let a client issue a special command, let's say COURIERMODE ON.
c) do whatever you want with the IMAP standard after that - i.e. work in
your own protocol that your server and that client both understand.
But if the client has not issued that command, the server should work
strictly as described in RFC2060, otherwise it won't be an IMAP server.
> Congratulations -- you've completely fell for their trap. If I were to
> have actually done what you've been led to believe I've done, neither Pine,
> nor Outlook Express would work at all, with Courier-IMAP.
That would be a bad thing. The result of that thing would be inferrior
popularity of your server - compared to a standard-compliant IMAP4rev1
server.
> making positive comments vis-a-vis Microsoft). But, it won't. One thing
> I've realized is that I don't think that I really want to earn the same
> reputation as UW-IMAP. In fact, I wrote Courier-IMAP precisely because of
> UW-IMAP's reputation of ignoring repeated requests for compatibility with
> software written by someone who's been feuding with UW-IMAP's authors.
Could you please list those requests? We have now aprx. 5mln seats sold
last year. Aprx 10% of those are using IMAP. We would hear about any
problem with any IMAP software. And I should tell you - we have no
"improvements" of the IMAP4rev1 in our servers. It's strictly on the
standard, and those clients do follow the standard. So I'd be very
interested in learning about the problems the current standard presents to
the current clients.
> And I'm certainly not going to go down the same path myself.
If you want to DEVELOP a BETTER standard - let's discuss it. Right here.
As you can see, there are many IMAP4rev1 extensions that are documented in
RFCs that do not have Mark's name on them. So, I do not understand why you
think that the only way to implement a better standard is to screw up the
existing one: that's definitely has nothing to do with Mark's attitude.
Hydrogen fuel is better than gas. So, let's add hydrogen pumps on the gas
stations and encourage car manufacturers to build H-powered cars
(clients). But if you start to put Hydrogen instead of gas into all cars
that stop by because your sign reads "gas station" - I would seriously
doubt that you will be able to earn better reputation than UW-IMAP.
--
Vladimir Butenko
Stalker Software, Inc.
Mark Crispin
> Whatever our feels were about
> this way of handling things (instead of writing to our tech. team
> directly, as all other vendors do) - from the TECHNICAL point of view Mark
> was right, and the IMAP standard says nothing about a space in that place
> - so we had to fix it immediately and release a new version out of
> schedule. Because it was OUR fault, and if we say that we comply with
> IMAP4rev1, we have to comply.
If it makes you feel any better, I've been on the other side, and with
MUCH more embarassing problems. It's not a pleasant situation.
Unfortunately, as you've discovered, the only way out is to make an
emergency release.
I strongly recommend that you go to the periodic IMC IMAP interoperability
bakeoffs. This is the best way to avoid such problems in the future. I
don't know when the next one will be held, but it should be announced
here. It's always better to get interoperability problems discovered and
resolved in pre-release code!
> Could you please list those requests?
I think that what he is talking about is that I don't want to get into the
business of supporting the "maildir" format. There are at least three
third-party c-client drivers available for maildir. If someone uses
maildir, they can go to one of those third parties for code and support.
I believe that it is infeasible to build maildir support that scales well
(e.g. does not exhibit performance problems with a moderately large
mailbox of 2000 messages) and also does not violate a major rule of either
maildir or IMAP. It's a no-win situation for me; and therefore I choose
to allow the maildir enthusiast community to do their own development,
distribution, and support of maildir IMAP code.
Mark Crispin
> > Then stop kvetching and *POST IT*. You're starting to sound like a meower....
> I have posted it on the project's web page, and it's included in the source
> tarball. It's been out there for a while.
That's where my material came from, and your statements are incorrect.
Please implement the specification, not your notion of what the
specification should be.
If you want to see a specification changed to conform to your views (such
as forbidding "[" in atoms), please follow the process for doing so.
Please make sure you have your facts right before you attack other
people's software.
Vladimir A. Butenko
<Pine.NXT.4.30.000313...@Tomobiki-Cho.CAC.Washington.EDU>,
Mark Crispin <m...@CAC.Washington.EDU> wrote:
> On Mon, 13 Mar 2000, Vladimir A. Butenko wrote:
> > Whatever our feels were about
> > this way of handling things (instead of writing to our tech. team
> > directly, as all other vendors do) - from the TECHNICAL point of view Mark
> > was right, and the IMAP standard says nothing about a space in that place
> > - so we had to fix it immediately and release a new version out of
> > schedule. Because it was OUR fault, and if we say that we comply with
> > IMAP4rev1, we have to comply.
>
> If it makes you feel any better, I've been on the other side, and with
> MUCH more embarassing problems. It's not a pleasant situation.
> Unfortunately, as you've discovered, the only way out is to make an
> emergency release.
I do not see anything unpleasant in the situation itself: it's our job.
It's virtually impossible that anyone (including the author :-) can
implement EVERYTHING exactly as outlined in the docs. Some things can
be misunderstood, some can be simply overlooked. And when we get the
problem report, we investigate and fix the problem.
I grepped the http://www.stalker.com/CommuniGatePro/History.html file
for "Bug" and "IMAP". There are 16 of them there (over the last 2 years),
though there were only 1 since that "CGatePro IMAP Bug" report you posted
many months ago, and I doubt if it counts as a bug :-). But who knows -
one can run into some problem in future, and that's what CGatePro Logs are
for, and that's what we are for: to fix the things if something is wrong.
I do not see anything unpleasant in these things: bugs do happen, the
problem is how many of them are there, how important they are and how
quickly they are fixed.
> I strongly recommend that you go to the periodic IMC IMAP interoperability
> bakeoffs. This is the best way to avoid such problems in the future. I
> don't know when the next one will be held, but it should be announced
> here. It's always better to get interoperability problems discovered and
> resolved in pre-release code!
While I'd enjoy to go to such a forum myself (if time permits :( ), I do
not think that this is the best way to fix the things. We work slightly
different: when a problem is reported, it's investigated immediately, and
the fix appears in the next release - at least, the next beta release that
go out every 1-2 weeks. I think that you do the same, and the main purpose
of the forum is to settle the ideological misunderstandings, draw a way
for new development, and solve those interoperability problems that go
beyond the written specs. For example, I'd like to see the eyes of those
Microsoft fellows who made their clients open 20 connections for one
session... :-) and :-(
> > Could you please list those requests?
>
> I think that what he is talking about is that I don't want to get into the
> business of supporting the "maildir" format. There are at least three
> third-party c-client drivers available for maildir. If someone uses
> maildir, they can go to one of those third parties for code and support.
>
> I believe that it is infeasible to build maildir support that scales well
> (e.g. does not exhibit performance problems with a moderately large
> mailbox of 2000 messages) and also does not violate a major rule of either
> maildir or IMAP. It's a no-win situation for me; and therefore I choose
> to allow the maildir enthusiast community to do their own development,
> distribution, and support of maildir IMAP code.
I can argue with you that directory-based solutions can be made scalable,
but this is not the point: the internal structure of some IMAP server has
nothing to do with the IMAP protocol specs themselves. That's I'm afraid,
the Sam's problem here: he had some disagreements with you as the designer
of one of IMAP servers, and that's completely up to him - he can create an
IMAP server that has nothing in common with your server, and if it is a
better server -so let it be so.
But then he passes that disagreement with Mark-designer to
Mark-protocol-maintainer, and this is completely different issue. One can
use a completely different approach and code to develop a server, but as
long as it complies with IMAP4rev1 specs, it's an IMAP4rev1 server. On the
other hand, if one takes imapd-uw code and changes just one line of it so
it would not comply (be that person name Sam or Mark) - that server will
not be an IMAP4rev1 server, and that's it.
What I wanted to see posted is not some problems of implementing this or
that in someone's code, but the problems in the IMAP4rev1 protocol itself,
and the requests for improvements of that protocol. Imporvements of a
particular server code is a completely different issue, and should be
discussed on that server support mailing list/forum.
> -- Mark --
Lyndon Nerenberg
Vladimir> permits :( ), I do not think that this is the best way
Vladimir> to fix the things. We work slightly different: when a
Vladimir> problem is reported, it's investigated immediately, and
Vladimir> the fix appears in the next release - at least, the next
Vladimir> beta release that go out every 1-2 weeks. I think that
Vladimir> you do the same, and the main purpose of the forum is to
Vladimir> settle the ideological misunderstandings, draw a way for
Vladimir> new development, and solve those interoperability
Vladimir> problems that go beyond the written specs. For example,
Which means your fixing things in a reactionary mode, and without
the hive knowledge present when you get a bunch of experienced
engineers together. Being able to discuss problems in a group,
especially when there is more than one "right answer" to the
problem is invaluable. You will also find your software taking
a much severer beating at the interop then it *ever* will in
the field. For our SMS server product, about 80% of the bug fixes
that went in were a direct result of IMC interop testing. A lot
of these were edge cases that you won't likely run into in the
field, but *will* see when you're testing against other peoples
alpha software. And then there are those of us mercenaries who
while away the time telneting to the servers and doing "unexpected"
things. (My t/golf shirt collection has grown considerably as a
result of these activities ;-)
Vladimir> I'd like to see the eyes of those Microsoft fellows who
Vladimir> made their clients open 20 connections for one
Vladimir> session... :-) and :-(
Even more reason to attend.
IMAP is a complex and subtle protocol. Any vendor of IMAP
products wouldn't be taking their job seriously if they
didn't attend the IMC interop events on at least a semi-
regular basis.
--lyndon
Vladimir A. Butenko
<lyn...@MessagingDirect.COM> wrote:
OK, I agree with all that, but I still cannot get the point.
a) there are already several thousand CGatePro server installed, and some
- on major ISPs, so it's not a problem to test any alpha-mode software
against it.
b) the CGatePro server software is available for free testing for 18
platforms directly from http://www.stalker.com/CommuniGatePro/ and I do
not see the problem in testing against it. Several E-mail client vendors
already use it as a "testbed" not only for their alpha versions, but for
the development process, too.
What the difference will it make if, say, I appear on some forum? I'm not
an IMAP server and will break as soon as someone puts a signle IMAP
command into any of my "outside world connections". If someone wants to
test something against our servers and for any reason cannot deploy it on
one of their own machines - just call 800-262-4722 and ask for Philip and
ask him to set a test account on one of our own CGatePro servers - there
are at least 3 avaiable on the "visible" Internet, and we can even create
an account on a Dynamic Cluster, too - but that's unlikely to make any
difference for the tester. Last time I looked, mail.stalker.com had about
half a dozen accounts created for varios Mail-client developers.
If there is a PROBLEM, and that problem has to be discussed with client
vendors - then, of course, a forum of some kind is a must. But how for God
sake can we find interoperability problems if we just sit together
somewhere and start to chat? I really do not get it, please explain.
> Vladimir> I'd like to see the eyes of those Microsoft fellows who
> Vladimir> made their clients open 20 connections for one
> Vladimir> session... :-) and :-(
>
> Even more reason to attend.
Yes, because there is a KNOWN problem. And it is of some interest for all
server vendors, not to Stalker only.
> IMAP is a complex and subtle protocol. Any vendor of IMAP
> products wouldn't be taking their job seriously if they
> didn't attend the IMC interop events on at least a semi-
> regular basis.
I do undrestand that it's kinda strange that we do not attend your
meetings, and I would take it as a good pitch for that conference, but
while you may say that we do not take our job seriously, I must say that
IMAP code is.. let me check.. - just 5% of CGatePro code. And it does not
create any problem neither to us, nor to our clients. While there are much
more serious issues and portions of the code that are much more
complicated than IMAP with all its extensions - and those things do
require our full attention - S/MIME incorporation, distributed LDAP,
Calendaring, WML - that's a huge list of things under active development
now.
This is all not to say that I do not see a reason for such meetings, but I
just want to know - what exactly we want to discuss there, what problems
do exist now, and - since we are in E-mail messaging business - why all
this cannot be discussed via E-mail or on Usenet?
Call me old and lazy, but if someone has to cross 11 time zones every 2
months and to participate in several Expos all over the globe, that person
inevitably developes a habbit of using E-mail and Usenet and asking
carefully what one more flight is needed for...
If I only could explain this to the cops, too - that I HAVE to drive fast,
because I'm tired of plains.... %-)
> --lyndon
Nicholas Lee
"Vladimir A. Butenko" <but...@stalker.com> wrote in message
news:butenko-1303...@stalker.gamma.ru...
The issue that has given rise to this thread is essentially to provide
explicit tokinisation for at least the password field, but I might suggest
given the "Which clients canNOT hndle '@' in authentication identifiers"
thread that tokinising this might be worthwhile as well.
I was having a problem because the '[]' are use as tokin limiters (MIME
stuff) else where in the protocol spec where as they where not 'special'
characters in the password auth field. For various reasons Sam at this
stage treats [] as distrinct tokin limits where every. (Personally I think
his reasons that it reduce code bloat are extremely valid.)
The fix he gave me for including [] in the password auth field is to
stringify the field, ie. "foo[]bar". Once this is done I managed to get my
"telnet localhost imap" testing to work, outlook express worked regards,
but pine using the complete spec doesn't.
I can only say IMO that having a token limiter in one part of the protocol
stream but not in another other part, would seem to increase the code bloat
and maintance requirements. Of course not being a imap server authour I
can't say this exactly. Adding four bytes (tokinising the login id and
password auth fields) certainly in this case seems worth while.
Of course back to the topic on hand, the thing that pissed me off about
Mark's actions is he took a paragraph out context and used it to extend his
agenda. I don't care if he thinks he's doing in the public good or other
people accept this . It's bad behaviour and I'm going to tell him off for
it. There are more civil ways of doing this without resorting to being a
bully-boy.
Nicholas
Lyndon Nerenberg
Vladimir> discussed with client vendors - then, of course, a forum
Vladimir> of some kind is a must. But how for God sake can we find
Vladimir> interoperability problems if we just sit together
Vladimir> somewhere and start to chat? I really do not get it,
Vladimir> please explain.
Vladimir, it's an interop event. 80 engineers in a large room with
a large ethernet and a large number of computers running a large
number of client and server implementations, all making sure they
can talk to each other. [Note that sales, marketing, press, and other
non-engineering scum are explicitly forbidden from attending ;-)]
There is very little chatting going on. In fact, if you hear
someone talking it means they found a bug.
Since these are all engineers, you're almost guaranteed that they
have source to their products with them. Thus, things gets fixed
in minutes, and the fixes can be tested against everyone elses code
very rapidly.
One example of this involved early deployments of the SASL DIGEST-MD5
mechanism. At the interop last March there were three or four vendors
working on this. We discovered quite quickly that there were some
vast differences in interpretation of some parts of the spec. Having
a group of engineers in the same room we were able to quickly break out
and identify the issues, propose a solution, implement that, and see
if it got us any further along. All inside of an hour. If we had tried
to do that by email it a) probably never would have happened to begin
with and b) still be a work in progress.
Interop events are invaluable for this sort of thing, and I stand
completely behind my statement about serious vendors attending
them. And that's not a bullet aimed at you. It sounds like you've
not been to one, so it's hard to appreciate just how valuable they
are. (And for those of us who have attended the IMC IMAP events
over the years, we have noticed a *direct* correlation between participation
and product quality. It's amazing to see how the quality of a product
has improved by the second time a vendor shows up at the event. This
is a Good Thing for everyone.)
--lyndon
Nicholas Lee
U...
> I believe that it is infeasible to build maildir support that scales well
> (e.g. does not exhibit performance problems with a moderately large
> mailbox of 2000 messages) and also does not violate a major rule of either
As a point of interest, I have several mailbox at stage with near a 1000
message. Many with large attactments. I merged (copied) a few them into one
mailbox giving me 2060 messages, about 34 megs worth.
Both Outlook express and pine (4.21) have no issue with this mailbox at all.
Pine opens the mailbox instantly having never seen it before and of course
outlook express goes though the process of caching the headers which takes a
little while.
It might be noted that this is currently an semi-loaded K6-2 400 with
128megs of ram. With only my mail box being open. However I can't see how
having too parse a 2000 mbox format message of size 25-34 megs is going to
be fast (and saver) than the file system and maildir format. Worse case you
use something liek Resifs (sp?) to deal with all the small files.
Of course I'm using courier-imap.
Nicholas
Lyndon Nerenberg
Nicholas> The issue that has given rise to this thread is
Nicholas> essentially to provide explicit tokinisation for at
Nicholas> least the password field, but I might suggest given the
Nicholas> "Which clients canNOT hndle '@' in authentication
Nicholas> identifiers" thread that tokinising this might be
Nicholas> worthwhile as well.
Sorry, I wasn't clear about this. It's not a protocol issue, it's
a UI issue. The UIs of some (very) popular IMAP and POP clients
arbitrarily throw away any authentication string data entered
after an '@' character, along with the '@' character itself.
Thus, (imagine you're looking at a GUI login/password dialog
box) if I enter 'lyn...@messagingdirect.com' in the login
field of the dialog, the client throws out the '@messagingdirect.com'
part and tries to log me in as 'lyndon' (which is not my authentication
id on the server).
--lyndon
Mark Crispin
> You forgot to mention one thing - the OS you are using. I guess that you
> are doing this on Linux, and Mark spends most of his time on - let me
> guess - Solaris :-). The speed of directory scan varies a lot on those
> platforms.
Not Solaris, but your point is correct. On some platforms, doing a stat()
on 2000 files in a directory takes 30 seconds, not 3 seconds. Ouch.
It quickly gets worse. If you are lucky, you can get the IMAP
internaldate and rfc822.size from the stat() call. But, that assumes that
the messages are stored in RFC822 format, not UNIX format, meaning CR/LF
newlines instead of LF newlines. If you don't have some sort of index
file (ala Cyrus), you end up having to open and read the file to count the
newlines. A lot of clients do "FETCH 1:* FAST"...oh dear...oh my...
You also should have an index file to store envelopes and body structures,
so you don't have to open the file. Many filesystems serialize path
references, so lots of consecutive opens are a problem. Yes (shudder),
there are clients which do "FETCH 1:* ALL" or "FETCH 1:* FULL".
So, you want to avoid doing a stat() at all; meaning that you have some
other way of discovering which objects from readdir() are files (messages)
and which are directories (subfolders). Again, the index file.
That's a lot of work for the index file to do. One reason that my mx
format is not encouraged is that it didn't go far enough and failed to
elimate the stat(). mx and mbx were simultaneous experiments, and mbx
kicked mx's rear end by two orders of magnitude. That's why work on mx
was abandoned with it half-finished.
The problem with an index file in the maildir context is that it defeats
one of the primary advertised capabilities of maildir: the use of
filesystem primitives to do locking (and hence NFS safety). So, an index
file, which is precisely what maildir tries to avoid, is probably out of
the question. What maildir does is store lots of stuff in the file names,
taking advantage of readdir() being much cheaper than the stat(). But you
can only cram so much here; and you have to interact with other maildir
software.
It is a set of difficult design tradeoff decisions that I don't wish to
make; no matter which one I choose, someone will be unhappy. That's why
it's better to let the maildir enthusiasts develop their own c-client
maildir drivers.
Mark Crispin
> Not Solaris, but your point is correct. On some platforms, doing a stat()
> on 2000 files in a directory takes 30 seconds, not 3 seconds. Ouch.
I should add that there's worse than just stat(). I just ran some quick
tests.
What really takes forever is copying 2000 files, because of the
serialization of open() on most filesystems. On most systems, it's much
faster to copy a 2MB file than to copy 2000 1KB files. On my system, it
came out to be 2 seconds vs. 103 seconds!
Deleting 2000 files took 80 seconds. The more messages you expunge, the
slower it is with a one-file/one-message format, and the faster it is with
a flat file format.
Renaming 2000 files, such as what you would have to do in maildir with a
build flags change if you store flags in the file name, took 93 seconds.
Big ouch.
Mark Crispin
> the file, it's still a "stat" call. And almost all mail clients want the
> to know the size of the message when they scan the mailbox.
Yes, which is why I made a mistake in my mx experiment by depending upon
stat() to get the size instead of storing it in the index. I didn't
realize how slow stat() could be.
Cyrus did not make that mistake; it also stores envelopes and body
structures in the index file. I think that Cyrus pretty much maximizes
the performance that you can squeeze out of one-file/one-message formats,
and they did a great job.
> And this still does not solve the problem of using a cluster when several
> clients can access the store from different servers
And, of course, Cyrus just punts on that entirely by outlawing NFS.
> mdir helps to avoid
> file locks (if it does not use index files), but does not help to
> synchronise changes.
Which is why we use locks in the first place! ;-)
> That's the problem only for the servers that rely on other software for
> mail delivery/automatd processing. But the point is clear, and I hope that
> all of us should agree:
Yes, I agree completely with your (a)-(e).
> There is, though one case that came to my mind, and it can become more and
> more important these days. Some of our clients said that they chose mdir
> for only one feature. It has nothing to do what we have discussed here
> before. THis feature is complete transparency.
Yes, transparency is very important, and often is neglected.
c-client is "mostly" transparent with traditional UNIX mailbox format; the
">" is not needed unless the line really looks like a UNIX mailbox header
line.
However, I agree this is an issue with traditional UNIX mailbox format,
and it's one of the big reasons why I never liked it.
mbx (the current favorite) and mtx (the old Tenex/TOPS-20 format) are
guaranteed fully transparent, even for binary data. I expect to be doing
some work soon to bum extra performance out of mbx format. It used to be
much faster than traditional UNIX format, but after the work I did to bum
performance in the traditional UNIX format it's now only "somewhat
faster". So I need to do some hacking to restore the big performance
advantage of my favorite format... ;-)
tenex format is transparent for normal text; in spite of the name, it's
actually a UNIXified mtx format (originally used by the UNIX port of MM)
that uses UNIX-style bare LF newlines instead of CR/LF. So its not
transparent if you care about CR and LF transparency and/or binary.
mbx, mtx, and tenex all allow shared read/write access, but they require
the ability to synchoronize updates and that means no NFS. Even when you
get locking out of the way, the inode vs. data cache problem over NFS will
still bite you.
mbx has the additional win that it allows shared expunge. That's great
for people who leave an IMAP client running 24/7, and then want to run an
IMAP client on their mail someplace else. For many folks at UW, it's
their office system that runs an IMAP client 24/7, for me, it's my home
system...
Vladimir A. Butenko
<nj.le...@kiwa.co.nz> wrote:
> "Vladimir A. Butenko" <but...@stalker.com> wrote in message
> news:butenko-1303...@stalker.gamma.ru...
> > In article
> >
> <Pine.NXT.4.30.000313...@Tomobiki-Cho.CAC.Washington.EDU>,
> > Mark Crispin <m...@CAC.Washington.EDU> wrote:
>
> > What I wanted to see posted is not some problems of implementing this or
> > that in someone's code, but the problems in the IMAP4rev1 protocol itself,
> > and the requests for improvements of that protocol. Imporvements of a
> > particular server code is a completely different issue, and should be
> > discussed on that server support mailing list/forum.
>
> The issue that has given rise to this thread is essentially to provide
> explicit tokinisation for at least the password field, but I might suggest
> given the "Which clients canNOT hndle '@' in authentication identifiers"
> thread that tokinising this might be worthwhile as well.
Hmm. Try to look at it from the other side, OK. How long did it take for
major client developers to avoid stripping off the "@xxxx" things from the
account name? As has been already noted here, even 4.5 versions of those
products still do it (though they do not do it for me, I have to say). Now
you want to change the way the password field is sent. Look - they did not
fix the problem that at least 100,000 people have (and those people did
write to them, not only to the server vendors), and you want them to
change something to make their clients work with just one server that has
no installed base (at least, not now).
That's simply won't work. You cannot EXTEND a protocol by breaking it
compatibility with the original one. All you can do is to create a NEW
version of the protocol, or the new protocol completely. Not a bad thing,
but the question is - is anybody gonna support it? So, the changes you are
talking about are changes that can be made in a NEW protocol only, and
given the time it took for major players to implement at least SOME IMAP
functionality, I would say that we can disccus the NEW protocol, but we
are unlikely to see it deployed during the next 5-10 years.
This is why my position is: stay with whatever is specified in the current
standard, and invest the development efforts to the extensions, not to a
completely new protocol. I'd say that designing a new, not
backward-compatible protocol is worth doing when it is realized that the
current one prohibits the further development. It was like switch from POP
to IMAP - it's hardly possible to "extend" the POP protocol to give it
IMAP functionality, so a new protocol was worth developing efforts and all
troubles of deploying it. Mark was doing IMAP for over 10 years (correct
me if I'm wrong here), and IMAP started to play SOME role on the
marketplace only 2-3 years ago. When I made a presentation of IMAP
protocol (thanks, Terry for the papers) on Macworld'97 most of the
audience heard about IMAP for the first time.
And now you (and Sam) suggest to, actually, develop a NEW protocol - i.e.
enter the same 10-years cycle - and for what? For better parsing of some
lexems in IMAP?! Please, get real.
> I was having a problem because the '[]' are use as tokin limiters (MIME
> stuff) else where in the protocol spec where as they where not 'special'
> characters in the password auth field. For various reasons Sam at this
> stage treats [] as distrinct tokin limits where every. (Personally I think
> his reasons that it reduce code bloat are extremely valid.)
IMAP is NOT a laguage. While one can try to deploy a "traditional"
yacc-style parser for it, there are many catches there, because it is
place-dependent. There are no "atoms" and "special symbols" there, in the
strict sense of those terms. A regular parser that just calls "getLexem"
function would fail in many places there, as it would fail for most of
Inet protocols - SMTP, for example.
For some people - it's a very bad thing, because it's not what they EXPECT
to see. That's just a question of selecting the right tool for the job. A
generic, programming-language-style lexical analizer is not a right tool
for dealing with IMAP protocol command parsing.
> The fix he gave me for including [] in the password auth field is to
> stringify the field, ie. "foo[]bar". Once this is done I managed to get my
> "telnet localhost imap" testing to work, outlook express worked regards,
> but pine using the complete spec doesn't.
It's a good idea to put the password in quotes in any case. Otherwise you
have to check that the password does not contain a quite mark. More,
passwords can contain characters that are not allowed in a q-string,
either. Some clients (I do not remember their names) always send passwords
as LITERALs.
> I can only say IMO that having a token limiter in one part of the protocol
> stream but not in another other part, would seem to increase the code bloat
> and maintance requirements. Of course not being a imap server authour I
> can't say this exactly. Adding four bytes (tokinising the login id and
> password auth fields) certainly in this case seems worth while.
Any CLIENT vendor can do that. But any SERVER is supposed to accept
anything there - atom, q-string or a LITERAL.
> Of course back to the topic on hand, the thing that pissed me off about
> Mark's actions is he took a paragraph out context and used it to extend his
> agenda. I don't care if he thinks he's doing in the public good or other
> people accept this . It's bad behaviour and I'm going to tell him off for
> it. There are more civil ways of doing this without resorting to being a
> bully-boy.
I think that it was already some ageement here and things, hopefully,
calmed down with the lesson taken by all parties. Let's move forward.
> Nicholas