[zeromq-dev] ZMTP 1.0 clarification

Pieter Hintjens ph at imatix.com
Sun Aug 17 14:26:17 CEST 2014


I'm going to answer these questions randomly and will probably miss some.

- http://www.ietf.org/rfc/rfc5234.txt defines VCHAR and such
- all string literals are case sensitive; so "ERROR" does not match "Error"
- larger numeric values are meant to fit into int32_t and int64_t,
however there is no significance to negative values as these represent
sizes. I could clarify that these are unsigned.
- metadata field names follow the HTTP conventions more or less. I'm
not sure this is ideal, and we can change that if there's a strong
argument either way
- duplicate header fields can be treated sympathetically, by taking
the last value. Or, brutally by disconnecting the client. I've no
opinion on this, as we lack data either way.


On Sat, Aug 16, 2014 at 11:44 PM, Merijn Verstraaten
<merijn at inconsistent.nl> wrote:
> 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
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list