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]

 



(leaving a full response to the authors, and responding to a couple of
points I found interesting)

On 8/13/13 3:11 PM, "Yaron Sheffer" <yaronf.ietf@xxxxxxxxx> wrote:

>- Arrays are prefixed by the number of elements but not by their length
>in bytes. And elements need not be all of the same size. So you cannot
>skip the array without fully parsing every last element. IIRC this is a
>major disadvantage compared to ASN.1 encodings.

>- And similarly to arrays, you cannot skip a map element without deep
>parsing of the element.

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 would reserve a part of the tag space
>for "private" application-specific allocations.

I like that.

>- One tag value you may want to consider adding is "critical" in the
>security sense of the word, i.e., an application is required to fail if
>it does not understand the value (probably best applied to map keys).

That's also an interesting idea.  If included, it would be best to add
this as soon as possible, and ensure that it gets added to the test
vectors, to avoid problems we've had in the past with inadequate
implementations of criticality.

>- In the "diagnostic notation", I suggest to use symbolic values rather
>than integers for tags, e.g. TAG_URI.

How would you deal with tags that your implementation doesn't understand,
then?

-- 
Joe Hildebrand







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