[Cbor] Re: 🔔 WGLC on draft-ietf-cbor-cde-08

[Anders Rundgren <[e-mail]>]

On 2025-03-06 23:34, Christian Amsüss wrote:
> Hello CBOR group,
> 
> as discussed in the last interim[1], it's time to run a Working Group
> Last Call on CBOR Common Deterministic Encoding (CDE) [2].

+1

Although I am not in favor of the CDE draft, *I do support* its
publication as an RFC because the only other credible alternative I can
come up with, is abandoning this work-item in its entirety.

Just "for the record", here is a condensed list of why I don't
consider this work particularity useful:

UNCLEAR RATIONALE:
There is nothing to find regarding the need and use of deterministic
encoding.  That some of the list participants use deterministic
encoding to avoid COSE-style "bstr" wrapping of CBOR to be hashed,
apparently does not fit the CBOR WG agenda.  In spite of being
informed, nobody representing COSE have bothered looking into this
issue, although it could have pretty far-reaching consequences.

UNFINISHED RESEARCH:
That we after two years of work, do not know why the target
applications for dCBOR (a CDE profile), need non-standard
handling of numbers seems a bit odd to me.

COMPATIBILITY ISSUES:
CDE is some kind of "framework" for people creating RFC 8949
profiles, that as far as I can tell, typically are mutually
incompatible, at least if using the more common definition of
compatibility which is at system-level: talking to a system
using the dCBOR flavor of CBOR from another system using another
CBOR "dialect", not abiding to "numeric reduction", doesn't
seem like a very useful task.  Making map-sorting potentially
optional is another step in the wrong direction.

MIXING LEVELS:
The CDE draft spans everything from encoding numbers to how
you deal with objects having multiple representations (like some
CBOR date objects).  It is hard to see any (valid) connection
between these topics, including the fact that they should have
pretty different audiences.

VERBOSITY:
CDE is (obviously) a follow-up document to RFC 8949. As such it
inherited a style of writing which I as a "normal engineer" have
issues with.  Both documents feels more like "PhD dissertations",
than specifications targeting implementers.  Personally, I used
https://cbor.me as the "truth", when navigating RFC 8949.


I could certainly go on, but this is the gist of it.


++UPSIDE++
A good thing (really?!) about the CDE activity, is that it forced
me to come up with an alternative take on the matter:
a concrete, cross-platform specification, directed towards tool-
builders supporting the developer segment designing applications
for browsers, mobile phones, Web severs, etc.  For this lot, CBOR
is just a set of data types, there is not even a "CBOR data model"!

Deterministic encoding is mandatory; no need to confuse the intended
user base with (technically) redundant questions like:

    Do I need deterministic encoding?

These users are not supposed to dig into RFC 8949 either.

Based on the limited response, I do the assumption that the IETF
have no interests in taking CBOR to places where JSON currently
reigns, not to mention, challenging COSE.

Regards,
Anders Rundgren




> 
> This document has seen controversial discussion. I hope that most
> concerns have been addressed, and ask both those who have long since
> been happy with the document and those whose concerns were addressed to
> state that on the list. Likewise, for those who do not agree with the
> document, this thread is a good spot to state their concerns here in a
> concise way (referencing archived threads for details can help keep
> things short while preserving context).
> 
> As a special note, there is a text proposal with protocol from Laurence
> on design considerations around ALDRs on [3]; Carsten is taking that up
> into an appendix and will provide a PR link / updated document. This is
> a sufficiently isolated concern that we don't need to wait for an
> integrated document (to be available when submissions reopen). If
> guidance on ALDR is something where you think the current document is
> lacking, please have a look at [3] or the upcoming PR.
> 
> 
> The call will run until Marh 26th to accommodate for lack of
> availability during IETF122.
> 
> Best regards,
> Christian
> 
> PS. We don't have a shepherd assigned for this document, any volunteers?
> 
> [1]: https://datatracker.ietf.org/meeting/interim-2025-cbor-05/session/cbor
> [2]: https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/
> [3]: https://mailarchive.ietf.org/arch/msg/cbor/G6w0Rz0eW9GJNd1et8I899Ua9MQ/
> 
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]