Parser does not respect tag 24 - It does not defer the decoding of data with this tag about cn-cbor HOT 2 OPEN

Tag 24 actually takes a byte string for the embedded CBOR, and the code should be handling that just fine. I think what you are looking for is a slightly different tag, which I'll call "decode later" in this message (using tag 99 for exposition). Let's use the very simple data structure »17« as the example for the embedded structure (single integer, encoded as h'11').

With tag 24, you first encode the data structure, then wrap in tag 24: resulting diagnostic notation is 24(h'11') (click to see the bytes). This makes the embedded data item easy to skip in one pointer forward movement.

With a new tag "decode later", there would be no byte string wrapper, resulting in 99(17).
Useful support for such a tag would switch the decoder into a "skip mode", where decoding is still needed to determine the length of the embedded data item, but no data structure creation takes place; the decoder would then just provide pointer/length to the application.
A decoder that doesn't know/implement that tag would still decode, and would provide the decoded data item to the application, which may or may not be useful depending on the use case.

I think this is an interesting idea, and we may want to go ahead registering such a tag. Can you describe in more detail how you would use such a tag?

from cn-cbor.

That is what I get for reading the text and not reading the table above.

What I was looking for was a way to avoid having the extra length bytes of a bstr when wrapping a cbor object. Thus for the COSE specification I was thinking in terms of encoding the content for the plain text as:

plaintext : bstr / tstr / #6.24(any)

This would allow me to avoid the additional bytes associated with having a length for a cbor object that is then wrapped into a binary container. However I still need to say don't do the decoding now because doing a decode/re-encode operation is potentially problematic as my re-encode may not match your original encode operation (mostly definite vs indefinite lengths) but some re-ordering and such could occur as well. In COSE this would also be applied to the protected map and potentially to the associated authenticated data fields. The first is definitely a map and the second will most likely contain cbor data if used in a constrained world.

There is only a space savings if the length of the embedded data is more than 24 bytes - so it would be more likely to be a space savings in the case of signed/mac-ed plain text rather than for the protected header or aad cases.

This might also have uses in the case where you have posited using the current tag definition. I assume this is mostly to do layering of things. Thus an upper layer includes something from a lower layer but keeps them separate in terms of the encode/decoder.

from cn-cbor.