Document Writeup for draft-bormann-cbor-04
1. Summary
The Responsible Area Director is Barry Leiba, and the Document
Shepherd is John Levine
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.
2. 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 five implementations, by at least four independent
implementors, in C, 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.
3. Intellectual Property
The authors say they know of no intellectual property claims.
4. Other Points
The draft creates two new IANA registries, for CBOR Simple Values and
CBOR Tags, and a new media type application/cbor. The specifications
for each are sufficient, but the media type has not been reviewed on
ietf-types. The IANA registries are Standards Action, Specification
Required and First Come First Served. The change controller for the
media type is Carsten Bormann.
Phillip Hallam-Baker remains unhappy about this being put forth as PS,
and could well file an appeal on the grounds that the design criteria should
have been agreed upon first.