Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.ietf@xxxxxxxxx> 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]}






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]