[Cbor] Rechartering Process

Jim Schaad <ietf@augustcellars.com> Wed, 22 May 2019 18:29 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE88C1200FF for <cbor@ietfa.amsl.com>; Wed, 22 May 2019 11:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HJl_Bngoy8A for <cbor@ietfa.amsl.com>; Wed, 22 May 2019 11:29:31 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE271200D8 for <cbor@ietf.org>; Wed, 22 May 2019 11:29:31 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 22 May 2019 11:29:25 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: cbor@ietf.org
Date: Wed, 22 May 2019 11:29:21 -0700
Message-ID: <008d01d510cc$47b932f0$d72b98d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdUQy69DHR/Seo6ISD+rHc0+KoR0sw==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/be_gq4SFZoRnWyoURCO2dqQ84zw>
Subject: [Cbor] Rechartering Process
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2019 18:29:34 -0000

During the virtual meeting today, one of the items on the agenda was to bash
the proposed charter update.  Below is the output of that process.  The
intention is to review the charter again at the next meeting in two weeks
and if there are no issues then to send it to the IESG for approval.  You
can send messages to the mailing list, setup a pull request at
https://github.com/cbor-wg/charter/ or come onto the next call if you want
to suggest changes.

Jim

Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript
Object Notation (JSON, RFC 7159) data interchange format to include binary
data and an extensibility model, using a binary representation format that
is easy to parse correctly. It has been picked up by a number of IETF
efforts (e.g., CORE, ANIMA GRASP) as a message format.

The CBOR working group will update RFC 7049 to fix verified errata. Security
issues and clarifications may be addressed, but changes to the document will
ensure backward compatibility for popular deployed codebases. The resulting
document will be targeted at becoming a Full Internet Standard. After that,
the CBOR working group will monitor issues found with the CBOR specification
and, if needed, will produce an updated document.

Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of
valid messages in a text representation, it is useful for protocol
specifications to use a description format for the data in CBOR-encoded
messages. The Concise Data Definition Language (CDDL) is such a description
technique that has already been used in CORE, ANIMA, CDNI, and efforts
outside the IETF.

CDDL has been published as RFC XXXX. While this specification has been
completed, several new features were raised during the update process that
were not included, in order not to delay publication, and to allow
publication in the Standards Track. One example of such a feature is the
ability to combine multiple CDDL files together using a mechanism other that
manually concatenating them together for processing. The working group will
collect these features as well as other features that are raised by users of
CDDL, evaluate their utility and add to a second edition of the
specification if warranted.

The working group will define the approach to further evolving CDDL as a
sequence of editions, which might also add further extension points,
probably as part of the introduction of the next edition of the CDDL base
specification. The body of existing specifications that make use of CDDL is
considered precious, and the WG will set out not to damage their value.

The working group will evaluate the necessity of providing advice and
guidance for developers using CBOR and CDDL. It is currently expected that
this would be done using a Wiki of some type. This work would not be
expected to be published by the IETF.

There are a number of additional CBOR tagged types that are either currently
adopted by the working group, by other working groups, or as individual
submissions. Additionally, there are expected to be other such documents
that will come to the attention of the working group. In some cases, the
working group expects to adopt and publish these proposals.

The working group will evaluate and place proposals in one of the following
categories using a dispatch like process:

 *   General purpose tagged types that are expected to have broad usage: The
working group will normally adopt and publish such proposals. Examples of
proposals in this category are CBOR Sequence (draft-bormann-cbor-sequence)
and Error Indications (draft-richter-cbor-error-tag).

 *   Internet wide specific purpose tagged types: The working group may
decide to adopt these proposals, but typically it would just provide input
and recommend that they be published either as an Independent Submission or
by a different working group.

 *   Narrow purpose tagged types: The working group may provide evaluation
of such proposals, but typically would not support Working Group adoption,
and could recommend publication in a different forum. An example of this
might be portions of draft-bormann-cbor-tags-oid dealing with some of the
more esoteric types such as regular expressions