[zeromq-dev] Proposal/request for ZMTP 3 command encoding change.

[Merijn Verstraaten]

Ola!

As I mentioned on here a while back, I've started working on an alternative implementation in Haskell. I've run into one annoyance with the current spec and, since libzmq the protocol hasn't even been fully implemented yet, I'd like to take to propose I small change before implementation work is done.

Almost everything in the protocol is fixed length or length encoded (which is great, it makes a implementing a streaming parser for the protocol really easy!), with 1 notable exception. The command-name is variable length. The ABNF for commands is below:

command = command-size command-body
command-size = %x04 short-size | %x06 long-size
short-size = OCTET          ; Body is 0 to 255 octets
long-size = 8OCTET          ; Body is 0 to 2^63-1 octets
command-body = command-name %x0 command-data
command-name = 1*VCHAR
command-data = *OCTET

This is rather annoying, because this now means you have to scan until you find %x0 to figure out the command length and without the command length it is impossible to compute the length of command-data.

I would like to propose changing the ABNF for command-name to:
command-name = name-length name
name-length = OCTET
name = 1*255OCTET

That is, prefix the command name with a 1 byte length indicator. A fixed length command-name would work too, but would likely cause significantly more overhead than a 1 byte length indicator and I think everyone will agree that there's no real reason to allow command names longer than 255 bytes anyway.

A similar issue applies to the authentication mechanism name, but since that is embedded in a field that has a fixed 20 byte length, at least it doesn't interfere with the parsing of incoming data.

Cheers,
Merijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130728/76724f9b/attachment.sig>