Re: [Cbor] Unusual map labels, dCBOR and interop

[Orie Steele <[e-mail]>]

Wolf and Carsten,

Thanks for educating me : )

Let me try my argument one more time, and if it doesn't land, then maybe
I'm chasing ghosts.

Let's say you have a CWT based protocol that is supposed to implement
dcbor, and that spans multiple middle boxes.

The protocol starts with a coin flip to decide which serialization to use
"cbor or dcbor".

After deciding any time "cbor" is chosen, a random "dcbor incompatible data
element" (such as undefined, or weird numbers) is inserted into the
unprotected header by every middle box that supports "cbor" and not "dcbor".

My concern was that on the wire, the boxes will see "application/cbor", but
internally they will process them as "application/dcbor+cbor", hence it is
less safe for this protocol to use "application/cbor"... but it would be
more safe for this protocol to use "application/dcbor+cbor".

I think the recommendation for such a protocol would be to define a more
specific dcbor based media type, like "application/foo+cbor", but then in
the media type registration cite dcbor instead of normal cbor.... I suspect
that people won't read this registration and will look at "+cbor" and
assume "undefined" and "weird numbers", are allowed.

That's the argument I am trying to articulate, is this a concern?

Regards,

OS





ᐧ

On Thu, Mar 28, 2024 at 1:25 AM Wolf McNally <[e-mail]> wrote:

> Anders,
>
> On Mar 28, 2024, at 1:23 AM, Anders Rundgren <
> [e-mail]> wrote:
>
> All of this is fine, but none of this is in conflict with CDE.
>
>
> That is correct: dCBOR is a *specialization* of CDE.
>
> ~ Wolf
>
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>