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

[Emile Joubert]

Hi James,

On 22/10/10 16:16, james anderson wrote:
> good afternoon;
> 
> thank you for your note.
> 
> On 2010-10-22, at 13:53 , Simon MacMullen wrote:
> 
>> On 22/10/10 12:44, james anderson wrote:
>>
>> <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.

That is a good suggestion, thanks.

>> 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?

That should be possible by inspecting the server properties which are
returned by the server during protocol negotiation. If a library wishes
to use short strings and interoperate with multiple brokers then that
would be the only way at present.

> the errata describes a mail thread which includes contributions from
> tony [garnock-jones] and john o'hara. a link would be helpful here.

That discussion may not have taken place in public.

> without additional background, it is difficult to comprehend, why a
> standard would set one encoding and two prominent implementations would
> "gratuitously" disregard it. given the versioned nature of the protocol,
> as demonstrated by the variations to framing, there is no inherent
> reason that the type codes be identical across version. there must have
> been more at issue than the errata describes.

I can assure you that there is nothing gratuitous about the way RabbitMQ
interprets the spec. We believe the spec contains a mistake in this case
and we have implemented what was probably intended.

> in any case, did their discussion ever progress further? 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.

The RabbitMQ project is in a good position to motivate that the
collected errata inform subsequent revisions of the spec. If concerned
members of the AMQP community such as yourself petition for this cause
then it becomes ever more likely.


Regards

Emile