Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-04

Carsten Bormann <cabo@tzi.org> Thu, 08 August 2013 19:58 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360C611E8225; Thu, 8 Aug 2013 12:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gCERiLa0Jry; Thu, 8 Aug 2013 12:58:49 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CB6C411E822F; Thu, 8 Aug 2013 12:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r78JwJrM009599; Thu, 8 Aug 2013 21:58:19 +0200 (CEST)
Received: from [192.168.217.105] (p5489221B.dip0.t-ipconnect.de [84.137.34.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 86A8C152; Thu, 8 Aug 2013 21:58:18 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CABkgnnXtCBHnOpY_=t7yWD-+7rSFHKdUi0VGUSVJqXq+xV-G2g@mail.gmail.com>
Date: Thu, 08 Aug 2013 21:58:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D16097AF-5DFB-4F6A-A6E7-2582C1CF25CD@tzi.org>
References: <CABkgnnXtCBHnOpY_=t7yWD-+7rSFHKdUi0VGUSVJqXq+xV-G2g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: draft-bormann-cbor-04.all@tools.ietf.org, gen-art@ietf.org, "ietf@ietf.org Mailing List" <ietf@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2013 19:58:55 -0000

On Jul 30, 2013, at 09:05, Martin Thomson <martin.thomson@gmail.com> wrote:

> What would cause this to be tragic, is if publication of this were
> used to prevent other work in this area from subsequently being
> published.

Indeed.

As Paul and I have repeatedly said, CBOR is not trying to be the final, definitive, binary object representation for all purposes.  It was written to some specific objectives, clearly stated in the document.  It is being proposed for standards-track because specific ongoing work that works well with these objectives will benefit greatly from being able to reference a common specification.  If the objectives for other work are different, that work may benefit from using a different format, existing or newly designed.

We had some offline discussion of what can be done to make this more apparent from the document, and decided to start at the most visible part, the abstract.

In -04, the abstract says:

   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.

Now this seemed fairly clear to the authors, but without context it might be read as trying to be the final, end-all format because it only talks about earlier formats.
We propose to fix this (at the danger of being slightly tautological) by making it clear other formats will be created in the future:

   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.

Serialization/encoding of data structures for transmission continues to be an exciting (if sometimes arcane) subject of computer science and its long history will not end with CBOR.

(CC to ietf@ietf.org because some discussion there appears to be related.)

Grüße, Carsten