[6tsch] Fwd: Protocol Action: 'Concise Binary Object Representation (CBOR)' to Proposed Standard (draft-bormann-cbor-09.txt)

["Pascal Thubert (pthubert)" <[e-mail]>]

FYI

Pascal

Début du message transféré :

Expéditeur: The IESG <[e-mail]<mailto:[e-mail]>>
Date: 14 septembre 2013 00:10:16 UTC+02:00
Destinataire: IETF-Announce <[e-mail]<mailto:[e-mail]>>
Cc: RFC Editor <[e-mail]<mailto:[e-mail]>>
Objet: Protocol Action: 'Concise Binary Object Representation (CBOR)' to Proposed Standard (draft-bormann-cbor-09.txt)
Répondre à: <[e-mail]<mailto:[e-mail]>>

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