I think you have misunderstood me. I agree that MessagePack makes no distinction in the type between unsigned and signed integers and I agree that it is correct for a general decoder to erase the distinction (or, to put it another way, to decode all the integer typecodes from MessagePack into a single kind of thing "integer"). I can see why some of my writings here could give the contrary impression but I think the spec is clear that these are different representations of the same type, not different types.
It's true that you gave references to some people who seem to have been confused about this at some point and I agree that it might be good to add a sentence to the MessagePack spec to clarify this. However, it doesn't seem to have been a problem serious enough to cause any of the implementations to get this wrong.
It's literally the only occurrence of RFC2119 SHOUTING in the document.
I really dislike RFC2119 and this kind of thing is one of the reasons why. It seems perverse to suggest that a recommendation is stronger because it uses a predefined term whose definition is explicit in its non-mandatoriness. Whether this should is stronger or weaker than the three other "should"s, two of which are in upgrade notes for implementors, is not clear.
It's certainly clear that it's not mandatory. Referring to the definition from RFC2119:
there may exist valid reasons in particular circumstances to ignore particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Well, the implications of not choosing the shortest format are pretty obvious.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Re: I think you're wrong on several of the technical aspects
Date: 2020-07-15 02:33 pm (UTC)It's true that you gave references to some people who seem to have been confused about this at some point and I agree that it might be good to add a sentence to the MessagePack spec to clarify this. However, it doesn't seem to have been a problem serious enough to cause any of the implementations to get this wrong.
I really dislike RFC2119 and this kind of thing is one of the reasons why. It seems perverse to suggest that a recommendation is stronger because it uses a predefined term whose definition is explicit in its non-mandatoriness. Whether this should is stronger or weaker than the three other "should"s, two of which are in upgrade notes for implementors, is not clear.
It's certainly clear that it's not mandatory. Referring to the definition from RFC2119:
Well, the implications of not choosing the shortest format are pretty obvious.