Subject: [Cbor] BCP document for CBOR

From: Jim Schaad <[email-masked]>
Date: Wed, 28 Aug 2019 12:29:21 -0700

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

---

From: Ira McDonald <[email-masked]>
Date: Wed, 28 Aug 2019 15:57:20 -0400

Hi,

+1 to BCP for CBOR idea.

I'm too busy to write or edit, but would try to review BCP text.

I've been much involved in a couple of other standards bodies in editing
BCP
documents.  I think they're equally as important as the underlying
standards.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Aug 28, 2019 at 3:29 PM Jim Schaad <[email-masked]> wrote:

> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Aug 2019 15:56:13 -0400

> covering today might be better placed in a BCP document rather than in the

I think that we actually talked about this at one time before.
This was around the question about whether we optimized for limited ability
encoders (by not always using the most efficient encoding), or limited
ability decoders (by limiting the number of different encodings used).

It was some kind of Design Considerations for Protocols using CBOR.
I thought it was a good idea.  It would provide a number of different ways to
do things (a palette), and then suggest that other uses say which one
"colour" they are using.

    > writing/editing the document?

I think that it's a good idea.
I would review and contribute, but I couldn't lead.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-