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]

 



Hi Joe,

please see below.

Thanks,
	Yaron

On 2013-08-14 01:20, Joe Hildebrand wrote:
(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 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.

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.

I agree this needs to go into the base spec ASAP, so that it really is treated correctly. And it certainly cannot be a later extension, as Paul suggested in another message.

Also note that "critical" can be applied to all sorts of data, including data items that are already tagged! I think this is not allowed for according to the spec. But the new "self-describing" tag that appeared in -05 suffers from the very same problem. It can be applied to things that need other tags. So supporting multiple tags may be a good idea after all.


- 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?


That's simple, especially if the diagnostic notation is really "write only" as Paul suggests. Just use the integer in this case.




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