Re: [Cbor] Combining CBOR protocol libraries

[Brian E Carpenter <[e-mail]>]

On 21-May-21 10:25, Laurence Lundblade wrote:
> 
>> On May 20, 2021, at 2:45 PM, Brian E Carpenter <[e-mail]> wrote:
>>
>> On 21-May-21 07:37, Laurence Lundblade wrote:
>> ...
>>>
>>> So which is the better practice, byte-string wrapping for protocols or a requirement on your better CBOR decoders?
>>
>> I don't see how having a class of "better" decoders works with interoperability. If we require that both ends have a "better" decoder, we've effectively forked CBOR, haven't we?
> 
> There’s always half-way implementations of protocols kicking around in GitHub and some of them may be useful in limited contexts. A CBOR 
decoder might also not implement preferred serialization, indefinite length string decoding and such and that is usually OK.
> 
> 
>>
>> We wrote this problem into the GRASP API (whose RFC, I understand, is less than 24 hours away):
> 
>> A requirement for all language mappings and all API implementations is 

>> that, regardless of what other options exist for a language-specific representation of the value, there is always an option to use a raw CBOR data 
>> item as the value. The API will then wrap this with CBOR Tag 24 as an encoded CBOR data item for transmission via GRASP, and unwrap it after reception. By this means, ASAs will be able to communicate regardless of programming language.
>>
>> I have some "interesting" code for this in my Python GRASP implementation, which decides on the fly whether to build a Tag24 or not, and if necessary de-tags an incoming Tag24 item. In other words, I had to write a nano 
>> encoder/decoder into my own code.
> 
> So I take it you prefer byte-string wrapping as a best practice?

I think so, for the reason in my quote from the GRASP API - it allows you 
to be reasonably certain of being language-independent.

    Brian