MBOX-Line: From vladimir_butenko at stalker.com  Mon Apr 10 14:15:04 2006
To: imap-protocol@u.washington.edu
From: "Vladimir A. Butenko" <vladimir_butenko@stalker.com>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] LIST Clarification
In-Reply-To: <Pine.WNT.4.65.0604101359200.4904@Tomobiki-Cho.CAC.Washington.EDU>
References: <443A7A2D.2070708@consilient.com> <web-35034698@mail.stalker.com>
	<Pine.OSX.4.64.0604101053530.2906@pangtzu.panda.com>
	<web-35035906@mail.stalker.com>
	<Pine.WNT.4.65.0604101359200.4904@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <web-35036142@mail.stalker.com>

On Mon, 10 Apr 2006 14:01:36 -0700 (Pacific Daylight Time)
  Mark Crispin <MRC@CAC.Washington.EDU> wrote:
> I think that your message (which you sent only to me) raises some good 
>points.  May I forward it to the imap-protocol mailing list, and answer it 
>there?

Sure. I'm at home and lovely PacBell/SBC/AT&T/whatever it is now - broke the 
connection right when I finished writing it, and went down for 40 mins - so 
I had to re-assemble the letter later and, obviously, did not put the 
correct addresses in. Sorry about that - please forward it to the list.

   Or do you prefer that this discussion remain private?

> I think that the only point of contention is if we need to declare another 
>errata to RFC 3501 or decide that it's good enough the way it is.

I do not see any real "error" in the current protocol specs. But some 
clarification would be a good thing - if/when you plan to release a new 
version of that RFC.

Ideally, the IMAP standard should be broken in 2 - the "Mail store standard" 
with all semantics of the mail store (including all that INBOX mess, ACLs, 
renaming of INBOX, case sensitivity, the UTF-7 encoding of mailbox names, 
etc, etc.,) and the "IMAP proper" - the protocol itself. The first standard 
should also specify how other protocols should access mail store. For 
example, what should happen if I read mail via POP and some message has been 
deleted and some has been added? We know what will happen (the client should 
not see the change in message #s, and attempts to retrieve the deleted 
message should return -Err or an empty message) - but there should be a 
place to explain all these things. And the IMAP protocol (or POP protocol) 
specs are not the right place for all these things.

Feel free to forward this part to the list, too - unfortunately, I cannot 
afford to help you with these changes, even if you agree with them. 
Hopefully, some folks on the mailing list will be willing to meet this 
challenge.

> -- Mark --
> 
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.

Sincerely,
Vladimir

