Earlier, I propose everyone to post its draft. Here is mine.
It is a binary protocol:

1) the shell:

 2 bytes: pattern
 2 bytes: shell size (including everything even the pattern)
 2 bytes: command code (the name of the command)
 1 byte: number of parameters

2) the parameter

  A parameter is composed of 3 things:
  1 byte: parameter size (inclunding the size)
  1 byte: parameter meaning (see below)
  1 byte: parameter type (integer, UTF-8, ...)
  N bytes: parameter value

An example:

Using the previously posted example:

00 03 00 04 "Chat" 00 14 (20 character UUID) 00 0E "Hi everyone!\r\n"

I would have sent:

FF FF 00 2C XX XX 02 17 UU TT (20 character UUID) 10 VV YY "Hi everyone!"

FFFF => pattern
002C => shell size (I hope I have made no error :) )
XXXX is the code meaning chat
02 => 2 parameters
17 => the first parameter uses 23 bytes
UU means emitting user ID (parameter meaning)
TT is the code for UUID type
10 => the second parameter ises 16 bytes
VV means message (parameter meaning)
YY is the code for UTF8 string type

----------------------------------------------------
In a previous mail, I speak about variable type parameters. Imagine this (nearly same example has before):
FF FF 00 22 XX XX 02 0B UU YY "nickname" 10 VV YY "Hi everyone!"
Now, the user ID is sent as a string instead of its UID. I wonder how text based protocol can do this but I have also something harder (too hard to produce an example manually). You know the $Search query. Using a standard text protocol (only 1 command allowed, you have no limit, it is a draft :) ), produce me an example working for searching:
1) an mp3
2) an avi bigger than 2MB
3) an mp3 bigger than 2 MB but smaller  than 10MB
4) an avi or an mpg being bigger than 350MB but smaller than 700MB
The 2 first cases are easy, show me the third and the fourth :)
With a binary protocol like the one I describe above, it is easy:
*  case 3) 1 parameter has "string" type and value "mp3", the 2 nd has "size" type and value "2MB", the third has "size" type and value "-700MB".
*  case 4)  Just provide 2 strings parameters, 1 is "avi" and the second is "mpg".

Yes, yes, I know, who (but me :) ) will use such things. Let's try something more useful.
Imagine a private chat:
chat_command source_nick dest_nick chat_message
Easy. Whouldn't it be interesting to have a chat with more than 2 users, let's say N (N is not defined):
chat_command source_nick dest_nick1 ... dest_nickN chat_message.
You use less bandwith to receive the data than receiving N times the message with different nickname and the hub can handle this faster...


Opinions ? comments ?

Eric