[Cbor] Re: Working Group Last Call on Serialization draft

[Vadim Goncharov <[e-mail]>]

Hi all,

Overall, I support publishing this document. What I especially like in it is
language: it is quite clear. I've continued to read from Appendix A, and there
is no ambiguities or something that reader will not understand (did not check
Appendix K and L, though).

My main concern remains requirement of Section 7, as some implementations may
have different concerns for this, and prohibiting forever may impede
future extensibility; Christian also have found that another reading of 8949
may suggest interpretation distinct from view expressed in draft.
And introducing tags for Section 10; for both, see below in quoted my previous
message on subject.

What I else can point out is that some information recently dicsussed in ML is
missing from draft, this is about Appendix J (and probably I) about cases when
byte-string wrapping is not used - that is, Bundle protocol example, C509 and
other discoveries / proposed solutions are not reflected in -08 version except
"tell()" method (described too succinct); while one of proposed methods was 
CBOR Pointer to items, it's draft is expired so I don't know how to act better.
I'm also not sure where ALDR description and may be other things rescued from
CDE draft should go, given voices about moving Appendix A.

Still, all those issues are not fundamental obstacles to publishing document
(in contrast to deep controversies with EDN draft), and can be routinely fixed
relatively fast.

On Sat, 15 Aug 2026 00:45:31 +0300
Vadim Goncharov <[e-mail]> wrote:

> On Thu, 30 Jul 2026 10:19:11 -0400
> Barry Leiba <[e-mail]> wrote:
> 
> > With the posting of the -08 version, the Serialization draft is going
> > into working group last call.
> > 
> >    https://datatracker.ietf.org/doc/draft-ietf-cbor-serialization/
> > 
> > Please review this version and post issues and comments to the CBOR
> > list within the next two weeks: earlier is better.  Working group last
> > call will end on Friday, 14 August.  
> 
> Hi, may be this date is too premature to end WGLC? Many people (at least
> Carsten, henk) are on vacations and will be available end of August. I am, to
> moment, reading the document only till Appendix B. Below are comments so far,
> I'll continue tomorrow - most certainly I'll have a paragraph or two to
> contribute (about ALDR / CBOR Pointer). Note, after first appendix by doing
> Ctrl-F on document, I did not find which of them are declared as normative
> and which informative, except Appendix I. While here, I think introduction
> should mention what each Appendix is about and why so many of them - that
> is, that the topic gives illusion serialization is simple but actually it
> has a number of non-obvious underwater mines.
> 
> 
> Section 4.1 p.5:
> 
> | If a value can be encoded using major type 0 or 1, then it MUST be encoded
> | with major type 0 or 1, never as a big number.
> 
> What about 40-bit "shorter" case? Is "shortest" non-goal for preferred-plus?
> 
> 
> Section 5.1.2 refers "bytewise lexicographic order" from "Section 4.2.1 of
> [STD94] and not the same as Section 3.9 of [RFC7049] / Section 4.2.3 of
> [STD94].)" but both do not specify precisely what is "bytewise", only give
> it ostensibly (by example).
> 
> For example, one well-known sorting in industry is "memcmp() order" (like in,
> say, for filenames in directories), which is defined in e.g. SQLite as:
> 
> int key_compare(const void *key1, int len1, const void *key2, int len2){
>   int c = memcmp(key1, key2, len1<len2 ? len1 : len2);
>   if( c==0 ) c = len1 - len2;
>   return c;
> }
> 
> [For completeness, reference memcmp() implementation behaves as if it is:
> 
> int memcmp(const void *s1, const void *s2, size_t n)
> {
>         if (n != 0) {
>                 const unsigned char *p1 = s1, *p2 = s2;
> 
>                 do {
>                         if (*p1++ != *p2++)
>                                 return (*--p1 - *--p2);
>                 } while (--n != 0);
>         }
>         return (0);
> }
> 
> function in C, typically optimized nowadays, though.]
> 
> This gives sort order where e.g. "aa" is before "aa" and any "z*" can't be
> before any string starting from "a".
> 
> From the 8949, without formal definition, it is not understandable if any of
> those sort orders is memcmp()-order on serialized CBOR representation, or
> both are not. Serialization draft, being oriented towards
> implementers/explainig, should clarify this moment.
> 
> 
> Section 7 new requirement seems to be too hard. It may happen in future that
> some will *have* to violate this rule. For example, tag 296 have modified
> behaviour of tags 28/29 (of course not in all implementations), while
> strictly speaking that was not a modification of *data type*, it is still
> possible, e.g. new tags on numbers have appeared after 8949, and more than
> once.
> 
> 
> For section 8, I am not CDDL expert to comment.
> 
> 
> Section 10: what about introducing a tag(s) (similar to dCBOR tag) to mark
> for decoder that conformance to preferred-plus or deterministic MUST be
> ensured inside? Such tag can also help decoder implementations to select map
> representation in memory to be of hash (fully unordered) or e.g. B-tree (to
> support preserving order on modifications) - while not necessary for
> semantics, this can have implications for performance (e.g. hashes are
> usually more cheap when preserving deterministic is not required), see one
> of my recent messages in list.
> 
> 
> Section 11.3: it has wrong formatting in at least 
> https://www.ietf.org/archive/id/draft-ietf-cbor-serialization-08.html
> version:
> 
> [LAM73]
>     Lampson, B. W., "A Note on the Confinement Problem",
> {"name"=>"Communications of the ACM", "value"=>"16(10)"} , {"name"=>"DOI",
> "value"=>"10.1145/362375.362389"} , October 1973. 
> 
> 
> Appendix A: I think recent discovery about CDDL should be included right
> here, that e.g. number 42 is same in data model, but can have different
> serializations, and note dCBOR approach here.
> 
> 
> > Barry, for the chair team
> > 
> > _______________________________________________
> > CBOR mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]  
> 



-- 
WBR, @nuclight