MIME-Version: 1.0
References: 
 <CA+aD3u20G_LzmpXhuPhVz5e4w=VjJuvhVrgrHj48O05HV-SQRg@mail.gmail.com>
In-Reply-To: 
 <CA+aD3u20G_LzmpXhuPhVz5e4w=VjJuvhVrgrHj48O05HV-SQRg@mail.gmail.com>
From: Bryan Newbold <bryan@blueskyweb.xyz>
Date: Wed, 19 Aug 2026 16:18:58 -0700
Message-ID: 
 <CABFYohgybcwM1FMR5ZG2zsVtnUSqq_s0kOznbWYX9rxgF_rGJQ@mail.gmail.com>
To: Michiel de Jong <michiel@unhosted.org>
Content-Type: multipart/alternative; boundary="00000000000068369e06596ea130"
Message-ID-Hash: MTFO3IVZV4L3GSFUH2PSTC36MZGGBCIP
CC: atp@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BAtp=5D_Re=3A_Removing_dependency_on_RFC_7049_=28legacy_CBOR_map?=
	=?utf-8?q?_key_ordering=29=3F?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/atp/TQk-t4fX1O3RCgy-hboOXMYJMMI>

--00000000000068369e06596ea130
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Michiel de Jong <michiel@unhosted.or=
g> 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 -- atp@ietf.org
> To unsubscribe send an email to atp-leave@ietf.org
>

--00000000000068369e06596ea130
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Michiel,<div><br></div><div>Thanks for contributing!</d=
iv><div><br></div><div>To summarize that discussion, it sounds like in the =
case of CBOR string map keys with explicit string length (which are the onl=
y supported map key data type in the ATP data model), the three canonical s=
orting specifications are the same:</div><div><br></div><div>- CBOR RFC-704=
9 (obsolete) Section 3.9 &quot;Canonical CBOR&quot;</div><div>- CBOR RFC-89=
49 (current) Section 4.2 &quot;Deterministically Encoded CBOR&quot;, sub-se=
ction 4.2.1 &quot;<span style=3D"background-color:transparent">Core Determi=
nistic Encoding Requirements&quot;</span></div><div><div>- CBOR RFC-8949 (c=
urrent) Section 4.2 &quot;Deterministically Encoded CBOR&quot;, sub-section=
 4.2.3 &quot;Length-First Map Key Ordering<span style=3D"background-color:t=
ransparent">&quot;</span></div></div><div><br></div><div>The current repo d=
raft text (<span style=3D"background-color:transparent">draft-holmgren-at-r=
epository-02) says:</span></div><div><span style=3D"background-color:transp=
arent"><br></span></div><div><span style=3D"background-color:transparent">&=
gt; *=C2=A0</span><span style=3D"background-color:transparent">=C2=A0All ar=
rays, maps, and strings are encoded with explicit lengths;=C2=A0</span><spa=
n style=3D"background-color:transparent">CBOR&#39;s indefinite-length encod=
ing is not used</span></div><div><span style=3D"background-color:transparen=
t">&gt;</span><span style=3D"background-color:transparent">=C2=A0* =C2=A0Ma=
p keys are sorted using the legacy length-first ordering of </span><span st=
yle=3D"background-color:transparent">Section 3.9 of [RFC7049]</span></div><=
div>&gt; * =C2=A0Maps MUST NOT contain duplicate keys<span style=3D"backgro=
und-color:transparent"></span></div><div><br></div><div>We definitely need =
to clarify that map keys must be strings. This is the case in the deployed =
network, but wasn&#39;t noted in the draft text, or the previous atproto wr=
itten specification[0].</div><div><br></div><div>I think we should definite=
ly reference=C2=A0<span style=3D"background-color:transparent">RFC-8949 Sec=
tion 4.2, and not call this a &quot;legacy&quot; mode. But I think continui=
ng to mention=C2=A0</span><span style=3D"background-color:transparent">RFC-=
7049 Section 3.9 could reduce confusion. Perhaps:</span></div><div><span st=
yle=3D"background-color:transparent"><br></span></div><div><div><span style=
=3D"background-color:transparent">&gt; *=C2=A0</span><span style=3D"backgro=
und-color:transparent">=C2=A0All arrays, maps, and strings are encoded with=
 explicit lengths;=C2=A0</span><span style=3D"background-color:transparent"=
>CBOR&#39;s indefinite-length encoding is not used</span></div><div><div><d=
iv>&gt; *=C2=A0 Map keys MUST have string type (and per above, an explicit =
length)</div><div>&gt; *=C2=A0 Maps MUST NOT contain duplicate keys</div></=
div></div><div><span style=3D"background-color:transparent">&gt;</span><spa=
n style=3D"background-color:transparent">=C2=A0* =C2=A0Map keys MUST be sor=
ted using length-first=C2=A0</span><span style=3D"background-color:transpar=
ent">bytewise lexicographic order of the encoded key. Because all map keys =
are strings encoded with a length prefix, this sorting order is described b=
y both [RFC8949] Section 4.2.1 and Section 4.2.3, as well as the earlier [R=
FC7049] Section 3.9.</span></div><div><br></div></div><div>A related questi=
on is whether map keys can be empty strings. This isn&#39;t mentioned in ei=
ther the draft text or the existing specifications, only buried in a separa=
te guide document[1]. I think we can reopen that question, i&#39;m not sure=
 which implementations do what in the current network, and it might be simp=
ler not to have an additional idiosyncratic restriction like this. Eg, I do=
n&#39;t see any such restriction in RFC-7493 (I-JSON). Either way, the ATP =
draft text should clarify the &quot;empty string map key&quot; question.</d=
iv><div><br></div><div><div>--bryan</div></div></div><br><div class=3D"gmai=
l_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue=
, Aug 4, 2026 at 6:22=E2=80=AFAM Michiel de Jong &lt;<a href=3D"mailto:mich=
iel@unhosted.org">michiel@unhosted.org</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><d=
iv>First of all, great to see this WG here!<br><div><br></div><div>I would =
like to discuss<span style=3D"background-color:transparent">=C2=A0Volker=
9;s observation</span><span style=3D"background-color:transparent">=C2=A0</=
span><span style=3D"background-color:transparent">from June</span>=C2=A0<a =
href=3D"https://github.com/ietf-wg-atp/drafts/issues/6" target=3D"_blank">h=
ttps://github.com/ietf-wg-atp/drafts/issues/6</a> and its possible conseque=
nces.</div><div><span style=3D"background-color:transparent"><br></span></d=
iv><div>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 libr=
ary instead of a custom one.</div><div><br></div><div>It&#39;s worth lookin=
g at this carefully though, because discovering a forgotten edge case after=
 changing the text could cause an ugly network split. :)</div><div><br></di=
v><div><br></div><div>Cheers,</div><div>Michiel de Jong</div><div>(from Unh=
osted.org)</div></div></div>
_______________________________________________<br>
Atp mailing list -- <a href=3D"mailto:atp@ietf.org" target=3D"_blank">atp@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:atp-leave@ietf.org" targe=
t=3D"_blank">atp-leave@ietf.org</a><br>
</blockquote></div>

--00000000000068369e06596ea130--