On Tue, 28 Jan 2003, Andreas Aardal Hanssen wrote: > I have probably misunderstood something about the wonderful world of > untagged responses. My whole interpretation was that many of these > responses, typically FETCH, can show up in most occasions, even when the > client does not ask for it, and that they are there to update the client.
So far, so good. > Some places the responses are required, or rather _expected_. Other times, > the responses can be quite unnecessary. This is, to me, quite inconsistent > in the protocol. If the protocol stated once and for all that all untagged > responses are optional, and only necessary if they show updates, _pending > updates_, to the state of the selected mailbox, then I'd be content. Once upon a time, that's what the protocol said. Certain individuals complained bitterly about that because they didn't want to maintain a client state. Instead, they wanted the data, each and every time they asked for it, and they also wanted to be able to ignore unsolicited data. To get a small taste of the lunacy involved, read RFC 1203. STORE is one of those instances of "asking for it". There is another advantage to always sending updates with STORE: the server would otherwise have to maintain a record of client state. It already has to keep track of its own state, and the state of the mail store. Resolving three states is much harder than resolving two states. The protocol is consistent. You just have to look at it in the right way. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
