But tag 24 makes it harder for pedantic security devices to validate CBOR,
somewhat like an "eval" statement.
Well, eval is Turing-equivalent, while tag 24 has quite narrow semantics.
So the added onus should be much more limited.
Is a "strict mode" decoder required to decode/validate the contents of this
tag?
Good question.
In my mental model, the "CBOR data"-tagged byte string is handed to the
application, and this would then have to explicitly call the decoder again if
needed (usually in strict mode again).
If the application does task the decoder to decode it as well, the strict mode
should transfer to that (unless the application has explicitly said otherwise).
And security aside, this usage means that endpoints (sender and receiver)
work a bit harder, in order to make the life of middleboxes easier. This may
or may not be the right trade-off, depending on your architecture.
There may be other reasons for a sending application to facilitate deferring
decoding a part of the structure.
I'm not as sure about the continued importance of the premise here.
The premise seems to be "you are only middlebox-friendly if you provide a
highly efficient way to skip large swaths of coded data the middlebox happens
not to be interested in".
Unless the application knows precisely what the middlebox is trying to do (like
in Joe's routing example), this may be hard to achieve.
With the move to architectures where every byte needs to be touched anyway
(say, for encryption, or with transports like Minion), this also becomes less
relevant.
I'm pretty sure the encoder-friendliness of item-counting (as opposed to
byte-counting) approach trumps any middlebox-friendliness aspect here.
... switching messages here:
This is indeed good text. I suggest to also add: "A tag followed by an
aggregate data item (map or array) applies to all members of the data item."
This is not a property of tags in general. A tag tags just the one item it
contains.
(This sentence could be used to describe a specific property of the "expected
conversion" tags, but saying it this way might be confusing. For these three
tags, the additional onus of inheriting the "expected conversion" to byte
strings embedded in the tagged data item is only paid by JSON converters.)
Grüße, Carsten