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

[Ballot comment]

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;-)

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

in tracker
IANA Actions - YES

This review is completed based on draft-bormann-cbor-06.

IANA has questions about some actions requested in the IANA
Considerations Section of this document.

IANA has a comment for one of the requested actions.

IANA Question -> this version did not clearly say if this CBOR Simple
Values registry and the CBOR Tags registry should be stand-alone
registries or grouped together in a master repository for current
and future CBOR registries.  Please confirm that.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are five actions which IANA needs to complete.

First, a new registry will be created called the "CBOR Simple Values" registry.

Maintenance of the registry is done using the following requirements as defined in RFC 5226:

0-19 - allocated through standards action
24-31 - reserved
32-255 - allocated through specification required

Note: It is suggested that these Standards Actions allocate values
  starting with the number 16 in order to reserve the lower numbers for
  any contiguous block.
 
There are initial values in the registry, as follows:

Value      Semantics              Reference
----------- ---------------------- ----------------
0-19        Unassigned
20          False                  [ RFC-to-be ]
21          True                  [ RFC-to-be ]
22          Null                  [ RFC-to-be ]
23          Undefined value        [ RFC-to-be ]
24-31      Reserved
32-255      Unassigned

Second, a new registry will be created called the "CBOR Tags" registry. The registration rules for the new registry are as follows:

0-23 - Standards Action
24-255 - Specification Required
256-18446744073709551615 - First Come First Served

There are initial registrations in this new registry and all (except for unallocated) will have a reference of [ RFC-to-be ].

+--------------+------------------+---------------------------------+
| tag          | data item        | semantics                      |
+--------------+------------------+---------------------------------+
| 0            | UTF-8 string    | Standard date/time string;      |
|              |                  |                                |
| 1            | multiple        | Epoch-based date/time;          |
|              |                  |                                |
| 2            | byte string      | Positive bignum;                |
|              |                  |                                |
| 3            | byte string      | Negative bignum;                |
|              |                  |                                |
| 4            | array            | Decimal fraction;              |
|              |                  |                                |
| 5            | array            | Bigfloat;                      |
|              |                  |                                |
| 6..20        | (Unassigned)    | (Unassigned)                    |
|              |                  |                                |
| 21          | multiple        | Expected conversion to          |
|              |                  | base64url encoding;            |
|              |                  |                                |
| 22          | multiple        | Expected conversion to base64  |
|              |                  | encoding;                      |
|              |                  |                                |
| 23          | multiple        | Expected conversion to base16  |
|              |                  | encoding;                      |
|              |                  |                                |
| 24          | byte string      | Encoded CBOR data item;        |
|              |                  |                                |
| 25..31      | (Unassigned)    | (Unassigned)                    |
|              |                  |                                |
| 32          | UTF-8 string    | URI;                            |
|              |                  |                                |
| 33          | UTF-8 string    | Base64url;                      |
|              |                  |                                |
| 34          | UTF-8 string    | Base64;                        |
|              |                  |                                |
| 35          | UTF-8 string    | Regular expression;            |
|              |                  |                                |
| 36          | UTF-8 string    | MIME message;                  |
|              |                  |                                |
| 37..55798    | (Unassigned)    | (Unassigned)                    |
|              |                  |                                |
| 55799        | multiple        | Self-describe CBOR;            |
|              |                  |                                |
| 55800+      | (Unassigned)    | (Unassigned)                    |
+--------------+------------------+---------------------------------+

Third, this document requests adding a media type to the applications media type registry located at:

http://www.iana.org/assignments/media-types/application/index.html

The media type to be added is:

cbor

Fourth, in the CoAP Content-Formats registry located at:

http://www.iana.org/assignments/core-parameters

the following Content-Format will be added to the registry:

Media type: application/cbor
Encoding:
ID: 60
Reference: [ RFC-to-be ]

Fifth, in the Structured Syntax Suffix Registry located at:

http://www.iana.org/assignments/media-type-structured-suffix

a new suffix will be registered as follows:

