Concise Binary Object Representation (CBOR)
draft-bormann-cbor-09

Thank you for working speedily to address my Discuss and Comments.

I have one small point remaining as captured from the email thread....

> > I don't think you particularly made the case for the need for CBOR
> > compared with, for example, ASN.1 BER.  I actually think it detracts
> > from your document to make the claim of being better than ASN.1 BER, and
> > I would prefer your document to just get on with defining CBOR and
> > showing how it works.
> 
> We were asked repeatedly for the comparison during the early discussion.

Yes, I can well believe that the comparison was requested. My point is that I
don't think you have made much of a comparison. The only point made is that the
serialized output for BER is "not particularly compact for many items" and that
"the code needed to decode numeric items can be complex on a constrained
device." I haven't done the cross-check, but I did wonder whether some of the
"not particularly compact" cases were for items that are not present in CBOR,
and whether you were comparing like with like for numeric items.

But this is not a big issue for me, and if you make no change for it I will not
cry.

Thank you for writing a useful and much needed document. I think it has solid backing from those who build these "things".

I would probably personally have wanted to see slightly simpler format, but YMMV. I'm very supportive of publishing this as an RFC, though as other ADs have said, perhaps it would be enough to make it Informational or at least state that it is "a way" to package data.

Having heard the dicussion on the status, and whated it play out on the IETF list, I'm moving to no objection. specifically not objecting the status of PS.

I don't see that this has to go for standards track. However, Pete has raised this in his ballot already.

I can't emphasize enough that binary encoding/decoding has been outside my areas of expertise since I was using ASN.1 in 1991, so please weigh these comments appropriately.

In the Abstract

   The Concise Binary Object Representation (CBOR) is a data format
   whose design goals include the possibility of extremely small code
   size, fairly small message size, and extensibility without the need
   for version negotiation.  These design goals make it different from
   earlier binary serializations such as ASN.1 and MessagePack, or other
   binary serializations that may be created in the future.

I find a statement about why CBOR differs from other binary serializations that don't exist yet to be odd :-) 

In 3.5.  Handling Unknown Simple Values and Tags

   A decoder that comes across a tag (Section 2.4) that it does not
   recognize, such as a tag that was added to the IANA registry after
   the decoder was deployed or a tag that the decoder chose not to
   implement, might issue a warning, might stop processing altogether,
   might handle the error and present the unknown tag value together
   with the contained data item to the application (as is expected of
   generic decoders), might ignore the tag and simply present the
   contained data item only to the application, or take some other type
   of action.

Just checking - is this level of flexibility normal for decoders? I wouldn't be surprised if the answer is "yes", but I'm reading this paragraph as saying "if you send a CBOR decoder a tag that it doesn't recognize, you can't be surprised at anything that happens next" - is that an accurate paraphrase?

In 5.1.  Extension Points

   o  the "additional information" space.  An implementation receiving
      an unknown additional information has no way to continue parsing,
      so allocating codepoints to this space is a major step.  There are
      also very few codepoints left.

Having lived through a couple of "allocating the last bit" exercises with other protocols, I'm wondering if there is any alternative to approving a proposed standard that's intended to be useful for decades, with an almost-exhausted "additional information" space when it goes out the door. If there's not ... at least, I asked.

Thanks for the definite length answer that cleared up my 
discuss point :-)

-----

Comments below here are the original ones for -06.

- I'm not sure I agree that the IETF LC result was that clear.
ISTM that there were more voices arguing coherently that CBOR isn't
ready for PS yet, or that a WG should consider this topic further.

- I no longer buy the argument that you're meeting the stated
design goals - a fully featured library for all this will have a
lot of code. Absent some openwrt-like build process that'll not be
so useful, and I don't think that selection of CBOR specific
features is likely to be understandable to most application
designers.

- abstract: the design goals don't make the result different,
rather the designer does that and we have no idea if CBOR will or
will not be similar to some future encoding format.

- I don't think the lwig class 1 is well defined and nor do I think
this ought reference it.

- I can see major confusion as to when to use types 2 or 3.  I
think better guidance would be good here in the form of a (set of)
"do that" and "don't do that" statements. I realise that might be
guesswork right now, but if you don't guess now, and CBOR doesn't
fail, I bet bad practices will grow up that cause problems.

- this still reminds me of BEEP, sorry;-)

I have no objection to the publication of this information, but support the discusses raised.

I agree with Pete's concern about why this is PS and not Experimental. It may even reasonably be Informational, but PS expresses a level of endorsement that does not seem justified.

I have concerns as to how well this has been reviewed, and wonder how many people, independent of the authors, have done a line by line verification of the correctness of the text.

I would like to hear more about how consensus was determined on this document, but I don't object to it in principle.