wasm-demo/demo/ermis-f/imap-protocol/cur/1600095077.22756.mbox:2,S

93 lines
3.9 KiB
Plaintext

MBOX-Line: From mrc+imap at panda.com Mon Nov 7 08:52:04 2011
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun 8 12:34:47 2018
Subject: [Imap-protocol] [noob] select & unseen?
In-Reply-To: <1320653922.13384.140660995615489@webmail.messagingengine.com>
References: <C61A1BDF-03DD-4ED9-BFCA-C6183F07DD3E@mac.com><4EB72A0C.31264.813832F8@David.Harris.pmail.gen.nz>
<alpine.OSX.2.00.1111061650360.9034@hsinghsing.panda.com>
<1320653922.13384.140660995615489@webmail.messagingengine.com>
Message-ID: <alpine.OSX.2.00.1111070726260.9034@hsinghsing.panda.com>
On Mon, 7 Nov 2011, Bron Gondwana wrote:
> RFC 3501 says " If this is missing, the
> client can not make any assumptions about the first
> unseen message in the mailbox, and needs to issue a
> SEARCH command if it wants to find it. "
> That means there is NO WAY for the server to communicate "there are no
> unseen messages in this mailbox" in an unambiguous way.
That means that if a client expects to know the position of the first
unseen message at select time, instead of doing a SEARCH, it can not
discriminate between the case of "there are no unseen messages" and
"server does not support sending that information."
There are alternative ways for the client to find that information, most
notably SEARCH UNSEEN. If there are no unseen messages, then the sole cost
is an extra RTT. If the server does not support sending that information,
then that's the way to get the information.
The whole point was to save the client from sending SEARCH UNSEEN, and the
possibly large response, if the server supports sending that information
and the client cares. I don't know if any clients care any more.
> Unfortunately, all these warts are required to be supported - and common sense
> is a cop-out.
Lawyers insist upon a legalistic interpretation without any use of "what
is intended here".
Engineering requires practical interpretations. Nobody gets anywhere with
legalistic interpretations. Engineering requires cooperative problem
solving.
> There is no reading of RFC3501 which gives a correct answer to
> this -
Nonsense. The only intepretation at the server end that makes sense is to
send the data when there is data to send. The client end interpretation is
explictly stated as above.
> hence my assertion that a fully complient server is required to
> immediately disconnect any client issuing a "SELECT" for a mailbox which doesn't
> contain unseen messages.
You seem to think that saying such things somehow impresses me of your
intelligence and talent.
If you were intelligent and talented you would be constructive and
cooperative.
Intelligent and talented people concern themselves with fixing things that
are broken - of which there is an infinite supply of newly created broken
things to add to the existing supply.
Intelligent and talented people do not bang drums repeatedly upon finding
a trivial ambiguity in a specification.
Intelligent and talented people content themselves with pointing out the
trivial ambiguity ONCE.
Intelligent and talented people don't go off on a tangent with a
misinterpretation that is both absurd and harmful.
Intelligent and talented people, if they find that trivial matter to be
annoying enough, will write an errata with proposed replacement wording,
post it for review, and upon general concensus will submit it to the RFC
3501 errata for inclusion in a future revision.
For what it's worth, that particular bit of text was from someone else's
errata...to remedy another silly ambiguity.
I was the editor of RFC 3501. I did write a great deal of it; but that
document is the work of many authors (and one editor). I feel sorry for
you if you believe that perfection (or even complete consistency) is
possible in such an effort.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.