[zeromq-dev] Is ZMTP3 backwards compatibility with ZMTP1.0 broken?

[Merijn Verstraaten]

This is not necessarily a problem, if we retroactively define ZMTP1.0 to ignore the more flag on identity frames, which the current C++ implementation already seems to be doing.

Cheers,
Merijn

On Aug 12, 2013, at 01:45 , KIU Shueng Chuan wrote:
> 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 <ph at imatix.com> wrote:
> On Sun, Aug 11, 2013 at 11:19 PM, Merijn Verstraaten
> <merijn at 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 at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130812/01f222da/attachment.htm>
-------------- 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/20130812/01f222da/attachment.sig>