Hi, > The server should allow exactly what the standard allows. > Acting silly is > a privilege that clients have. Servers don't. ;-) Compliant > silly behaviour > is not something the server should try to fix. In an ideal world, the > server should stand and the client should try to be less silly. ;-)
Does this not justify the argument that the syntax should be better defined, and by that I include the concept of taking ease of implementation into consideration. You statement regarding command/response case is such an issue. By allowing the format syntax responses and commands to be upper/lower case you add extra processing in both the client and server to handle both cases. This in an overhead that could be avoided by the use of a stricter definition of the protocol. Why allow FETCH , fetch, FeTcH, fETCh at all? Just state in the protocol that the command is "FETCH" case sensitive. I have seen clients that like NIL or nil but not Nil or nIL. Surly from the point of view of interoperability a strict protocol is better than a loose one. I'm not arguing that the server should implement what it thinks the protocol should be. But coders will write what the think the procol means and the less explicit the protocol the more room for misinterpretation. Remember "I know you think you understand what I said but I didn't say what I meant". Richard.
