Re: Why is a message immutable?
It implies nothing of the sort. A client's decision to cache any part of a message for eternity is purely on the shoulders of the client. It has no bearing on how the server should store the data. While this is true, a client's ability to cache the message if it so chooses is promised by the IMAP protocol. Again, think of a browser. I could set the caching such that the first time I visit a web site, that web page is cached forever, but I claim that wouldn't be very useful. The web browser analogy does not hold, mainly because HTTP either makes no promises about the client's ability to cache the data, or it makes very specific promises via certain headers. On the other hand, IMAP makes very strong promises about the client's ability to cache the data. The only way for a server to invalidate the client's cache is to send an EXPUNGE for the relevant message and issue a new UID. With current clients, I absolutely agree. But, as I mentioned into another reply, I think enabling updates for current clients is not necessary. What is necessary is that they don't break. Newer clients will be able to make use of an update capability. Perhaps I am misunderstanding. Are your proposing the ability to update a message without changing the UID, or not? If so, then how do you propose that existing clients not break? How do you update a message that an existing client has cached? If not, then I don't think there's any disagreement: essentially you're proposing some sort of optimized append (append-based-on ...). john - Original Message - From: John Milan [EMAIL PROTECTED] To: Arnt Gulbrandsen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 19, 2003 7:32 AM Subject: RE: Why is a message immutable? In IMAP, a client is free to cache any part of a message for as long as it wants. That implies that once a server has sent e.g. a message's ENVELOPE to a client, that message can't be changed any more, or the client's cache would hold incorrect data. It implies nothing of the sort. A client's decision to cache any part of a message for eternity is purely on the shoulders of the client. It has no bearing on how the server should store the data. Again, think of a browser. I could set the caching such that the first time I visit a web site, that web page is cached forever, but I claim that wouldn't be very useful. The only way for a server to invalidate the client's cache is to send an EXPUNGE for the relevant message and issue a new UID. With current clients, I absolutely agree. But, as I mentioned into another reply, I think enabling updates for current clients is not necessary. What is necessary is that they don't break. Newer clients will be able to make use of an update capability. JM
What is Outlook waiting for?
So, I'm monkeying around with a (minimal) IMAP server implementation, and I'm trying to get Outlook XP to talk to it. When I point it at the server and hit F5, it hangs at Check for new mail. Apparently, it is waiting for some information from my server that I don't think I have. Here is our conversation (S is the server, C is Outlook XP): 127.0.0.1:2088: S: * OK HELLO 127.0.0.1:2088: joined 127.0.0.1:2088: C: 000H CAPABILITY 127.0.0.1:2088: S: * CAPABILITY IMAP4rev1 127.0.0.1:2088: S: 000H OK CAPABILITY completed 127.0.0.1:2088: C: 000I LOGIN john john 127.0.0.1:2088: S: 000I OK LOGIN completed 127.0.0.1:2089: S: * OK HELLO 127.0.0.1:2089: joined 127.0.0.1:2089: C: 000J CAPABILITY 127.0.0.1:2089: S: * CAPABILITY IMAP4rev1 127.0.0.1:2089: S: 000J OK CAPABILITY completed 127.0.0.1:2089: C: 000K LOGIN john john 127.0.0.1:2089: S: 000K OK LOGIN completed 127.0.0.1:2088: C: 000L SELECT INBOX 127.0.0.1:2088: S: * 0 EXISTS 127.0.0.1:2088: S: * 0 RECENT 127.0.0.1:2088: S: * OK [UIDVALIDITY 512553089] UIDs valid 127.0.0.1:2088: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 127.0.0.1:2088: S: 000L OK [READ-WRITE] SELECT completed 127.0.0.1:2089: C: 000M LSUB * 127.0.0.1:2089: S: * LSUB () / INBOX 127.0.0.1:2089: S: * LSUB () / Sent Items 127.0.0.1:2089: S: * LSUB () / Drafts 127.0.0.1:2089: S: * LSUB () / INBOX/Baz 127.0.0.1:2089: S: * LSUB () / INBOX/Baz/Bar 127.0.0.1:2089: S: 000M OK LSUB completed 127.0.0.1:2089: C: 000N STATUS Drafts (UNSEEN) 127.0.0.1:2089: S: * STATUS Drafts (UNSEEN 0) 127.0.0.1:2089: S: 000N OK STATUS completed 127.0.0.1:2089: C: 000O STATUS INBOX/Baz (UNSEEN) 127.0.0.1:2089: S: * STATUS INBOX/Baz (UNSEEN 0) 127.0.0.1:2089: S: 000O OK STATUS completed 127.0.0.1:2089: C: 000P STATUS INBOX/Baz/Bar (UNSEEN) 127.0.0.1:2089: S: * STATUS INBOX/Baz/Bar (UNSEEN 0) 127.0.0.1:2089: S: 000P OK STATUS completed 127.0.0.1:2089: C: 000Q STATUS Sent Items (UNSEEN) 127.0.0.1:2089: S: * STATUS Sent Items (UNSEEN 0) 127.0.0.1:2089: S: 000Q OK STATUS completed 127.0.0.1:2088: C: 000R NOOP 127.0.0.1:2088: S: 000R OK NOOP completed It logs in, selects INBOX, then does a NOOP, and sits. (It makes another connection, checks out the subscriptions, and asks for the count of UNSEEN messages on all the other mailboxes.) I'm guessing that it wants me to send something with that NOOP, but I just can't figure out what. I've already told it I don't have any messages for it, and that hasn't changed... john -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: What is Outlook waiting for?
I modified it to return a PERMANENTFLAGS response, but that didn't seem to help. (Just so that I can believe I understand the RFC, PERMANENTFLAGS is optional when it does not differ from the set of flags you returned with the FLAGS status, right? It would gall me to have to include it just because uw-imap does...) john -Original Message- From: Larry Osterman [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 9:32 AM To: John Doty; [EMAIL PROTECTED] If I had to hazard a guess, it's because you didn't send a PERMANENTFLAGS response on the select. If that's the case, it's probably an outlook bug because I don't believe that PERMANENTFLAGS is a manditory response to select, but Larry Osterman -Original Message- From: John Doty [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 12:05 AM To: [EMAIL PROTECTED] Subject: What is Outlook waiting for? So, I'm monkeying around with a (minimal) IMAP server implementation, and I'm trying to get Outlook XP to talk to it. When I point it at the server and hit F5, it hangs at Check for new mail. Apparently, it is waiting for some information from my server that I don't think I have. Here is our conversation (S is the server, C is Outlook XP): 127.0.0.1:2088: S: * OK HELLO 127.0.0.1:2088: joined 127.0.0.1:2088: C: 000H CAPABILITY 127.0.0.1:2088: S: * CAPABILITY IMAP4rev1 127.0.0.1:2088: S: 000H OK CAPABILITY completed 127.0.0.1:2088: C: 000I LOGIN john john 127.0.0.1:2088: S: 000I OK LOGIN completed 127.0.0.1:2089: S: * OK HELLO 127.0.0.1:2089: joined 127.0.0.1:2089: C: 000J CAPABILITY 127.0.0.1:2089: S: * CAPABILITY IMAP4rev1 127.0.0.1:2089: S: 000J OK CAPABILITY completed 127.0.0.1:2089: C: 000K LOGIN john john 127.0.0.1:2089: S: 000K OK LOGIN completed 127.0.0.1:2088: C: 000L SELECT INBOX 127.0.0.1:2088: S: * 0 EXISTS 127.0.0.1:2088: S: * 0 RECENT 127.0.0.1:2088: S: * OK [UIDVALIDITY 512553089] UIDs valid 127.0.0.1:2088: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 127.0.0.1:2088: S: 000L OK [READ-WRITE] SELECT completed 127.0.0.1:2089: C: 000M LSUB * 127.0.0.1:2089: S: * LSUB () / INBOX 127.0.0.1:2089: S: * LSUB () / Sent Items 127.0.0.1:2089: S: * LSUB () / Drafts 127.0.0.1:2089: S: * LSUB () / INBOX/Baz 127.0.0.1:2089: S: * LSUB () / INBOX/Baz/Bar 127.0.0.1:2089: S: 000M OK LSUB completed 127.0.0.1:2089: C: 000N STATUS Drafts (UNSEEN) 127.0.0.1:2089: S: * STATUS Drafts (UNSEEN 0) 127.0.0.1:2089: S: 000N OK STATUS completed 127.0.0.1:2089: C: 000O STATUS INBOX/Baz (UNSEEN) 127.0.0.1:2089: S: * STATUS INBOX/Baz (UNSEEN 0) 127.0.0.1:2089: S: 000O OK STATUS completed 127.0.0.1:2089: C: 000P STATUS INBOX/Baz/Bar (UNSEEN) 127.0.0.1:2089: S: * STATUS INBOX/Baz/Bar (UNSEEN 0) 127.0.0.1:2089: S: 000P OK STATUS completed 127.0.0.1:2089: C: 000Q STATUS Sent Items (UNSEEN) 127.0.0.1:2089: S: * STATUS Sent Items (UNSEEN 0) 127.0.0.1:2089: S: 000Q OK STATUS completed 127.0.0.1:2088: C: 000R NOOP 127.0.0.1:2088: S: 000R OK NOOP completed It logs in, selects INBOX, then does a NOOP, and sits. (It makes another connection, checks out the subscriptions, and asks for the count of UNSEEN messages on all the other mailboxes.) I'm guessing that it wants me to send something with that NOOP, but I just can't figure out what. I've already told it I don't have any messages for it, and that hasn't changed... john -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
RE: What is Outlook waiting for?
Hmm, ok. (Won't argue with the man whose name is on the RFC. ^_^) May I suggest that, in future revisions of RFC 2060, that the paragraph in section 6.3.1, page 23: If the client can not change the permanent state of one or more of the flags listed in the FLAGS untagged response, the server SHOULD send a PERMANENTFLAGS response code in an OK untagged response, listing the flags that the client can change permanently. be changed? In my opinion it suggests that the PERMANENTFLAGS response is optional if the client can change all of the FLAGS listed in the FLAGS untagged response. If it is the case that the server MUST send the PERMANENTFLAGS response if there are any flags that can be changed, then the PERMANENTFLAGS response code should be added to the list of untagged data items that MUST be sent. It seems exceptionally bogus that outlook would just not work on a system without IDLE. (After outlook does not get a response from my server, it pops up a dialog box saying Hey user, your evil IMAP server timed out while I was trying to get new mail! The is regardless of what I click.) I guess I should get started implementing IDLE john -Original Message- From: Mark Crispin [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Crispin Sent: Monday, February 10, 2003 10:26 AM To: John Doty Cc: Larry Osterman; [EMAIL PROTECTED] On Mon, 10 Feb 2003 10:12:45 -0800, John Doty wrote: (Just so that I can believe I understand the RFC, PERMANENTFLAGS is optional when it does not differ from the set of flags you returned with the FLAGS status, right? It would gall me to have to include it just because uw-imap does...) PERMANENTFLAGS means that when you change the flag, the flag will stay changed in the next session, as distinguished from flags which are only valid in a particular session and are discarded when the session terminates. I think that what you are seeing is Outlook's standard behavior when the server does not support IDLE. Rather than periodically poll the server for new mail by issuing a command every few minutes (which is what it should do), it just sits there unless the user does a mouse click. FWIW, rumors to the contrary notwithstanding, NOOP is not a poll command. All commands check for new mail on the selected stream as a side-effect. NOOP does nothing else, so if you want to poll for new mail but not do anything else, then you use NOOP. Anyway, the galling thing is that to work well with Outlook, you have to implement IDLE. But you're not done yet. Outlook won't terminate the idle state before the 30 minute inactivity autologout timer, even though the specification says that it should. So, at about 29 minutes into the IDLE, the server needs to send a hokey EXISTS announcing fake new mail, then when the client sends a DONE the server should send a hokey EXPUNGE to make the fake new mail go away. That will cause the client to issue a new idle and prevent the autologout.
