[zeromq-dev] ZMTP 1.0 clarification

Merijn Verstraaten merijn at inconsistent.nl
Sat Aug 16 23:44:44 CEST 2014


And one more (sorry for the barrage of questions!): The length fields of, for example, property values and frames are specified as “1 octet”, “4 octets” or “8 octets”, but the RFC doesn’t mention signednes! For example, the 1 octect lengths are 0 through 254, so presumably that’s unsigned, but the max lengths for 4 and 8 octets are defined as 2^31-1 and 2^63-1 respectively, which seems to imply these values should be signed?

Cheers,
Merijn

On 16 Aug 2014, at 13:13 , Merijn Verstraaten <merijn at inconsistent.nl> wrote:
> Additionally, the spec uses string literals in many places, i.e. “READY” and “ERROR” as command names. The ABNF RFC specifies that literals should be matched case insensitively, does this also hold for the ZMTP RFCs? I hope not, as that makes parsing much more bothersome. Metadata field names are case insensitive, but does the same apply for, for example, the data in socket type? (Although I guess that answer follows from my earlier question of whether string literals are case insensitive like in the ABNF RFC).
> 
> Cheers,
> Merijn
> 
> On 16 Aug 2014, at 12:50 , Merijn Verstraaten <merijn at inconsistent.nl> wrote:
>> Hi Pieter,
>> 
>> Yes, I saw that short lengths can still be encoded by a long length value. Some more clarifications:
>> 
>> In ZMTP 3.x how are duplicated metadata fields in the authentication handshake supposed to be handled? Suppose a client sends two Socket-Type fields, or perhaps multiple identity fields. I’m guessing this should be treated as an error and disconnected via an ERROR command?
>> 
>> Also, I see some of the BNF’s using VCHAR, how is VCHAR defined? All printable characters or something else?
>> 
>> Cheers,
>> Merijn
>> 
>> On 16 Aug 2014, at 00:38 , Pieter Hintjens <ph at imatix.com> wrote:
>>> Yes, this is safe to say. However note that ZMTP v2 and later use a
>>> long length, and an empty identity, to handshake with older
>>> implementations. So while the first frame must be 255 or shorter, that
>>> length may be encoded in 1+8 bytes (not always 1).
>>> 
>>> -Pieter
>>> 
>>> On Sat, Aug 16, 2014 at 9:08 AM, Merijn Verstraaten
>>> <merijn at inconsistent.nl> wrote:
>>>> Ola!
>>>> 
>>>> I’m getting back to my own implementation of ZMTP, I’m trying to be backwards compatible and have a question about the ZMTP1 handshake. The spec states that identities must be between 1 and 255 bytes and the first message in a ZMTP1 connection contains the id. So it’s safe to say that any first message with a length > 255 is an error?
>>>> 
>>>> Cheers,
>>>> Merijn
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> 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 --------------
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/20140816/c350743c/attachment.sig>


More information about the zeromq-dev mailing list