Session Date/Time: 02 Apr 2025 14:00

CBOR

Summary

The CBOR working group held an interim call to discuss three drafts: CDE, CBOR-PACK, and LITERAL. The primary discussion focused on the Common Deterministic Encoding (CDE) draft, which recently completed Working Group Last Call. Key points included editorial changes, the status of GitHub issues, and a significant debate about the document's scope and form—specifically, whether it should be a Best Current Practice (BCP) or a Proposed Standard update to RFC 8949. Towards the end of the call, a brief discussion began on the CBOR-PACK draft concerning its use of tags for references and potential size implications. The LITERAL draft was not reached due to time constraints.

Key Discussion Points

Common Deterministic Encoding (CDE) Draft:
- WG Last Call (WG-LC) Review: The CDE draft (v08) completed its WG-LC. Most comments focused on appendices, which have been reordered and updated. New appendices address an information/data model distinction (Appendix A), provide additional text (Appendix B, from Lawrence), and include encoding examples (Appendix D, from Corivo).
- Terminology Updates: Version -10 was submitted to remove instances of the word "profile." The abstract was also clarified to emphasize CDE as a single, shared common deterministic encoding and to introduce "basic serialization" as a less restrictive constraint than full deterministic encoding, aimed at reducing variability.
- GitHub Issues Status:
  - Issues #29 (word "profile") and #22 (ALDR text) are considered addressed by the editor in versions -10 and -09, respectively.
  - Issue #26 (concrete ADR recommendations) proposes removing certain informative text; the editor views this text as a useful example of an application stack and is reluctant to remove it.
  - Issue #25 (threat of ecosystem fogging) questions the document's motivational premise; the editor asserts the document is necessary because of this threat, citing private SDO discussions and ongoing mailing list activity, and therefore will not remove this information.
  - Lawrence (the filer of these issues) disagreed with the editor's "won't fix" assessment for #25, stating a lack of evidence for the threat. He also suggested #26 might benefit from additions, not removals, and preferred a shorter ALDR text.
- Document Scope and Status Debate:
  - A significant discussion arose regarding the document's nature. Ori (AD), Rowan, and Joe suggested that the document's aim to provide clarity around deterministic encoding would be better served by a narrow Proposed Standard update to RFC 8949, rather than a BCP.
  - Concerns were raised about the potential for confusion stemming from similar terminology ("core deterministic encoding" in RFC 8949 vs. "common deterministic encoding" in the draft) and the clarity of implementation requirements when embedded in an extensive informative BCP.
  - Proponents of an 8949 update argued that if the intent is to define new categories or refine existing ones (like "preferred," "basic," and "deterministic" serializations), this should be done normatively in a standard.
  - The editor argued that CDE is additive to RFC 8949, not an update, as it picks specific constraints left open by the core requirements in RFC 8949, which are referenced by other documents. He compared it to TCP defining headers on top of IP, rather than updating IP itself.
  - The editor also highlighted that RFC 8949 already defines "preferred" serialization and that "basic" is a useful new term for an existing practice.
  - There was also a concern expressed that the editor was not adequately engaging with proposed changes, focusing instead on a "preconceived destination."
- Chair's Intervention: The chair acknowledged concerns about reaching consensus and asked the editor to be more receptive to proposals from the working group, emphasizing that decisions should reflect rough consensus rather than just the editor's preference.
CBOR-PACK Draft:
- Tag Usage and Size Efficiency: The discussion began on CBOR-PACK, specifically regarding the justification for using numerous tags for references and the resulting size efficiency.
- Using a Zipf distribution model, the editor presented calculations showing average bytes per reference. Reducing the number of tags used increased the average bits per reference, with radical reduction costing about 8.4 bits per reference.
- Appropriateness of Tag Use: Michael questioned the fundamental premise, arguing that CBOR tags are for tagging data structures (i.e., data types), not for communicating data (like numerical offsets into a compression table). He viewed this as an "inappropriate use of tag space," advocating for a clear architectural separation between tags and data.
- The editor countered by citing historical precedent with tags 2 and 3 in CBOR (for unsigned/negative integers) as examples of tags reflecting content, suggesting similar usage has not had negative consequences over 12 years. Joe requested examples of cardinality greater than two for this type of tag usage.

Decisions and Action Items

CDE Discussion: The discussion regarding the CDE document's scope, format (BCP vs. Proposed Standard update to RFC 8949), and resolution of open GitHub issues will continue on the CBOR mailing list.
CDE GitHub Issues: The chair will announce a timebox on the mailing list for resolving the remaining GitHub issues related to the CDE document.
CBOR-PACK Discussion: The discussion on the CBOR-PACK draft, specifically regarding tag usage and efficiency, is postponed to the next interim meeting.

Next Steps

CDE: Participants are encouraged to engage on the mailing list to resolve the document's path and address outstanding technical and editorial concerns, particularly regarding terminology and the document's status (BCP or 8949 update).
CBOR-PACK: The working group will continue its discussion on the CBOR-PACK draft, including the fundamental architectural question of tag usage, at the next interim meeting.
LITERAL: This draft remains on the agenda for future discussion.
The next interim meeting is scheduled for two weeks from now.