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.