Name: Concise Binary Object Representation (CBOR)
+suffix: +cbor
References: [ RFC-to-be ]
Encoding considerations: CBOR is a binary format.
Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +cbor SHOULD be as specified for "application/cbor".  (At publication of this document, there is no fragment identification syntax defined for "application/cbor".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+cbor" SHOULD be processed as follows: For cases defined in +cbor, where the fragment identifier resolves per the +cbor rules, then process as specified in +cbor.  For cases defined in +cbor, where the fragment identifier does not resolve per the +cbor rules, then process as specified in "xxx/yyy+cbor". For cases not defined in +cbor, then process as specified in "xxx/yyy+cbor".
Interoperability considerations: n/a
Security considerations:  See Section 8 of [ RFC-to-be ]
Contact: Apps Area Working Group (apps-discuss at ietf.org)
Author/Change controller: The Apps Area Working Group.

NOTE:
The Structured Syntax Suffix Registry is managed through Expert Review
as per RFC 6838.  IANA will initiate a request for a new suffix and
send this to the designated expert (Ned Freed) for review.

IANA understands that these five actions are the only ones required upon approval of this document.

Thank you,

Pearl Liang
ICANN


On Thu Aug 22 19:03:07 2013, iesg-secretary@ietf.org wrote:
> Evaluation for  can be found at
> http://datatracker.ietf.org/doc/draft-bormann-cbor/
>
> Last call to expire on: 2013-08-13 00:00
>
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
> Barry Leiba          [ X ]    [  ]      [  ]    [  ]
>
>
> "Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
> with no "Discuss" positions, are needed for approval.
>
> DISCUSSES AND COMMENTS
> ===========
> ?
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor
> Subject: Protocol Action: 'Concise Binary Object Representation
> (CBOR)' to Proposed Standard (draft-bormann-cbor-04.txt)
>
> The IESG has approved the following document:
> - 'Concise Binary Object Representation (CBOR)'
>  (draft-bormann-cbor-04.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
>
>

[Ballot comment]
I agree with Pete's concern that this should probably not be PS.  It seems like Informational would be sufficient.

It would be helpful in Table 1 and Table 2 if you could include the hex values for the whole initial octet, for the values displayed (0xFF for stop code, 0xF4 for False, etc.)

The tag system described in Section 2.3 / 2.4 seems like a whole lot of unnecessary complexity, especially for things like "URI" and "base64url".

[Ballot comment]
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.

[Ballot discuss]
This is one of those DISUCSSes where I want to say to the authors: "Don't panic!" I want to have this DISCUSSion because I'm really not sure I know the answer; I'm not saying, "I think this is wrong and I want some time to explain why it is wrong." So please indulge me if you would.

I'd like to hear some more about why PS is appropriate for this instead of Experimental. This was not the product of a chartered work item where people understood and came to consensus on what problem they were trying to solve and then came to consensus on the solution. Instead, some individuals had an idea about a problem to solve (which is not completely explicit), solved it, and asked for endorsement of the IETF. I'd like to think we'd reserve that tool for things that we know fill a well-known gap. Conversely, I'd like to see what this gets used for and how well it works, so having a section on "how we're going to tell if this is getting good deployment" (which I think should be in any Experimental document) seems like a good thing.

What's the advantage at this point of declaring this an IETF Proposed Standard as against letting this run as an experiment for a while? I might understand that Barry thought this was important enough that it warranted IETF attention rather than simply ISE attention, but I'm still not clear on PS vs. Exp.

[Ballot comment]
2.2: See my followup note to Stephen's DISCUSS, but paragraphs 2 and 3 need to be rewritten.

2.3:

  As with all other major types, the 5-bit value 24 signifies a single-
  byte extension: it is followed by an additional byte to represent the
  simple value (to minimize confusion, only the values 32 to 255 are
  used).

I see no reason to limit the simple value to 32..255 if the additional information is 24. You don't limit that in any other types. I see no reason I should not be able to represent 'True' as either 0b111_10101 or as 0b111_11000 0b00010101. There is no such restriction on integer types, you're making something invalid that doesn't have to be (potentially making implementations less interoperable, because some will reject things while others will accept them), and restricting it seems to go against the comment in section 1.1, sub 1, second bullet. Please explain. (Not that if you change this, you also need to update section 3.2 and 3.9.)

It's also not clear to me why 'False' is not 0 and 'True' is not 1; it seems like it would be easier to implement on many platforms.

2.4:

  Applications may use specific tags defined in the following list and/
  or defined by standard action or in the registry.

I think you should strike "by standard action or" and rewrite this to:

  Applications may use specific tags defined in the Tags Registry
  (section 7.2), which initially includes the tags in the following
  list.

2.4.1: Why is the numeric time value not NTP format, with fixed-point fractional seconds? Doing so would make more sense given section 1.1, sub 1.

3.4: I don't understand why "Inadmissible type on the value following a tag" gets treated differently than other semantic errors. Other semantic errors basically make the behavior decoder-defined. But this one say that a certain kind of decoder "is expected to check the type of the enclosed data item." The same could be said for a decoder that decodes a UTF-8 string into a native string representation. Either put an onus on semantic validity or don't, for all of them.

4: "This section gives non-normative advice". Is there any other kind?

[Ballot discuss]
I basically have no objection to the publication of this document
although I am very sympathetic to the view that this work did not get
detailed or wide review in the IETF.

However, I am pretty sure that you have a number of references listed as
Informative when they should be Normative.  Just a random example,
RFC 3339 is cited in Section 2.4.1 as describing the date/time format
for tag=0. That would appear to make RFC 3339 a normative reference.

I think you will find a number of similar examples.

Even [I-D.ietf-lwig-terminology] seems to be used in a normative way
in section 1.1 in that I cannot understand objective 2 without reading
the definition of "constrained node" in that document.

[Ballot comment]
Here are a few points for consideration...

---

The Abstract says

  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.

How can you say that CBOR is different from other mechanisms that may
be created in the future? That seems like gratuitous marketing hype!

---

Section 1 para 2

  The serialization is for an
  extended version of the JSON data model [RFC4627].

I couldn't establish any context or this statement. What does "The
serialization" refer to? I think you are using a term that has a
technical definition common in this sphere, but not exlpained to the
reader.                             

---

"Text string" or "Stings of Unicode characters"?

Section 2.1 defines Major type 3 as "string of Unicode characters that
is encoded as UTF-8", but Section 2.2 and later sections talk about
"text strings".  Consistent language would help.

---

Section 2.2

  Text strings with indefinite lengths act the same as byte strings
  with indefinite lengths, except that all enclosed items (chunks) MUST
  be text strings.  Note that this implies that the bytes of a single
  UTF-8 character cannot be spread between items: a new item can only
  be started at a character boundary.

I don't think you need "MUST be" where "are" would do.
Compare with your definition of "Major type 3" in Section 2.1

---

Section 2.4

  Decoders do not need to understand tags, and thus tags are probably
  of little value in applications where the implementation creating a
  particular CBOR data item and the implementation decoding that stream
  know the semantic meaning of each item in the data flow.

I don't like statements of "probability" like this.  Is there any way
you can clean up the words?

---

Section 2.4

  Applications may use specific tags defined in the following list and/
  or defined by standard action or in the registry.

What does this text actually mean?
Would it be better to say...

  IANA maintains a registry of tag values as described in Section 7.2.
  Table 3 provides a list of initial values.

---

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.

[Ballot comment]
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.

[Ballot discuss]

- Surely 2.2 needs to say how to embed a "break" value into a byte
string (etc.) value - yet you don't - what is the indefinite length
encoding of a very long byte string of "break" values? Or am I
misreading something?

[Ballot comment]

- 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;-)

IESG/Authors/WG Chairs:

IANA has reviewed draft-bormann-cbor-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about the IANA actions requested in this document.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, a new registry will be created called the "CBOR Simple Values" registry.

IANA Question -> should this registry and the CBOR Tags registry be stand-alone registries or grouped together in a master repository for current and future CBOR registries?

Maintenance of the registry is done using the following requirements as defined in RFC 5226

0-19 - allocated through standards action
24-31 - reserved
32-255 - allocated through specification required

There are initial values in the registry, as follows:

Value      Semantics              Reference
----------- ---------------------- ----------------
0-19        unallocated           
20          False                  [ RFC-to-be ]
21          True                  [ RFC-to-be ]
22          Null                  [ RFC-to-be ]
23          Undefined value        [ RFC-to-be ]
24-31      Reserved
32-255      unallocated         

QUESTIONS:
1) the text "starting with the number 16" included in section 7.1
is very confusing:

