Skip to main content

Concise Binary Object Representation (CBOR) Sequences
draft-ietf-cbor-sequence-02

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, cbor@ietf.org, ietf@augustcellars.com, Jim Schaad <ietf@augustcellars.com>, draft-ietf-cbor-sequence@ietf.org, alexey.melnikov@isode.com, cbor-chairs@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Concise Binary Object Representation (CBOR) Sequences' to Proposed Standard (draft-ietf-cbor-sequence-02.txt)

The IESG has approved the following document:
- 'Concise Binary Object Representation (CBOR) Sequences'
  (draft-ietf-cbor-sequence-02.txt) as Proposed Standard

This document is the product of the Concise Binary Object Representation
Maintenance and Extensions Working Group.

The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-cbor-sequence/


Ballot Text

Technical Summary

  This document describes how a sequence of CBOR objects can
  be transmitted in an environment that uses media types.  A
  CBOR sequence is not a legal CBOR object.

  The document also defines a structured syntax for allowing
  generic parsing of CBOR sequences using "+cbor-seq".

Working Group Summary

  There was some discussion about the need to define this
  data structure as it can be done by the use of an indefinite
  array.  The consensus of the working group was that this
  would be a useful item to have.

Document Quality

  The document is simple and understandable.  I have seen code
  for one implementation of CBOR Sequences and it appeared to
  match the document from a brief reading of the code.
  All of the registrations have been sent to the appropriate
  review mailing list and there has been no returned comments.

Personnel

  The Document Shepherd is Jim Schaad.  The Responsible Area
  Director is Alexey Melnikov.

RFC Editor Note