According to the "Backwards Interoperability" sections of RFC15 and RFC23, bit 0 of the flags field is used to probe whether the peer is using ZMTP/1.0. So now it needs to be left as %x7F.
On Mon, Aug 12, 2013 at 7:13 AM, Pieter Hintjens <p...@imatix.com> wrote: > On Sun, Aug 11, 2013 at 11:19 PM, Merijn Verstraaten > <mer...@inconsistent.nl> wrote: > > > RFC23 states that a backward compatibility detecting handshake starts as > follows: > > "Send a 10-octet pseudo-signature consisting of "%xFF size %x7F" where > 'size' is the number of octets in the sender's identity (0 or greater) plus > 1. The size SHALL be 8 octets in network byte order and occupies the > padding field." > > > > However, RFC13 states that ZMTP1.0 long length messages follow the > format "%xFF size flags", where bit 0 of flags specifies whether there are > more messages to come, which is wrong for an identity frame. Do existing > ZMTP1.0 implementations simply ignore this flag on identity frames? > > Good catch. For sure ZMTP 1.0 implementations don't check this, but > I'm wondering why we chose %x7F. That might be a mistake, based on the > explanation of the flags field in RFC 13 (bit 0 is put before bits > 1-7). I suspect the intention was to create a valid frame, with the > reserved bits all set to 1. So, %xFE. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
