On Thu, 26 Sep 2002 11:17:14 -0700, Vladimir A. Butenko wrote: > I'm not talking about "fixing" anything here. I'm talking about making the > standard a definitive document.
That's what I'm talking about as well; if the standard fails in some substantive way to be a definitive document, it needs to be fixed. On the other hand; if the failure is of academic interest only, and if the fix could create an "unfunded mandate" that would be an implementation burden, then it may be better to let it be. Thus, it is worthwhile to discuss the nature of any problems. We need to know both "is it a problem" *and* "is it worth fixing?" I have been paying attention to your arguments. Please take a look at draft 19 when it comes out. I hope that you will find it to be a great improvement. > the "current number of messages in the mailbox" is a fixed number, delivered > via the EXISTS response when the mailbox is selected. The current number > changes ONLY when (AFTER) the client receives the EXPUNGE or EXISTS response > from the server. I agree. Do you have a suggested place to add this? Perhaps you should wait until draft 19 comes out, then suggest an specific place and wording where this should go in. > This actually implies that the server must maintain "ghosts" for all those > messages that it has deleted (by request of some other client), but for > which it has not delivered the EXPUNGE response to this client. I agree about this implication. RFC 2180 discusses this at length. > I'd also > vote for the clause in the specs that the server must NOT show a new message > (in the FETCH, SEARCH responses) before it sends the EXISTS response to the > client. I agree. Once again, once draft 19 comes out, please suggest a specific place and wording where this should be added. > See the "the client takes the appropriate action for the response, and reads > another response from the server". I have to conclude that because the > client is required to read another request after getting untagged data, that > untagged data cannot be sent AFTER the "+" request, since after the "+" > request the client cannot sit and wait for/read another response from the > server - the server may not send anything. In the case of an synchronous client, that is true. But a client could be asynchronous. In any case, since the client command is still being read, there is no "command in progress". It isn't even known if the command will end up in a BAD or not. * is an ambiguous case, I agree; but since it's a timing race I don't see how it can be avoided. The more important thing is to forbid untagged EXPUNGE in that case, and RFC 2060 does that. In any case, if you have specific suggestions for clauses to add or wording to change, please do so. But, I suggest that you wait for draft 19 (later today or tommorrow) to make sure that your concerns aren't already addressed. > responses sent BEFORE the "+" request are responses sent "when no command is > in progress". Responses sent AFTER the "+" request cannot be considered as > responses sent "when no command is in progress" - the client might have > already sent the complete command, and those responses cannot be considered > as "sent with the continutation request", since for the server the > "continuation" phase should be considered complete as soon as it sends "+". I agree, but only to the extent that it's a timing race, and could be interpreted either way. That is, anything sent after + could be sent "with" it or maybe it can't be sent with it. > If a client is truly asynchronous, it would not need any IDLE > or NOOP command. Not quite. Both client AND server need to be asynchronous. Also, a synchronous server has to be careful not to fill its TCP window and deadlock (this is cautioned against in RFC 2060). Also, there needs to be some command, at some interval, so that each side is assured that the other is still alive. > most existing clients are synch ones, so the protocol has to > include this phrase: "Server implementations that send such responses MUST > deal with flow control considerations.". How can they? Can they assume that > a channel can consume one untagged * FETCH 123 FLAGS (), but it will block > if they send 20 of those? That's a good question. Perhaps the underlying TCP provides a "get free window space" call, or has a "write all or none" call. I leave this for the implementation to decide. IMAP was originally intended to be asynchronous (or rather, asynchronous with data but not command/responses), but the temptation to write synchronous clients was equally clear from the onset, and the memory of bad experience with the CCA Datacomputer (which was asynchronous) vs. one of its major clients (DFTP, which was synchronous) lead to an early realization that it was difficult indeed to write an asynchronous server that would not get into difficulties. The thing that caused the real problem was the idea of having multiple commands in progress at a time and hence the need for tagged commands -- this is what changed the original IMAP to IMAP2. This was never very commonly used, but some people thought that it was very important in the early days. The motivation was the notion that a FETCH or SEARCH might require an operator to change a disk pack or mount a tape to get to the data, and you might want to do something else while you were waiting... Of course, the world has changed since then. IMAP servers rarely are in a situation in which a response will take a long while, but the server can do something else while you wait. It would have been much easier to make IMAP clients and servers asynchronous if only untagged data was asynchronous, and commands and responses remained synchronous. That only would have required the client to keep a thread listening on input. The requirement added in IMAP2 that commands and responses also be asynchronous made it much more complex, and few people have ever figured out how to do it. And finally...: > What I'm asking for is the METHOD, a GUIDELINE for a server implementor to > decide if the negative response should be sent as NO or as BAD - such a > guildeline to be placed into the protocol specs. I agree that this should be done. Larry's notion of "use NO when the message can/should be presented to the user, use BAD when the servers sees this as a bug in the client" is closer to my thinking than yours, but perhaps we can come up with some sort of unified wording that makes us all happy. I know that I'm sounding like a broken record, but when draft 19 comes out, please suggest a specific text and point of insertion into the document. It's pretty clear that there will be a draft 20. Draft 19 has a lot of big changes, and I'd like to address your points in draft 20.
