Here's an unstructured list of some things that need to be addressed in a standards document. More will follow later.
1. Private extensions. Obviously the protocol is easy to extend just by adding new commands. To bring some order I suggest the following:
Standard commands are limited to use the characters [a-z_0-9] and must start with a character in [a-z], i.e. only lower case English letters, underscore, and digits, starting with a lower case letter.
Private commands are limited to the same characters plus hyphen and are suggested to be of the form "x-y" where "x" is a program specific prefix, e.g. gg for GNU Go and "y" is the rest of the command name. One example of a private command could be "gg-owl_attack".
I don't think we need to keep any official list of prefixes. These commands should be program-specific anyway.
2. Newline conventions That different systems tend to use different newline conventions is a problem that must be addressed by the standard. Personally I prefer the unix convention of a single LF but it probably would invite problems not to accept the presence of CR. My proposal is that all occurences of CR are simply ignored and that an LF defines a newline. This would work with systems using only LF or CRLF but obviously not with systems using only CR. Would this be a (significant) problem? Are there any better solutions? I'd really appreciate input on this point.
3. Case sensitivity Should the protocol in general be case sensitive or not?
4. Unknown command versus unimplemented command. I don't think it's useful to distinguish between unknown commands and unimplemented commands. Thus a program should respond with "?[id] unknown command" to everything it doesn't recognize or knows it can't handle. Currently GNU Go does like this:
| 1 fds | ?1 unknown command: 'fds'
I think we should skip everything following "unknown command".
/Gunnar