The message encoding might look something like
<command>:<argument>:<argument>:<argument>
where <argument> was \ escaped to protect from internal | or :'s and
command was defined to never contain : or |. This way, you could always
read a block of bytes into a list/array of arguments with the same decoding
rules.

why not switch to a 100% text based client (with CR as command separator), someone mentions it earlier. And in any case, why not using XML based protocol, it is fairly easy to handle, well defined (without incorrect interpretation error), easy to extend and provides native UTF8 encoding.

that acts on or generates a message, but should have to edit the code that
encodes/decodes messages.

Requirements would be
     - EVERY hub that supports the new encoding scheme MUST support
       the old scheme
     - Every message is encoded/decoded with the same set of rules
     - No binary values

you have a problem here. You say you only want to modify the function that encodes/decodes message but this implies a generic function and a generic function will not convert the $MyInfo binary value into a non binary one.

     - One-to-one mapping from old messages to new messages
     - One protocol addition. A new message 'Supports' that identifies
       the commands a client supports sent immediately after it is decided
       that the new encoding method is being used.

So in the end, I would really prefer a new encoding scheme with a defined
way of extending it (supports).

IMHO, it is definitely the first thing to do.

Eric
DCTC/dchub