The IESG has approved the following document: - 'Concise Binary Object Representation (CBOR)' (draft-bormann-cbor-09.txt) as Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-bormann-cbor/ Technical Summary CBOR (Concise Binary Object Representation) is a new binary format for data structures. It is intended to be semantically similar to JSON, to be easy to encode and decode even in very constrained environments, to allow extensions without versioning, and to be reasonably compact. It is intended to provide a standard format that applications can use to exchange structured data, so the requested publication type is Proposed Standard. Review and Consensus The announcement of the -00 version on the appsawg list on 22 May provoked a blizzard of about 100 messages over the following three days. Several people asked whether the world needed yet another binary JSON format. The authors offered to add a discussion of other similar formats and how CBOR differs from them. A few people asked whether there should be a canonical version of CBOR. The authors explained why there isn't, but offered to add a discussion of how one might be defined as an extension. Others noted that all CBOR formats start with a length or count field, making streaming implementations difficult since they would have to buffer up potentially large amounts of data. After some back and forth, the authors offered to add chunked subformats and uncounted formats that use an end tag. One person noted that the discussion of translation to and from JSON said that CBOR bignums be translated to JSON integers, which would often lead to loss of precision in JSON implementations and suggested that the translation instead be to encoded binary data, to which the authors agreed. One other person expressed dissatisfaction with CBOR and sketched out the rudiments of an alternative, although he has not (as far as I can tell) further developed it. Nine people participated in the discussion. After the announcement of the -01 version on 29 May, there were about a dozen messages from the same people, generally positive and discussing minor technical issues. After the announcement of the -02 version later the same day, responding to that day's comments, there were no further messages, suggesting that the issues were handled to the satisfaction of the people in the discussion. There are at least four implementations, in Python, Ruby, Javascript, and Java. There are no outstanding technical issues. The end of section 7 has a TBD that should be deleted. During Last Call, the major issue involved whether it was appropriate to publish CBOR as Proposed Standard. Phillip Hallam-Baker opined that Experimental would be appropriate, and that for Proposed Standard it would be preferable to have a working group hash out the use cases and design criteria first, and agree on those before proposing one or mote standards. There was some support for this position, but no serious and reasoned objection, and in the end, consensus was clearly toward putting CBOR forth as a *Proposed Standard*, with the option of other proposals in future. Personnel The Responsible Area Director is Barry Leiba, and the Document Shepherd is John Levine
