Is there a registered media type for when using the structured clone extension

[lmaccherone]

I have noticed that if you encode with the structured clone extension but attempt to decode without it, cbor-x throws an error. I'm building an API where every response body is encoded in cbor-x with the structured clone extension, and I wonder how best to tell clients precisely what encoding is being used. RFC 6839 says you should not use an unregistered suffix like application/vnd.my-app+cbor-sc, so for now; I'm just using application/vnd.my-app+cbor and giving good documentation. I'm also catching the error thrown by cbor-x and explicitly mentioning that you need to use the structured clone extension in my error response. Still, I wonder if there is a valid way to specify it in the Content-Type header.

[kriszyp]

How to indicate which extension tags that need to be supported is a great question, and something we might want to pose to the IETF CBOR committee. I am inclined to thing this might actually be a good place to use media type parameters, and specify the tags that are need like:
application/cbor;tags=28,29,258,259
The structuredClone flag itself only enables/disables the use of tag 28 and 29, but plenty of other tags can be used depending on if you are serializing Dates, Maps, typed arrays, etc. (regardless of whether structuredClone is enabled). The list of tags that cbor-x tags employs/supports is here:
https://github.com/kriszyp/cbor-x#list-of-supported-tags-for-decoding
And the official IANA registry is here:
https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

However, I didn't think you should need to specific structuredClone flag on the decoder side, but I will take that up in the "issue" rather than this "discussion".

[lmaccherone]

I like your suggestion on tags as media type parameters.

On my end, I'm using new Ecoder({ structuredClone: true }).encode() and new Ecoder({ structuredClone: true }).decode(). If I want users to be able to use my API, which requires that duplicate object references are preserved, what media type string should I specify? Note, I don't need Set or Map support, just the duplicate object reference support.

I'd also like to understand more about tag 105.

1. It would be nice to have the benefits (speed and compactness) that you write tag 105 brings, but if support for other languages like Python and Java is sacrificed I'd rather not... or at least think about providing the option. It looks like your proposed tag 105 is not yet accepted. What's the likelihood that it gest accepted and when do you think that might happen? Do you know of any other CBOR libraries supporting it or working on supporting it?
2. Does structuredClone: true automatically enable tag 105? If so, can I turn it off but still get the duplicate object reference support with { structuredClone: true, useRecords: false }?
3. Does it work if there are optional keys? Let's say most of the time, the record looks like, { "name": "normally", "value": 1 } but sometimes it looks like { "name": "occassionally", "value": 10, "optionalField": "wow" }.