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

Fri Oct 22 16:16:17 BST 2010

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.

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

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

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.

thanks,