Hello all, First of all, I'm a newbie, so my deepest apologies for raising old wrecks....
BUT.... I've been scratching my head over why the latest IMAP specification has been changed such that ENVELOPE and BODYSTRUCTURE are now explicitly immutable (RFC 2060 was mum on the issue). I finally found the original thread from May of 1998. http://www.washington.edu/imap/listarch/1998/msg00514.html Which led to this summary that seems the simplest to understand: "This is exactly why I raised my initial objection, and after discussing this with Mark, he and I agree that messages that are modified in any way that would cause a modification of the ENVELOPE or BODYSTRUCTURE are different messages, and thus the UID of the message MUST be changed." This strikes me as a rather strange argument. Mark must have some very impressive powers of persuasion because this is quite at odds with most other implementations of unique identifiers and its data. Certainly anyone familiar with databases would disagree that changing a piece of data requires changing its key. But I have a feeling 'database' is a dirty word here, so scratch that example. Instead, let's look at other examples. The address of my house stays the same regardless of whats in it. My bank account number stays the same regardless of how little is in it. If I want a snapshot of what's in my house, I take a picture. If I want to know what my bank balance was on new years day, I can either save the data file on news years day or perform a search for what it was on a particular date (aha, you might say, you contradict yourself. you are actually searching many messages, each containing a particular days bank balance. please read on). Lets look at the most successful universal identification scheme in recent memory: the URL. If I type in http://www.cnn.com I expect my web browser to be able to locate that address. If the CNN website happens to be the same as when I left it, great. If it happens to be updated from the last time I viewed it, fine. If it changes tomorrow, no problem. I always see the current content for the http://www.cnn.com identifier. Speed concerns are handled by simple and well defined caching rules. And again, I can save a particular day's page if I want to. So what are some concerns? In the thread I cite above, one person raised server performance concerns. Even if this is the case, I firmly believe in our ability to come up with reasonable solutions-- especially with today's horsepower. Another issue raised was there is no way in IMAP to make a message change (apart from flags). But this can be solved by creating a way in IMAP to make a message change (and yes, I hope I have one :) I can only think of two arguments at this point (though I'm sure there's more, please contribute): 1) The philosophical 'What is a message?' 2) The very real possibility of breaking lots of running clients. Let's address the second argument first. I claim IMAP is flexible enough, and we are smart enough, that we can collectively come up with a solution that won't break all clients. Call me an optimist. So assuming argument 2 is an excercise left to the reader, we are left with argument 1: 'What is a message?'. Good question. As you recall, earlier I seemed to contradict my own argument that pointers and data are disjoint. Back to the bank account example. In order for me to see what my bank balance was on new years day, I would need to find the 'message' corresponding to my account number, dated new years day and containing the balance. So I would need a series of messages, right? Right. But is this the same message that corresponds only to my account number? NO. What we have are two sets of messages. Set 1 contains a message with a UID consisting only of my bank account number (and since I have only one bank account, it's a small set). Set 2 contains copies of that single message in set 1, but created on a recurring epoch: the changing of a day (and since time marches on, its more substantial). These two sets don't really have a whole lot in common. There probably exists the ability to move from the current bank account message in Set 1 to the new years day balance message in Set 2, but its not required as a function of its UID. As for creating the two sets, I could have been diligent and punctual and manually COPIED my bank account balance message from one mailbox to another every midnight, but thankfully it was done automatically. But surely the messages in Set 2 are immutable, right? Obviously you've never worked in a bank :) For example, what if I wanted to see my bank account balance on Jan 1, 2000, which, because of the Y2K bug, accidently had a value of $1 million for a short while? Would my account still show $1 million for Jan 1, 2000 if I search for that message today? Absolutely not! Because someone caught the general error, updated the automatic COPY routine, and then updated the faulty account data in the message of Jan 1, 2000. They might have even done it on Jan. 3 or thereabouts. So even here, it was still quite useful for messages to be updatable. Why am I beating a horse that that died back in 1998? Because it wasn't beaten properly! I think this is a huge hole in the IMAP spec, and other than several references stating 'messages MUST be immutable', I have yet to see any problem explaining why it's so obviously impossible for messages to be mutable. Currently, IMAP can AUTHENTICATE users, CREATE mailboxes, APPEND or COPY messages, FETCH messages or parts of messages, SEARCH for messages, STORE flags associated with a message, EXPUNGE messages and DELETE mailboxes. We've also seen recent activity with Access Control Lists. There's even Secure Socket implementations. IMAP already has the kitchen sink, except for the ability to update messages. By not supporting updates, IMAP essentially doesn't have running water. I think the richness of the client/server interaction and two-way nature of the IMAP protocol has real potiential for today's environments. But I also think the ability to update messages is crucial for it to be grow with today's environments. I have a rough draft of a rough UPDATE command extension, but I wanted to see if I'd be blown out of the water first. I eagerly await your comments. Thanks for your time reading such a long-winded message. Feel free to change it! :) John Milan -- ----------------------------------------------------------------- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -----------------------------------------------------------------
