the type of a collection

[thomas-fossati]

Since #67 a CMW can also be a collection.

But now we have introduced a slight asymmetry: the typing mechanism we have for non-collection CMWs does not apply to collections, i.e., collections don't have an intrinsic way to describe their overall type.

Clearly, one can always define the media type of a given collection, but that's an extrinsic property and is not always useful.

Problems linked to this asymmetry have popped up in the use of CMW collections with the X.509 wrapper where the OID is not a sufficient indication for the processor to make sense of the wrapped CMW collection as a whole.

One possibility is to reuse the EAT approach and reserve a specific label for a type indicator, e.g.:

json-collection = {
  ? "__cmwc_t": uri / oid
  + text => json-CMW / c2j-tunnel
}
cbor-collection = {
  ? "__cmwc_t": uri / oid
  + (int / text) => cbor-CMW / j2c-tunnel
}

(Note the use of CDDL's cut in the definition which prevents further matching on the same "reserved" label.)

Note that we could derive automatic media types using the base application/cmw+cbor (or application/cmw+json) and add a t parameter with the value of the __cmwc_t key.

[nedmsmith]

What might a content author populate the ? "__cmwc_t": uri / oid with that is different from the text in text => json-CMW?

I'm afraid I don't understand the problem that this proposal fixes.

[thomas-fossati]

What might a content author populate the ? "__cmwc_t": uri / oid with that is different from the text in text => json-CMW?

An example:

{
  "__cmwc_t": "tag:example.com,2024:combined-evidence",

  "kat": [
    "application/kat+jwt",
    "eyJhbGci..."
  ],

  "pat": [
    "application/pat+jwt",
    "eyJhbGci..."
  ]
}

[hannestschofenig]

Thanks for quickly adressing this issue!