http://www.dolda2000.com/~fredrik/doldaconnect/protocol.html

This is just my opinion but I give my reasons:

Format:
======
CRLF vs CR: I think using a single character (not only CR) as command separator is better because it uses less bandwidth but also because it is faster to search (only 1 byte to compare instead of 2) and commands can be splitted using a simple strchr().

Quoting: That seems good to me but we must define how backslashes are handled when encountered inside double quote (ignore the \ and discard it or keep it working as outside double quote). I think backslash should work everywhere in the same way and more over, this will allow this "somewords\"otherwords".

Semantics:
========

Roles: DC without this architecture is not DC :)

Word sets: I think commands should be case-sensitive (for faster comparison) but we should forbid commands having same case-independent values (like toto and Toto).

User identification: ok for me.

Search criteria: we should also define the maximum number of reply a client can send.

Context: I don't understand the need of context in a client, I think the user privilege should be only maintain in the hub. With my hub for example, it is possible to have more than one "level" of operator with more or less privilege (some op can "only" kick users but some others can also modifiy the hub configuration). On connect, perhaps the hub should send a list of all commands a client can send (IMHO, a bit heavy).

References:
=========

DESC: someone still uses a 32bit integer to store the share ? ;)

About connection stage, I assume GUID is the first command you sent (correct me if I am wrong). Why not having the following connection establishment:


1: H=>C: the hub sends its ID (something like the GUID of the client but for the hub)

2: C=>H: the client sends its ID and its password simultaneously (I modified your "GUID ID" command into "GUID ID password"). Then we can do the full authentification in a single step and without error, thanks to the GUID of the hub

3: H=>C: the hub accepts an continue the process into "normal" mode or close the connection after a message.