On Wed, 19 Mar 2003 07:32:25 -0800 John Milan <[EMAIL PROTECTED]> wrote:
> 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. Sigh. 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. 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! To be safe we have to assume that all clients, present and future, may have a cached value for this envelope, so we better tell them all. In fact, we MUST tell them all because they won't know to ask. So, we start issuing lots of unsolicited FETCH responses to convey the change in the ENVELOPE. Let's now extrapolate the example to a change in a body part. How about a BIG body part. If we presume that there are some clients who have cached this value, we had better let them know we've changed it. Once again, because we don't know who has cached it, we MUST tell everyone about it, present and future (offline cache synchronization). Aren't we a nice server to start slamming out unsolicited BODY fetch results to all our clients whether we ever fetched any part of that message or not. You begin to see the complexity and potential nastiness in such a situation. ... 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? What part of the message are you planning to modify? Why as a client would I *EVER* want my server gratuitously changing a message without my explicit permission and direction. Even if such manipulation does occur (proxy security processing perhaps?), why would you ever need to have this change after the initial appearance of the message in the store? 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. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: [EMAIL PROTECTED] Phone: 780 424 4922
