[rabbitmq-discuss] ? short-string encoding and rabbitmq 2.0.1

[Michael Bridgen]

James,

>> <snip>
>>> i understand this, and the code in the repository[3] to indicate that
>>> the 115,6,83 at the start of the fourth line of the content vector,
>>> above, was decoded as a short 16/signed instead of the intended six byte
>>> short string. given which state, the subsequent vector
>>> <<84,82,73,78,71,7,80, ...>> matched no pattern. do i understand these
>>> events correctly?
>>
>> Yes.
>>
>> See http://dev.rabbitmq.com/wiki/Amqp091Errata#section_3 for a bit
>> more information, but in short this is an area where we believe the
>> spec to be incorrect.
>
> ok. it would help, if the page which describes that rabbitmq implements
> 0.9.1 were to include something to the effect that the specification
> which version 2 purports to support is not the one to which the page
> links, but some other. perhaps it could also include a link to that
> other specification, or at least to the wiki errata page. perhaps the
> release notes page could include the topic. or perhaps the release news
> page.

In general RabbitMQ tries very hard to implement the letter of the 
specification; however there are a few things in the published AMQP 
0-9-1, as in most specifications, that are either ambiguous or 
inconsistent.  In those cases we set out in the errata what is it 
RabbitMQ /does/ do.  This is not an unusual situation.

As an egregious though amusing example, see the published *AMQP 0-8* 
specification under the heading "4.2.2 Protocol Header".

If you are cross because this cost you time and effort, then I 
sympathise -- we've spent rather a lot of time and effort ourselves 
trying to implement 0-9-1 in a way that it consistent /and/ 
interoperates with other implementations.

>> The upshot is that there isn't a way to put short strings in tables;
>> you have to use long strings.
>
> evidently.
> the question remains, whether rabbitmq's intention is that, a library
> which purports to implement the standard now needs to not only negotiate
> protocol version, but also implementation?

Sadly, it is a choice between being faithful to the specification and 
working with the implementations extant.  For us, too.

[...]
> can one expect
> that discussion to proceed to a conclusion? to a ratified errata for the
> specification itself? if one expects implementors to follow a ratified,
> published, standard specification to which the implementations purport
> to conform, that would be appropriate.

I'm not going to disagree.


Michael.