It's not concensus; it's the specification.Where?
The IMAP specification is filled with numerous rules having to do with when updates (most notably, untagged EXPUNGE) can be sent (and are required to be sent) all in the name of maintaining precise synchronization between client and server within a session.
You have to consider two possibilities: either the IMAP architect is an crazy person who writes lots of synchronization rules which have no purpose, or these rules exist for a reason.
This is a good rule of thumb to keep in mind when considering any protocol: when it seems that a protocol has senseless rules and numerous design problems, perhaps you are looking at it wrong. Perhaps you have misunderstood the design.
Unlike HTTP, IMAP is an extremely session-stateful protocol. It is almost the exact opposite of HTTP. The way to write a very poor IMAP client is to treat IMAP like HTTP. In many ways, the way to write a good IMAP client is to do the exact opposite of good HTTP practice.
Why is this a better question?You can not carry over state from one session to another.Where in the RFCs is this stated or implied?The better question is: where in the RFCs does it state or imply that you can carry over state from one session to another?
Because no other major Internet protocol has the ability to carry over state from one session to another. This is not a facility which generally exists in Internet protocols. Consequently, if such a facility were to exist in IMAP, it would merit special mention.
I consider one of the goals of specification to be reduced ambiguity. I would think that if there was expected behavior then it would be better to be written down?
As I stated in another message, I lack the prescience to know all the possible ways in which people can misinterpret IMAP, or to know all the possible facilities which some person may somehow assume that IMAP has even though no other Internet protocol has it. In fact, I consider both of these to be completely open-ended and impossible to itemize.
My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert.
As Barry said, there is no such thing as a "coordinated session" in IMAP; nor for that matter in any other major Internet protocol.
IMAP goes to great efforts to guarantee each session precise state, and to synchronize state changes precisely. This can not happen if there is carryover between sessions.I'm still not sure what session state we are talking about. Obviously sequence numbers. Is there anything else in this category?
There is *no* carryover between sessions.
You *may* have a UID, which *may* be used to find the same message in a future session under the limited circumstances stated in RFC 3501.
If they allow you to refer to the same message between sessions how is this not state being carried over from one session to another?
The fact that a message with UID 1232 exists in mailbox FOO in one session is no guarantee that a message with UID 1232 exists in mailbox FOO in another session (whether simultaneous or future).
UID 1232 tells you two things. First: . if the message exists in the other session *and* . if the UIDVALIDITY of the mailbox is the same in both sessions then, and *only* then, UID 1232 will refer to the same message.
Second, it is guaranteed that: . if the UIDVALIDITY of the mailbox is the same in both sessions then UID 1232 will not refer to some other message.
Once again, why do you have multiple simultaneous sessions to the same mailbox from the same client?This is a good question, but before we diverge the discussion I would like to fully understand the base behavior.
I really think that it would be better if you could explainh what it is you wish to accomplish, and hopefully then we can tell you:
. if IMAP can do it
. how to do it with IMAP
Otherwise, we're going to continue talking past each other.
Let's start with this: for almost all purposes, it is pointless to have multiple simultaneous sessions to the same mailbox from the same client. I'd like to understand why you think this is of benefit to you, since this will help me understand where your misunderstandings lie.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
