Re: [Cbor] New Version Notification for draft-macnally, for

Joe,

My main issue with discussing what we’re *not* supporting in the I-D is that doing so (especially exhaustively) would require a fair amount of space and might introduce confusion. For instance, we don’t discuss why we’re not supporting `0xff break`; it is there to support CBOR indefinite-length structures, which are ruled out.

Most of RFC 8949 uses `undefined` interchangeably with `null`, which makes it ambiguous. See for example, §3.4 where it says: "As a matter of convention, many tags do not accept null or undefined values as tag content; instead, the expectation is that a null or undefined value can be used in place of the entire tag..."

Whereas §5.7 proposes a purpose for `undefined` that seems to be in conflict with the goal of determinism: "undefined might be used by an encoder as a substitute for a data item with an encoding problem, in order to allow the rest of the enclosing data items to be encoded without harm."

With regard to bignums, they aren’t mentioned at all in the normative §4.2.1, and they’re only mentioned in passing in the non-normative §4.2.2: "If a protocol includes a field that can express integers with an absolute value of 2^64 or larger using tag numbers 2 or 3 (Section 3.4.3), the protocol's deterministic encoding needs to specify whether smaller integers are also expressed using these tags or using major types 0 and 1. Preferred serialization uses the latter choice, which is therefore recommended.” While I agree with the recommendation (issues around lower-nint values aside), we have moved our I-D away from recommendations and toward purely normative requirements. Given that bignums are out of scope for the current profile, perhaps you could clarify what sort of statement you feel would be helpful regarding them?

I would expect that supporting dCBOR as a feature switch in an otherwise generic CBOR encoder would entail some complexities, and I’m looking forward to hearing your analysis. My experience in implementing single-purpose dCBOR codecs is that overall it simplifies them, which will work well in constrained environments.

~ Wolf

> On Aug 8, 2023, at 8:44 AM, Joe Hildebrand <hildjj@cursive.net> wrote:
> 
> Section 2.5 needs something about `undefined` one way or the other.
> 
> From an implementors perspective, I still think this needs something about bigints, Carsten's comment about "forking" notwithstanding.
> 
> Otherwise, this handles all of my issues with this document as it stands.
> 
> If you'd like to see the complexity this adds to my code, here is the pending PR: https://github.com/hildjj/cbor2/pull/19
> It ended up being a lot more work than I expected.
> 
> Note: I have another message coming on one of the other threads that will compare this vs. Carsten's approach.  I should not be counted as in one camp or the other until that analysis is complete.
> 
> — 
> Joe Hildebrand
> 
>> On Aug 8, 2023, at 4:12 AM, Wolf McNally <wolf@wolfmcnally.com> wrote:
>> 
>> New in this version:
>> 
>> Clarified that all requirements are narrowing.
>> 
>> —
>> 
>> A new version of I-D, draft-mcnally-deterministic-cbor-05.txt
>> has been successfully submitted by Wolf McNally and posted to the
>> IETF repository.
>> 
>> Name: draft-mcnally-deterministic-cbor
>> Revision: 05
>> Title: Gordian dCBOR: A Deterministic CBOR Application Profile
>> Document date: 2023-08-08
>> Group: Individual Submission
>> Pages: 10
>> URL:            https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-05.txt
>> Status:         https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/
>> Html:           https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-05.html
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcnally-deterministic-cbor
>> Diff:           https://author-tools.ietf.org/iddiff?url2=draft-mcnally-deterministic-cbor-05
>> 
>> 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.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
> 