Re: [Cbor] (d)CBOR session at IETF 118

[Anders Rundgren <[e-mail]>]

Wolf,
Pardon me for sending the previous response to the CBOR list; it was only intended for you and your colleges :(

Assumption: the anticipated standard profile(s) only deal(s) with the (proper) encoding of CBOR data items.

If we (the IETF), actually need two standardized and non-interoperable encoding profiles, we seem to lack information to why CDE doesn't cut it for certain classes of applications.

Since encoding 4.0 as 0xf94400 (CDE) or 0x04 (dCBOR) should be of no importance at the application-level (assuming the encoder/decoder adhere to the same conventions), the issue is (AFAICT) confined to the design of encoder/decoder APIs.  However, API considerations are not a part of the current dCBOR draft.

Thanx,
Anders


On 2023-11-05 11:17, Wolf McNally wrote:
> Anders,
> 
> We're working towards a COMMON standard with dCBOR, and the numeric reduction is a key feature, not a deviation. It’s there by design because it’s needed for the applications we and others are building. Your preference for a single, unifying standard is noted, but the benefits of dCBOR, including numeric reduction, serve specific use cases that justify its existence.
> 
> I take your support for CDE as your personal stance rather than an objective assessment of dCBOR's merit. Different use cases may necessitate different profiles, and that doesn’t imply a “defeat” for either.
> 
> I understand the concern for fragmentation, but the real-world application and the demonstrated preference of some community members for dCBOR’s approach, particularly regarding numeric reduction, suggest a single profile does not suit all. If the use case demands it, differentiation is not only justified but necessary.
> 
> ~ Wolf