[Atp] Re: Removing dependency on RFC 7049 (legacy CBOR map key ordering)?

[Bryan Newbold <[e-mail]>]

Hi Michiel,

Thanks for contributing!

To summarize that discussion, it sounds like in the case of CBOR string map
keys with explicit string length (which are the only supported map key data
type in the ATP data model), the three canonical sorting specifications are
the same:

- CBOR RFC-7049 (obsolete) Section 3.9 "Canonical CBOR"
- CBOR RFC-8949 (current) Section 4.2 "Deterministically Encoded CBOR",
sub-section 4.2.1 "Core Deterministic Encoding Requirements"
- CBOR RFC-8949 (current) Section 4.2 "Deterministically Encoded CBOR",
sub-section 4.2.3 "Length-First Map Key Ordering"

The current repo draft text (draft-holmgren-at-repository-02) says:

> *  All arrays, maps, and strings are encoded with explicit lengths; CBOR's
indefinite-length encoding is not used
> *  Map keys are sorted using the legacy length-first ordering of Section
3.9 of [RFC7049]
> *  Maps MUST NOT contain duplicate keys

We definitely need to clarify that map keys must be strings. This is the
case in the deployed network, but wasn't noted in the draft text, or the
previous atproto written specification[0].

I think we should definitely reference RFC-8949 Section 4.2, and not call
this a "legacy" mode. But I think continuing to mention RFC-7049 Section
3.9 could reduce confusion. Perhaps:

> *  All arrays, maps, and strings are encoded with explicit lengths; CBOR's
indefinite-length encoding is not used
> *  Map keys MUST have string type (and per above, an explicit length)
> *  Maps MUST NOT contain duplicate keys
> *  Map keys MUST be sorted using length-first bytewise lexicographic
order of the encoded key. Because all map keys are strings encoded with a
length prefix, this sorting order is described by both [RFC8949] Section
4.2.1 and Section 4.2.3, as well as the earlier [RFC7049] Section 3.9.

A related question is whether map keys can be empty strings. This isn't
mentioned in either the draft text or the existing specifications, only
buried in a separate guide document[1]. I think we can reopen that
question, i'm not sure which implementations do what in the current
network, and it might be simpler not to have an additional idiosyncratic
restriction like this. Eg, I don't see any such restriction in RFC-7493
(I-JSON). Either way, the ATP draft text should clarify the "empty string
map key" question.

--bryan

On Tue, Aug 4, 2026 at 6:22 AM Michiel de Jong <[e-mail]> wrote:

> Hi,
>
> First of all, great to see this WG here!
>
> I would like to discuss Volker's observation from June
> https://github.com/ietf-wg-atp/drafts/issues/6 and its possible
> consequences.
>
> With this, it seems the reference to the deprecated RFC 7049 can be
> removed. That would mean implementers could use an off-the-shelf CBOR
> library instead of a custom one.
>
> It's worth looking at this carefully though, because discovering a
> forgotten edge case after changing the text could cause an ugly network
> split. :)
>
>
> Cheers,
> Michiel de Jong
> (from Unhosted.org)
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>