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(_dot_)ietf(_at_)gmail(_dot_)com>
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.