> Sigh. Snort.
> Let's say you decide (for some as yet unexplained reason) that you want to > change the header. The ENVELOPE then changes for the message, > invalidating any cached values, client or server, for that message. That would be the idea. > Because you don't know that what clients have cached the envelope, you now > need to notify clients that the envelope has changed. Which clients have > fetched the ENVELOPE? Don't know! Don't care! The server keeps track of the latest information, the clients grab the updates as needed. <snip possible implementation that obviously wouldn't work> > But all of this aside. Internet mail messages are exactly that -- > messages. They are composed by the issuer in the form the issuer chooses > the message to take. What reasonable circumstances would you have for > changing the content of the message that was handed to you in good faith by > the delivery system? You've never seen a message change on its way to a receiver? Haven't you ever asked anyone to 'look over this message' before you sent it? There are quite a few people who wish they could have modified a message they sent to their bosses in haste. > What part of the message are you planning to modify? I'm proposing basically everything except the UID and INTERNALDATE right now, but I suspect there will be other parts that should be immutable. Computed values obviously make no sense. For instance, RFC822.SIZE must only be changed as a result of an update, it can never be set by a client directly. Macros data items like ALL, FULL etc. also wouldn't make sense. But the very well defined, and quite usefull, section definitions allowing for full or partial FETCHes should be UPDATe-able, in my opinion. > Why as a client would I *EVER* want my server gratuitously changing a > message without my explicit permission and direction. I would never want something gratuitous in the sense of being unwarranted (free is another story :). However, I would like to know if the server has something *new* for me, much like it tells me I have a new message. > We can and do manipulate meta-data about a message. I would suggest that > annotating a message so that it can be interpretted differently by a > client that chooses to support such annotations is a better way to "alter" > the view or content of a message. I think annotations fall apart if there are alot of them and their individual perceived value is close to nil. I think there is a broad range of data that falls in this category. Think stock prices. There are alot of closing day prices for IBM between now and, say, 1935 that I simply don't care about. I want to know the latest information, because that has the most value. I'm also not advocating that every and all messages are updateable by anyone at anytime. I don't like chaos any more than you do. But one can easily imaging a permission scheme like the basic filesystem's read/write system that can be supported by ACLs, but one argument at a time. JM
