Re: [Cbor] BCP document for CBOR

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: blueroofmusic@gmail.com
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Aug 28, 2019 at 3:29 PM Jim Schaad <ietf@augustcellars.com> wrote:

> 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 mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>