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

[Anders Rundgren <[e-mail]>]

Short return since I was mentioned :)

I'm working with Open Banking and similar high-profile applications.

In these contexts, client developers get ZERO possibility of using their favorite encoding format.
However, Open Banking only represents a fraction of a gazillion, in practice, rather similar applications.
If CBOR is [ever] going to be a viable solution in this space, you need a pretty good and universal profile, as well as compatible tools.

Such tools will follow the current de-facto standard.  That is, using Object Oriented concepts and Encapsulation.

This is the rationale for *my* work.

We can WGLC cbor-cde anytime, personally, I stick to RFC8949.

Thanks,
Anders

On 2025-03-31 14:29, Carsten Bormann wrote:
> Hi,
> 
> preparing for Wednesday’s interim, I looked at the ~ 32 messages on this mailing list that mentioned the draft since WGLC, preparing for submitting -09.
> 
> I couldn’t really do much with the messages that said they wanted some other documents instead, such as a discussion of CBOR interoperability considerations, which the CDE document is not about.
> 
> Anders agreed that this document should move forward, but had these points [1]:
> 
> [1]: <https://mailarchive.ietf.org/arch/msg/cbor/2tgHTlheVhaOMpecfeZ-ORFm1hE>
> 
>> UNCLEAR RATIONALE:
> 
> Both abstract and first paragraph of the introduction provide rationale for CDE (and the new term “basic serialization”).
> 
>> UNFINISHED RESEARCH:
> 
> Anders has a question about dCBOR, which is irrelevant to the present document.
> (There also is no research necessary to answer this question.)
> 
>> COMPATIBILITY ISSUES:
> 
> Anders believes there is some interoperability danger from creating CBOR profiles.
> I actually agree, which is why CDE unifies the existing approaches to deterministic encoding in one common best current practice, which also could be called “profile" (but: there is only one).
> There also is an attempt to describe dCBOR as a competitor profile to CDE, which it isn’t.
> 
>> MIXING LEVELS:
>> The CDE draft spans everything from encoding numbers
> 
> (Which is indeed properly the subject of CDE)
> 
>> to how
>> you deal with objects having multiple representations (like some
>> CBOR date objects).
> 
> CDE points out that you might have to say something about this (deterministic representation down from the application level) in conjunction with CDE (deterministic encoding of CBOR data items).
> It doesn’t define a best current practice for *what* to say (too application specific), but does introduce terms that might help with *how* to say it.
> In any case, it points out that the fact that you might have to say something doesn’t invalidate CDE as the one common best current practice for deterministic encoding.
> This is necessary to understand when using this BCP.
> 
>> 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.
> 
> Indeed, we clearly have different styles.
> The “implementer’s manual” style Anders seems to like just doesn’t cut it when creating actual specifications.
> It is great for blog posts and Wiki pages, though (hint, hint).
> 
> 
> Laurence [2] points out that much of the CDE document is already specified in RFC 8949.
> Still, he thinks that CDE should be standards-track, not BCP as currently planned.
> I don’t think this would be entirely wrong, but BCP just is closer to what this document does: delineating an important set of related statements already in RFC 8949 and supplying a common term for them, including making a choice where one is left open by RFC 8949.
> 
> There are also a few things in [2] that aren’t quite right, but I won’t niggle with the text in the comment.
> I just would like to state my disagreement with his finding of CDE to be "an opportunity to refine the normative definitions of basic serialization, preferred serialization, and CDE” in the sense of restating RFC 8949 and making CDE update RFC 8949.
> Restatements are bad [restate], and, if at all, I’d go into the inverse direction to point out that many CBOR-based standards (e.g., COSE) miraculously already make use of CDE as is (as always, of the subset of CDE they need, which is small for COSE).
> But that would be informational, and it maybe fits better on a Wiki page.
> 
> [restate]: https://www.ietf.org/archive/id/draft-bormann-restatement-03.html
> 
> Laurence also would like to rename “basic serialization” into “CIE” (CBOR Interoperable Encoding), which would be highly misleading, as it would imply other choices provided by RFC 8949 aren’t interoperable, which they surely are.
> 
> [2]: <https://mailarchive.ietf.org/arch/msg/cbor/OW3t8mohL9QMxYugJ7nzV-NBd5A>
> 
> Michael [3] thinks we should publish "a set of canonical encoding templates”.  I’m not quite sure what that would be, but the point of CDE is that we only need one “Common Deterministic Encoding” and not a menu of templates to choose from.  In any case, he was quite affirmative of this document.
> 
> [3]: <https://mailarchive.ietf.org/arch/msg/cbor/6dwAUypkoJTkxg2xwhOERpORdug>
> 
> 
> We have a number of additional comments that essentially reflect a process of becoming aware of the application-level deterministic representation (ALDR) issue and how it is different from CDE (but can be addressed in a way that works well together with CDE).
> I think these comments are great support for not ignoring ALDR.
> 
> We got lots of great editorial input from Laurence that I tried to incorporate after aligning terminology.
> Some of this is already merged, and there is a PR [09] with some more that previews what I will submit as -09.
> There is now some minimal consideration of how the existence of encoding variants influences interoperability with partial implementations in Appendix A [09-iop].
> Please check [09-html] and [09-diff].
> This PR also includes a slightly updated form of three useful tables of examples in Anders’ “base” document, now forming Appendix D.
> 
> [09]: https://github.com/cbor-wg/draft-ietf-cbor-cde/pull/28
> [09-iop]: https://cbor-wg.github.io/draft-ietf-cbor-cde/models-edit/draft-ietf-cbor-cde.html#appendix-A-5
> [09-html]: https://cbor-wg.github.io/draft-ietf-cbor-cde/models-edit/draft-ietf-cbor-cde.html
> [09-diff]: https://author-tools.ietf.org/api/iddiff?url_1=https://cbor-wg.github.io/draft-ietf-cbor-cde/draft-ietf-cbor-cde.txt&url_2=https://cbor-wg.github.io/draft-ietf-cbor-cde/models-edit/draft-ietf-cbor-cde.txt
> 
> I’ll do another editorial round before submitting, so comments are welcome (of course, even after submitting -09 as well).
> 
>> On 2025-03-06, at 23:34, Christian Amsüss <[e-mail]> wrote:
>>
>> The call will run until Marh 26th […]
> 
> I’m not a chair of this group, so I’ll leave it to the chairs to consider whether the other feedback we got (e.g., from Wolf McNally [wm]) was affirmative.
> 
> [wm]: <https://mailarchive.ietf.org/arch/msg/cbor/2tgHTlheVhaOMpecfeZ-ORFm1hE>
> 
>> PS. We don't have a shepherd assigned for this document, any volunteers?
> 
> Any takers?  We could discuss this on Wednesday as well.
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]