"
New entries in the range 0 to 19 will be allocated by Standards
  Action, starting with the number 16.  New entries in the range 32 to
  255 will be allocated by Specification Required."

Can authors please clarify the "starting number 16" within the range
0 to 19?

2) Should the term "Unassigned" be used as defined in RFC5226,
rather then "unallocated"?


Second, a new registry will be created called the "CBOR Tags" registry.  The registration rules for the new registry are as follows:

0-23 - Standards Action
24-255 - Specification Required
256-18446744073709551615 - First Come First Served

There are initial registrations in this new registry and all (except for unallocated) will have a reference of [ RFC-to-be ].

+-----------+-------------------+-----------------------------------+
| tag      | data item        | semantics                        |
+-----------+-------------------+-----------------------------------+
| 0        | UTF-8 string      | Standard date/time string; see    |
|          |                  | Section 2.4.1                    |
|          |                  |                                  |
| 1        | multiple          | Epoch-based date/time; see        |
|          |                  | Section 2.4.1                    |
|          |                  |                                  |
| 2        | byte string      | Positive bignum; see Section      |
|          |                  | 2.4.2                            |
|          |                  |                                  |
| 3        | byte string      | Negative bignum; see Section      |
|          |                  | 2.4.2                            |
|          |                  |                                  |
| 4        | array            | Decimal fraction; see Section    |
|          |                  | 2.4.3                            |
|          |                  |                                  |
| 5        | array            | Bigfloat; see Section 2.4.3      |
|          |                  |                                  |
| 6..20    | (unallocated)    | (unallocated)                    |
|          |                  |                                  |
| 21        | multiple          | Expected conversion to base64url  |
|          |                  | encoding; see Section 2.4.4.2    |
|          |                  |                                  |
| 22        | multiple          | Expected conversion to base64    |
|          |                  | encoding; see Section 2.4.4.2    |
|          |                  |                                  |
| 23        | multiple          | Expected conversion to base16    |
|          |                  | encoding; see Section 2.4.4.2    |
|          |                  |                                  |
| 24        | byte string      | Encoded CBOR data item; see      |
|          |                  | Section 2.4.4.1                  |
|          |                  |                                  |
| 25..31    | (unallocated)    | (unallocated)                    |
|          |                  |                                  |
| 32        | UTF-8 string      | URI; see Section 2.4.4.3          |
|          |                  |                                  |
| 33        | UTF-8 string      | Base64url; see Section 2.4.4.3    |
|          |                  |                                  |
| 34        | UTF-8 string      | Base64; see Section 2.4.4.3      |
|          |                  |                                  |
| 35        | UTF-8 string      | Regular expression; see Section  |
|          |                  | 2.4.4.3                          |
|          |                  |                                  |
| 36        | UTF-8 string      | MIME message; see Section 2.4.4.3 |
|          |                  |                                  |
| 37+      | (unallocated)    | (unallocated)                    |
+-----------+-------------------+-----------------------------------+

QUESTION: Should the term "Unassigned" be used as defined in RFC5226,
rather then "unallocated"?


Third, this document requests adding a media type to the applications mediat type registry located at:

http://www.iana.org/assignments/media-types/application/index.html

The media type to be added is:

cbor

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

---
Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Concise Binary Object Representation (CBOR)) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Concise Binary Object Representation (CBOR)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-bormann-cbor/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-bormann-cbor/ballot/


No IPR declarations have been submitted directly on this I-D.

I will finish my AD review during last call -- I think the document is in good shape, and my comments are not likely to be major.