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

[Orie Steele <[e-mail]>]

<no hat>

Sounds like the advice is:

For more specific media types such as gordian envelope, make it clear that
while they might end in +cbor they are actually a subset of cbor / dcbor.
As you have said this is essentially the same as what we do today, when
creating more specific media types for cbor based application formats.
This advice belongs in the dcbor draft, but a new media type for generic
"application/dcbor+cbor" is maybe not needed since we don't expect any
protocols to use generic "application/dcbor+cbor" or really even
"application/cbor" when they have more specific media types available such
as:

application/cose (which is never dcbor)
application/cwt (which is never dcbor)
... https://www.iana.org/assignments/media-types/media-types.xhtml (anything
with +cbor, is only dcbor when it says its dcbor)

... and it's forbidden to update a media type that was previously cbor to
dbor because doing so would create a breaking change.

I think this advice is worth writing down.

OS



ᐧ

On Thu, Mar 28, 2024 at 9:33 AM Carsten Bormann <[e-mail]> wrote:

> Hi Orie,
>
>
> On 2024-03-28, at 15:10, Orie Steele <[e-mail]> wrote:
> >
> > Let me try my argument one more time, and if it doesn't land, then maybe
> I'm chasing ghosts.
>
> This thought experiment makes some assumptions about what people could be
> doing that fall firmly into “don’t-do-that-then” [1] land with me.
>
> [1]: http://www.catb.org/jargon/html/D/Don-t-do-that-then-.html
>
> > Let's say you have a CWT based protocol that is supposed to implement
> dcbor,
>
> CWT is not based on dCBOR, so I don’t know what that would mean.
> (OK, maybe that new protocol is a variant that is *not* a CWT but
> otherwise similar, let’s call it NCWT.)
>
> > and that spans multiple middle boxes.
>
> And that is definitely a good scenario to test the above…
>
> > The protocol starts with a coin flip to decide which serialization to
> use "cbor or dcbor".
>
> After the coin flip, it would need to tell the result, e.g., by using a
> different media type.
>
> > 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”,
>
> Well, both media types (assuming there will be a dcbor+cbor) are
> non-specific and therefore do not provide much of a handle to do any
> application processing.
>
> > 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".
>
> Yes.
> But it would be much better to use media types that are more specific as
> to the application protocol.
>
> > I think the recommendation for such a protocol would be to define a more
> specific dcbor based media type, like "application/foo+cbor",
>
> Exactly.
>
> > but then in the media type registration cite dcbor instead of normal
> cbor....
>
> Exactly.
>
> > I suspect that people won't read this registration and will look at
> "+cbor" and assume "undefined" and "weird numbers", are allowed.
>
> But there is never an assumption that foo+cbor allows all of CBOR; we
> usually try to provide some CDDL or other specification that defines (and
> thus restricts) the application data model.
> Intermediates that randomly insert data items into an application protocol
> they don’t understand are destructive.
>
> > That's the argument I am trying to articulate, is this a concern?
>
> The usual response here would be “let’s write some text then” (e.g., for
> the security considerations to discuss check/use vulnerabilities).
> But if your assumption is that people don’t read, that won’t help.
>
> Grüße, Carsten
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>