Re: [Cbor] Announcement: draft-mcnally-deterministic-cbor-03

[Wolf McNally <[e-mail]>]

Joe,

Awesome! We’re excited that you’re doing an independent implementation and I’d be happy to work with you on test vectors.

Your points on the I-D are well-taken. So I’m releasing a new revision today that is much more explicit about both rules for encoders and decoders.

Regarding non-float simple values (major type 7): my own implementations do reject any values other than `true`, `false`, and `null`, because all the other code points are either “unassigned”, “reserved”, redundant/of questionable value (0xf7 undefined), or only used with indefinite-length structures which are disallowed (0xff break). So I went ahead and added this as a requirement. If anyone here has practical use-cases for why other simple values should be allowed in the dCBOR profile, please do let me know.

~ Wolf

> On Aug 6, 2023, at 7:13 PM, Joe Hildebrand <[e-mail]> wrote:
> 
> I've been implementing this today.  Here are some notes:
> 
> - It would be nice if the encode/decode requirements were split out in a few places and made more explicit in a few places.  If each section had a "for dCBOR encoders" and "for dCBOR decoders" sub-section, it would help the implementor make sure they hadn't missed anything.
> - In particular, s2.1 (5) should be spelled out everywhere it applies
> - +/- Infinity is a special case of s2.3 (2).  The wording in s2.3.2 (4) sent me down the wrong road to special-case these, but it's worth calling them out as special cases to test.
> - s2.3.2 says "encoders must" then talks about decoding on a couple of the points
> - I was expecting something about simple values other than true/false/undefined/null being prohibited
> 
> Overall, the doc made sense to me.
> 
> cbor2 will support dcbor in its next release, once I figure out how much granularity I want in configuring it on or off.  It won't be the default encoding, and the decoding errors will not be on by default.
> 
> I would be happy to collaborate on a set of test vectors if you're interested.
> 
> — 
> Joe Hildebrand
> 
>> On Aug 6, 2023, at 4:20 AM, Wolf McNally <[e-mail]> wrote:
>> 
>> As promised, this revision of our dCBOR I-D includes discussed corrections. It also reformats all profile requirements in a way that is hopefully easier to understand and discuss.
>> 
>> ~ Wolf
>> 
>> A new version of I-D, draft-mcnally-deterministic-cbor-03.txt
>> has been successfully submitted by Wolf McNally and posted to the
>> IETF repository.
>> 
>> Name: draft-mcnally-deterministic-cbor
>> Revision: 03
>> Title: Gordian dCBOR: A Deterministic CBOR Application Profile
>> Document date: 2023-08-06
>> Group: Individual Submission
>> Pages: 8
>> URL:            https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-03.txt
>> Status:         https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/
>> Html:           https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-03.html
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcnally-deterministic-cbor
>> Diff:           https://author-tools.ietf.org/iddiff?url2=draft-mcnally-deterministic-cbor-03
>> 
>> Abstract:
>> CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its
>> Section 4.2.  The present document provides the application profile
>> "dCBOR" that can be used to help achieve interoperable deterministic
>> encoding.
>> 
>> Discussion Venues
>> 
>> This note is to be removed before publishing as an RFC.
>> 
>> Source for this draft and an issue tracker can be found at
>> https://github.com/BlockchainCommons/WIPs-IETF-draft-deterministic-
>> cbor.
>> 
>> 
>> _______________________________________________
>> CBOR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
>