Re: FETCH Failure
On Tue, 2004-09-28 at 22:00, Barry Leiba wrote: Why is this a better question? 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? Hm. So, let's see: You'd expect to be able to open two FTP sessions to the same server, set the mode to binary in one session, transfer a file in the other session, and expect the mode to be binary, yes? I don't think the FTP spec says otherwise, so No. This is a classic apples to oranges comparison. A transfer mode is clearly a session characteristic. The session uses this information to operate on the data in transit. A better comparison would be state stored central to FTPs objects of operation, i.e. files. In the case of FTP the server is mirroring state about files on the server's file system. File state, while it can not be relied on to be correct the minute the server responds to an ls for example, it can be relied on to be consistent between sessions. I could envision multiple FTP clients working in concert where one did an ls and concurrent sessions then did gets. Note, I'm not arguing SNs should be session state. I'm convinced they are not. My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert. And do you know ANY Internet protocols where that happens? I'm not sure exactly what you are looking for, but I would point out RFC1990 goes in this direction. It is more important to note I'm not looking for, nor expecting, protocol help to share sessions. Mike
Re: FETCH Failure
On Tue, 2004-09-28 at 23:43, Mark Crispin wrote: On Tue, 28 Sep 2004, Michael Wener wrote: It's not concensus; it's the specification. Where? ... 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. I've never considered the protocol to have design problems or senseless rules. 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. This is what I need. 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. This is what I need. How this is not shared state between sessions I'm not sure, but perhaps it is semantics. 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. I prefer to fix miscommunication before changing subjects. Mike
Re: FETCH Failure
Note, I'm not arguing SNs should be session state. I'm convinced they are not. I misspoke. I'm convinced that SNs should not be shared between sessions. Mike
Re: FETCH Failure
Michael Wener [EMAIL PROTECTED] wrote: My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert. The server has no way of knowing whether two sessions are coordinated on the client side. It has to treat each session independently. In the case of IMAP, this means, among other things, that the server maintains a per-session mapping between messages and message sequence numbers. Consequently, message sequence numbers are not meaningful to a particular session until the server has added the appropriate entries to that session's mapping, which typically happens when the server notifies that session of the new messages. paul
Re: FETCH Failure
On Wed, 2004-09-29 at 09:42, Philip Guenther wrote: Michael Wener [EMAIL PROTECTED] writes: ... Note that you still have to wait until the server tells you the message exists. Until then it is completely free to say no such message. ... How this is not shared state between sessions I'm not sure, but perhaps it is semantics. That a message with a given UID exists is per-session state: it exists from the moment the server announces it via a * N EXISTS response until the server sends a * M EXPUNGE response for it. I understand. Thank You. That a given UID in a given mailbox with a given UIDVALIDITY maps to a specific message for as long as it exists is unchanging. Does something that never changes count as shared state? If they have equal values in each session, I would think so. Maybe the key here is that, as your explanation above points out, it is a matter of when the state becomes visible, and in the case of EXPUNGE leaves visibility, to the session. Is it fair to say that once a UID is visible within a session it is shared state? ... 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. I prefer to fix miscommunication before changing subjects. This mailing list is the tech-support for the IMAP protocol. The single most important thing when communicating with tech-support is to describe your goal or intent. Spending hours working out how My goal and intent at the moment is to understand the concept of a session within IMAP. to do something that turns out to be a step away from the ultimate goal is frustrating to all involved. There's a good chance that I'm not frustrated. I'm learning a significant amount from this discussion given my goal. I appreciate those that are taking the time to answer. the discussion of how to attain the real goal would have answered the original question or rendered it moot. Could have. I've always believed in a good understanding of first principals. The understanding I gain in this discussion will greatly aid in future discussion as well as having the possibility of rendering a question I may ask in the future moot. Mike
Re: FETCH Failure
On Wed, 2004-09-29 at 10:30, Paul Jarc wrote: Michael Wener [EMAIL PROTECTED] wrote: My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert. The server has no way of knowing whether two sessions are coordinated on the client side. It has to treat each session independently. In the case of IMAP, this means, among other things, that the server maintains a per-session mapping between messages and message sequence numbers. Consequently, message sequence numbers are not meaningful to Ah ... I see. Does the server keep a per-session mapping between messages and UIDs? Mike
Re: FETCH Failure
Michael Wener writes: Is it fair to say that once a UID is visible within a session it is shared state? Yes. It's shared with all other sessions that have the same uidvalidity and mailbox, and in which that UID is visible. My goal and intent at the moment is to understand the concept of a session within IMAP. RFC 3501, page 5, third paragraph. Personally I find the definition slightly puzzling, but there it is. Arnt
Re: FETCH Failure
Michael Wener [EMAIL PROTECTED] wrote: Does the server keep a per-session mapping between messages and UIDs? No, that mapping is per-UIDVALIDITY. UIDVALIDITY typically does not change very often, although the server is allowed to change it at any time. paul
Re: FETCH Failure
On 09/29/2004 04:34:05 PM, Michael Wener wrote: On Wed, 2004-09-29 at 09:42, Philip Guenther wrote: Michael Wener [EMAIL PROTECTED] writes: to do something that turns out to be a step away from the ultimate goal is frustrating to all involved. There's a good chance that I'm not frustrated. [snip] But other people may be :). More seriously: What has not been mentioned yet is that flags belong to a session state, too, particularly session flags (those not listed in PERMANENTFLAGS). Ie. a message with UID XXX can have \seen flag in one session and no such a flag in another. As it was said before, a client accessing same mailbox in two different sessions is most likely a wrong design for IMAP. I would kindly advise to reconsider it unless you have a very intimate knowledge of all the possible implications. Perhaps somebody could recommend a different design if you described the problem you are trying to solve by opening two connections. Pawel
Re: FETCH Failure
On 29 Sep 2004, Michael Wener wrote: : : My goal and intent at the moment is to understand the concept of a : session within IMAP. The best explanation I've ever heard on this list is to think of the mailstore as a world or environment and the server is describing the world to the client session. The client accepts the descriptions from the server and can also ask the server to do things. The server describes the results of the client's requests, but it can ALSO describe things that have NOTHING to do with the client's requests. (Untagged responses.) In fact the server is obliged to tell the client these things. These are things that may have been initiated in another session, or initiated by the server itself, doesn't really matter. I wish I could find the original post because it was much more well written. So instead of thinking of IMAP as client request, server response, client request, server response, etc, think: client request, server says this happened, and that, and this, and by the way that thing you asked for is now done. The this and that are the untagged responses, one of which may be relevant to the client's request. Get your brain around the concept that the server can - and must! - tell you ANYTHING, not just the things you asked for, and then it starts to make more sense. The implication of this is that a session should not assume anything except exactly what the server tells it. (In my opinion) debating about shared state is irrelevant. You don't need to share state with other sessions, because when something happens the server is going to describe it to all sessions. Don't take directions from other sessions. To make a tenuous analogy, that would be like your tour guide telling you turn left, but you insist on turning right because some dude on the street corner told you to. -- Within nine days of its release the very first exploit for IE 3.0 was discovered and released to the public. The rest ... is history. - Josh Ryder
Re: FETCH Failure
I wrote: UIDVALIDITY typically does not change very often, although the server is allowed to change it at any time. More precisely, it can't change during a session, but two different sessions can get different UIDVALIDITY values, no matter how close together they are. paul
RE: FETCH Failure
Ah, but sequence numbers ARE a session characteristic. They can only be considered to be valid in the context of a single session. That's why there are so many silly rules about when you can change the session numbers and the consequences of that. Consider the EXISTS and EXPUNGE responses for example. EXISTS can be sent at any time - why? Because EXISTS adds entries to the end of the per-session set of sequence numbers, and you can always add to the end of an array without changing the meaning of the existing entries of the array. On the other hand, EXPUNGE can only be sent at a time when the server KNOWS the client is not evaluating a sequence number. Why? Because the EXPUNGE response changes the sequence number for every message in the mailbox FOR THAT SESSION. Those are the silly, nonsensical rules to which Mark was referring - they don't make any sense in the context of global sequence numbers, but make perfect sense when you consider sequence numbers as being a session characteristic. UIDs are cross session, IF (and only IF) the UIDVALIDITY is unchanged. And there ARE existing, compliant servers which will give a different UIDVALIDITY for every session (if the underlying message store is incapable of implementing UIDs). Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Wener Sent: Wednesday, September 29, 2004 5:27 AM To: [EMAIL PROTECTED] Subject: Re: FETCH Failure On Tue, 2004-09-28 at 22:00, Barry Leiba wrote: Why is this a better question? 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? Hm. So, let's see: You'd expect to be able to open two FTP sessions to the same server, set the mode to binary in one session, transfer a file in the other session, and expect the mode to be binary, yes? I don't think the FTP spec says otherwise, so No. This is a classic apples to oranges comparison. A transfer mode is clearly a session characteristic. The session uses this information to operate on the data in transit. A better comparison would be state stored central to FTPs objects of operation, i.e. files. In the case of FTP the server is mirroring state about files on the server's file system. File state, while it can not be relied on to be correct the minute the server responds to an ls for example, it can be relied on to be consistent between sessions. I could envision multiple FTP clients working in concert where one did an ls and concurrent sessions then did gets. Note, I'm not arguing SNs should be session state. I'm convinced they are not. My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert. And do you know ANY Internet protocols where that happens? I'm not sure exactly what you are looking for, but I would point out RFC1990 goes in this direction. It is more important to note I'm not looking for, nor expecting, protocol help to share sessions. Mike
RE: FETCH Failure
On Wed, 29 Sep 2004, Larry Osterman wrote: UIDs are cross session, IF (and only IF) the UIDVALIDITY is unchanged. And there ARE existing, compliant servers which will give a different UIDVALIDITY for every session (if the underlying message store is incapable of implementing UIDs). However, this cross-session characteristic is much less than Mike seems to expect. The fact that a UID is known to a session does not mean that it is known to another (even a simultaneous) session. There are many ways that a message can be known to one session but not another. UIDs only promise that a particular UID will not refer to two different messages. In other words, UIDs are a means by which an application can synchronize itself in a session using data from another (typically chronologically earlier) session. Sessions do not synchronize on their own, although simultaneous sessions will tend towards synchronization over time. File state, while it can not be relied on to be correct the minute the server responds to an ls for example, it can be relied on to be consistent between sessions. I just noticed this comment of Mike's. It's false, as anyone who has spent any non-trivial amount of time dealing with NFS can testify. Sad, but true. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: FETCH Failure
Absolutely right, that's a subtlety I missed in my response. In particular, just because you have two sessions with the same UIDVALIDITY doesn't mean that you can use a UID from session 1 in session 2 - if you haven't seen the EXISTS response for that message, it doesn't exist. This is actually REALLY important - I suspect that some IMAP servers will let you get away with doing this, even though it's a violation of the protocol (in particular, I'm not sure that the Exchange 5.5 IMAP server would catch this protocol violation - it might, but it might not). Larry Osterman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: Wednesday, September 29, 2004 12:34 PM To: Larry Osterman Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FETCH Failure On Wed, 29 Sep 2004, Larry Osterman wrote: UIDs are cross session, IF (and only IF) the UIDVALIDITY is unchanged. And there ARE existing, compliant servers which will give a different UIDVALIDITY for every session (if the underlying message store is incapable of implementing UIDs). However, this cross-session characteristic is much less than Mike seems to expect. The fact that a UID is known to a session does not mean that it is known to another (even a simultaneous) session. There are many ways that a message can be known to one session but not another. UIDs only promise that a particular UID will not refer to two different messages. In other words, UIDs are a means by which an application can synchronize itself in a session using data from another (typically chronologically earlier) session. Sessions do not synchronize on their own, although simultaneous sessions will tend towards synchronization over time. File state, while it can not be relied on to be correct the minute the server responds to an ls for example, it can be relied on to be consistent between sessions. I just noticed this comment of Mike's. It's false, as anyone who has spent any non-trivial amount of time dealing with NFS can testify. Sad, but true. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: FETCH Failure
On Tue, 28 Sep 2004, Michael Wener wrote: Session 2 Ah Ha, I see I have new mail There's your problem. You were informed of new mail in session 1, and you assumed that this information is valid in session 2. It isn't. You can not carry over state from one session to another. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: FETCH Failure
Michael Wener wrote: Session 1 1 IDLE + IDLE Accepted Some time passes and then new mail arrives * N EXISTS * 1 RECENT Session 2 Ah Ha, I see I have new mail 2 FETCH N BODYSTRUCTURE * N EXISTS * 1 RECENT 2 NO the specified message set is invalid The line Ah Ha, I see I have new mail is incorrect. Session 1 has seen it has new mail, not session 2. From the server's perspective these might as well be different machines, so when session 2 attempts to fetch anything about message N the server (legitimately) rejects this request since the server hasn't told session 2 about the new message yet. In addition to rejecting this request the server now tells session 2 about the new message, so a subsequent fetch for this message will work. The bottom line is the server must tell each session (independently) about new messages (and anything else) - a single client that uses multiple connections must understand this. Assuming multiple sessions must be used, one possible solution is for session 2 to issue a NOOP when it realizes it has a new message so the server can tell it about the new message. -Rick Block
Re: FETCH Failure
On Tue, 2004-09-28 at 13:43, Timo Sirainen wrote: On 28.9.2004, at 20:30, Michael Wener wrote: Session 1 1 IDLE + IDLE Accepted Some time passes and then new mail arrives * N EXISTS * 1 RECENT Session 2 Ah Ha, I see I have new mail 2 FETCH N BODYSTRUCTURE * N EXISTS * 1 RECENT 2 NO the specified message set is invalid This is clearly a client bug. There are no guarantees that multiple sessions have compatible sequence numbers. Expunges especially may make the fetch return wrong message. At minimum the client should do UID FETCH and do some fallback processing if it doesn't return anything. The point here is that it *is* currently a valid sequence number. After all the next FETCH confirms this. There is no guarantee within a *single* session that a sequence number is valid. Another session could have expunged SN N while my fetch was in transit in the network. For example on Exchange 2000 I get the peculiar series of responses. Again we see a one command lag of sorts ... Session 1 1 STORE N FLAGS (\Deleted) * N FETCH (FLAGS (\Deleted)) 1 OK STORE Completed 3 CLOSE 3 OK CLOSE Completed Then after above command series is completed Session 2 2 FETCH N FLAGS * N FETCH (FLAGS (\Deleted)) 2 NO Some Messages in the mailbox had previously been expunged 4 FETCH N FLAGS 4 NO Some Messages in the mailbox had previously been expunged It would not be difficult to craft a client that tolerated failed commands and then adjusted behavior. The strange thing here is that the responses are wrong, or more accurately stated, delayed. I'm very curious about this pattern of delay. Mike
Re: FETCH Failure
On Tue, 2004-09-28 at 13:48, Mark Crispin wrote: On Tue, 28 Sep 2004, Michael Wener wrote: Session 2 Ah Ha, I see I have new mail There's your problem. You were informed of new mail in session 1, and you assumed that this information is valid in session 2. It isn't. Yes, this seems to be the consensus. You can not carry over state from one session to another. Where in the RFCs is this stated or implied? Also, obviously some state is carried over as stated in 2.3.1.1. So what state is and is not session affinitive? I see in 2.3.2 that flags are explicitly defined to have or not have session affinity. UIDs do not have session affinity. Mike
Re: FETCH Failure
On Tue, 28 Sep 2004, Michael Wener wrote: The point here is that it *is* currently a valid sequence number. After all the next FETCH confirms this. No, it is not a valid sequence number, and it remains an invalid sequence number until you receive an EXISTS response *in that session* that announces the validity of that sequence number. There is no guarantee within a *single* session that a sequence number is valid. Another session could have expunged SN N while my fetch was in transit in the network. Also incorrect. An untagged EXPUNGE can only be transmitted when a command other than FETCH, STORE, and SEARCH is in progress. Until such a command is in progress, the sequence remains valid even if the message was expunged in another session. For example on Exchange 2000 I get the peculiar series of responses. That behavior is now deprecated. Refer to RFC 2180; the behaviors described in 4.1.1 and 4.1.4 are now preferred over 4.1.2 and 4.1.3. This all leads to a different question: why do you have multiple sessions open to the same mailbox from the same client? This is potentially very costly in server resources, and does not work at all with some servers. It should be avoided. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: FETCH Failure
On 28.9.2004, at 22:19, Michael Wener wrote: This is clearly a client bug. There are no guarantees that multiple sessions have compatible sequence numbers. Expunges especially may make the fetch return wrong message. At minimum the client should do UID FETCH and do some fallback processing if it doesn't return anything. The point here is that it *is* currently a valid sequence number. After all the next FETCH confirms this. It only happens to be correct in that case. It could easily be wrong as well. There is no guarantee within a *single* session that a sequence number is valid. Another session could have expunged SN N while my fetch was in transit in the network. It is still valid. The message may not physically exist anymore, but the sequence number still points to that one specific message. The message is completely gone from the session only after EXPUNGE is sent to client. Here's an example of how you can easily break by trusting sequence numbers to be same with different sessions: Session 1: 1 IDLE + idling * 1 EXPUNGE * 5 EXISTS Session 2: 1 FETCH 5 UID // tries to fetch the new message, while in fact it fetches old one * 6 EXISTS * 5 FETCH (UID 5) 1 OK 2 NOOP * 1 EXPUNGE 2 OK Of course the session 2 could keep track of what expunges haven't been yet notified, but that gets complex and still doesn't make it entirely safe. Better to keep completely separete states for each connection. PGP.sig Description: This is a digitally signed message part
Re: FETCH Failure
On Tue, 2004-09-28 at 15:40, Mark Crispin wrote: On Tue, 28 Sep 2004, Michael Wener wrote: ... assumed that this information is valid in session 2. It isn't. Yes, this seems to be the consensus. It's not concensus; it's the specification. Where? 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? Why is this a better question? 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? Consider carefully what state-carryover would imply to a client that is not aware of the state in any other session. The client couldn't use any data that it got, because it could be invalidated, without notice, by some other client. My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert. 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? Also, obviously some state is carried over as stated in 2.3.1.1. Actually, that is not the case. Note in the second paragraph in 2.3.1.1 about the UIDVALIDITY. A compliant server could issue different UIDVALIDITY values in different sessions and have nothing in common between the two. The only thing that UIDs do is allow you to refer to the same message between sessions. They do not, in any way, guarantee that that message actually exists. 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? I realize that the server has the option to invalidate the state between sessions, but by your own statement this is intended to be the exception. Once again, why do you have multiple simultaneous sessions to the same mailbox from the same client? I think that you may have a more This is a good question, but before we diverge the discussion I would like to fully understand the base behavior. fundamental misunderstanding about IMAP, and I'd like to clear that up. Thank You. I may. Mike
Re: FETCH Failure
On Tue, 28 Sep 2004, Michael Wener wrote: Also incorrect. An untagged EXPUNGE can only be transmitted when a command other than FETCH, STORE, and SEARCH is in progress. Until such a command is in progress, the sequence remains valid even if the message was expunged in another session. Do you mean as in RFC2180 sec 4.1.1? The server does have the option of using section sec 4.1.3, no? No. Regardless of which portion of RFC 2180 section 4.1 you use (and you should only use 4.1.1 or 4.1.4; 4.1.2 and 4.1.3 are proven to be bad ideas that break clients), this does not repeal the base specification. Note RFC 3501 section 5.2. When I say invalid above, all I mean is that the SN no longer refers to what the client thought it did prior to the external event that removed the message. This situation CAN NOT happen. It is FORBIDDEN by the specification. The whole point of RFC 2180 section 4.1 is to describe how a server should comply. At all times, it is completely unambiguous what message a sequence number refers to. You can not reference a message number higher than the last EXISTS in the session. No message goes away in the session until an untagged EXPUNGE is received in the session, and an untagged EXPUNGE can only be received at certain points. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: FETCH Failure
Why is this a better question? 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? Hm. So, let's see: You'd expect to be able to open two FTP sessions to the same server, set the mode to binary in one session, transfer a file in the other session, and expect the mode to be binary, yes? I don't think the FTP spec says otherwise, so My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert. And do you know ANY Internet protocols where that happens? Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam
Re: FETCH Failure
On Tue, 28 Sep 2004, Barry Leiba wrote: My consideration at the moment is only coordinated sessions. Sessions that are aware of each others logic and are behaving in concert. And do you know ANY Internet protocols where that happens? This is actually a pretty good observation. Internet protocols don't work this way, and it has not been considered necessary to state this for each protocol. The architects of Internet protocols lack the prescience to envision every possible way in which some person could conceive that a protocol could work. It is arguable that the possibilities are completely open-ended, and that it is impossible to present an exhaustive list of the ways in which the protocol does not work. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: FETCH Failure
On Tue, 28 Sep 2004, Michael Wener wrote: 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. 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? Why is this a better question? 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.
