[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
- [Cbor] BCP document for CBOR Jim Schaad
- Re: [Cbor] BCP document for CBOR Ira McDonald
- Re: [Cbor] BCP document for CBOR Michael Richardson