> 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