Larry, my 20+ years wasted in this boring computer design field resulted in - guess what? - exactly the same opinion about the explicitly specified error codes, esp. when they are placed into the manuals (OS manuals ARE the specs, the same as standards) where they can be read by those who would be much better off reading something much more useful, like comics or Wall Street Journal.
I'm afraid that you did not get my point. I did not say "list all situation where the server must return the BAD response". I said - IF no better solution is found, list all KNOWN situations when the server must return the BAD code, list all KNOWN situations when the server must return the NO code, and EXPLICITLY SAY that in all other situations the negative response code is implementation-specific. And it looks like Mark has said that it was his/RFC2060 intention, too. Please note that I suggested this clause ONLY if no better definition was found. I've suggested a definition - BAD if the server cannot access the command in any situation, NO - if the negative response is caused by the current state of the session and/or message store. You've suggested a different approach: 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. I do not want to argue that mine is better. I would even say that if you look at them closer, they are almost the same: only my implementation would say "NO" when you try to do SELECT in a non-AUTHed state (as the current standard suggests), yours will say BAD in this case, but in most other cases they will result in the same error codes. 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. Without it, having 2 different error codes is useless, and - according to your own suggestion to avoid enumerating error codes, I'd suggest that only one negative code would be used :-) But - it would violate the current standard, it would break the clients, thus I've suggested the clause that (as I hope) would provide a guideline and would also be compliant with the current specs. If you do not like my guideline - it's 100% fine, I'd welcome any other guideline, I'm just asking for ANY guideline to be in the specs. On Thu, 26 Sep 2002 11:03:46 -0700 "Larry Osterman" <[EMAIL PROTECTED]> wrote: > Yes, I do suggest that there should be NO strict and explicit definition > for the cases when BAD should be returned instead of NO. > > Larry Osterman Sincerely, Vladimir
