[Cbor] BCP document for CBOR

Jim Schaad <ietf@augustcellars.com> Wed, 28 August 2019 19: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 BBAED120074 for <cbor@ietfa.amsl.com>; Wed, 28 Aug 2019 12:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 7JdCDknN15La for <cbor@ietfa.amsl.com>; Wed, 28 Aug 2019 12:29:30 -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 92439120041 for <cbor@ietf.org>; Wed, 28 Aug 2019 12:29:29 -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, 28 Aug 2019 12:29:23 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: cbor@ietf.org
Date: Wed, 28 Aug 2019 12:29:21 -0700
Message-ID: <01d401d55dd6$e5ee1e70$b1ca5b50$@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: AdVd1OCIe6Nv/zJjQoGIwcM2gy/V1g==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/eJAIimG84b5bLS5Y_NzuPa2XB6A>
Subject: [Cbor] BCP document for CBOR
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, 28 Aug 2019 19:29:32 -0000

During the interim call today, as Carsten was going through the set of open
issues, it dawned on me that a good number of the issues that he was
covering today might be better placed in a BCP document rather than in the
CBOR standard.  

Some of the issues that seem to me to be better suited for a BCP would be

1.  Some parts of Issue #63 about the choices an application can make for
dealing with duplicate keys.  The security considerations would need to stay
in the main document, this would just be a discussion of the trade-offs
between the three choices presented in the issue along with a
recommendation.

2.  Possibly Issue #67 which deals with how protocols should deal with
unexpected tags and simple values.  The core document would probably just
say returned in some form, but more information about this might go into a
BCP

3.  Issue #68 which discusses the trade offs of using different types of
keys for maps.  This text could just move from the core document into the
BCP and thus it would be easier to change later as we get more experience.

4.  Issue #77 which talks about the JSON to CBOR conversion of numbers into
either integers or floats.  This could also discuss the differences between
"pure" JSON and I-JSON where 53 bits of precision is much more explicit

5.  Potentially some of the issues around strict might move into this
document where the advice could potentially change in the future.

6.  Some of the text around #92 could end up here.  The recommendation that
it not be done should be in the Expert Review considerations, but
potentially a discussion of why it may want to be done could go into the BCP
document.  I have a feeling that this advice might change at some point but
I don't know that.

7.  Issue #94 which is dealing with NaN where a generic recommendation would
be in the main document, but suggestions on how applications might want to
use the different types of NaNs might show up.

What do other people in the WG think of this proposal?  

If the proposal were to be adopted, are there people who are interested in
writing/editing the document?

Jim