Got it, thanks for the example.
But tag 24 makes it harder for pedantic security devices to validate
CBOR, somewhat like an "eval" statement.
Is a "strict mode" decoder required to decode/validate the contents of
this tag?
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.
Thanks,
Yaron
On 2013-08-17 00:58, Joe Hildebrand wrote:
On 8/15/13 1:26 PM, "Yaron Sheffer" <yaronf(_dot_)ietf(_at_)gmail(_dot_)com>
wrote:
One of the reasons why I like the CBOR tag applied to a byte stream is
that
it can be used to skip parsing on entire sections (no matter their
underlying types) in processors that don't need to understand that
section.
I suppose you mean you don't understand the section at a semantic level
(e.g. you don't understand the map "section-7") but you do need to parse
every last data item in the section before you know its byte length. So
at a syntactic level you don't skip anything.
Example:
{"to": "you", "from": "me", "content": 24(h'a26161016162820203')}
If I'm just routing this based on the "to" address, I don't need to parse
the
"content" value. If I'm the end recipient, I can either put my parser
into a
mode that parses into CBOR (tag 24) blocks, or I can feed the byte string
I
get for "content" from a generic parser back into that same parser.
Either
way, I find out that the "content" is:
{"a": 1, "b": [2, 3]}