84 lines
3.8 KiB
Plaintext
84 lines
3.8 KiB
Plaintext
MBOX-Line: From mrc at CAC.Washington.EDU Thu May 24 08:52:17 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc@CAC.Washington.EDU>
|
|
Date: Fri Jun 8 12:34:39 2018
|
|
Subject: [Imap-protocol] Re: FLAGS response
|
|
In-Reply-To: <1738689467.102591179990489448.JavaMail.root@dogfood.zimbra.com>
|
|
References: <1738689467.102591179990489448.JavaMail.root@dogfood.zimbra.com >
|
|
Message-ID: <alpine.OSX.0.99.0705240835310.10455@pangtzu.panda.com>
|
|
|
|
On Thu, 24 May 2007, Dan Karp wrote:
|
|
> It certainly makes sense that changes in FLAGS elicit unsolicited
|
|
> responses in much the same way as changes in EXISTS and RECENT do.
|
|
> Along those lines, should the server be sending untagged notifications
|
|
> with the appropriate response codes when the next message UID [UIDNEXT]
|
|
> and lowest-sequenced unseen message [UNSEEN] change?
|
|
|
|
A reasonable question.
|
|
|
|
IMHO, UIDNEXT and UNSEEN are uniquely useful at SELECT time: UIDNEXT to
|
|
tell a disconnected client if there are possible new messages since the
|
|
last session (saves an RTT) and UNSEEN to allow some clients to position
|
|
their message index browser at the "first unread message" (again to save
|
|
an RTT).
|
|
|
|
Both of these are late add-ons to IMAP, with relatively little
|
|
justification. Some have argued their abolition. But on the other hand,
|
|
there was a client that did a STATUS to get UIDNEXT separate from the
|
|
SELECT, because it wanted to know if there was new mail but it had been
|
|
deleted and expunged. I don't think that we want to go back there.
|
|
|
|
Anyway, I see little point to sending UIDNEXT and UNSEEN updates.
|
|
|
|
>> Put another way: a subsequent FLAGS response in a session should only add
|
|
>> flags at the end of the list, but a FLAGS response in a new session can
|
|
>> reorder/remove flags.
|
|
> Will any clients fail if either of these two suggestions are not followed
|
|
> by the server?
|
|
|
|
Yes. This was even discussed on the IMAP mailing list many years ago.
|
|
|
|
> They both seem reasonable, but there doesn't appear to be
|
|
> anything in RFC 3501 that requires that servers behave in that manner.
|
|
|
|
RFC 3501, like all human endeavors, is not perfect. We have spent about
|
|
20 years in trying to get IMAP beyond Proposed Standard status. We are
|
|
probably going to fall back yet again with another Proposed Standard RFC
|
|
for IMAP.
|
|
|
|
You can't assume that the specification is going to tell you everything
|
|
that you need to know. It will never happen. We can address this
|
|
particular question, but I can guarantee that someone will find another
|
|
one after the publication of the new RFC.
|
|
|
|
Each IMAP specification update consumes a couple of years of my time.
|
|
Invariably, there are months of "last calls" and inactivity, only to have
|
|
someone call a "wait, we need to do this" at the last minute that pulls
|
|
everything back. Requests to review drafts don't work.
|
|
|
|
And, with the addition of more expository text to say (what is obvious to
|
|
some people), we get a larger and more bloated document that people won't
|
|
read. There are already many IMAP implementations written by people who
|
|
looked at the examples but never the formal syntax or the expository text,
|
|
because their implementations blatantly violate both.
|
|
|
|
I understand -- and sympathize -- with the desire to remove reliance upon
|
|
folklore and common sense. I see no hope of that ever being accomplished.
|
|
|
|
The sad fact is that we are running out of time. Given past history,
|
|
there is little hope that it will reach full standard status under my
|
|
tenure.
|
|
|
|
I don't think that it's a good use of the next decade or so to make a
|
|
futile attempt to perfect the base specification. It needs to be made
|
|
good enough, and there needs to be general understanding of the
|
|
architecture so that people don't blame their silly decisions on the base
|
|
specification.
|
|
|
|
-- 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.
|
|
|