Add cbor2 to implementation list#113
Conversation
There was a problem hiding this comment.
Pull request overview
Adds the Rust cbor2 library to the CBOR implementations page (impls.html) so visitors can discover it alongside other Rust CBOR crates.
Changes:
- Added a new Rust implementation entry for
cbor2. - Included links to the crate on crates.io and the source repository on GitHub.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <p>The cbor2 implementation, available on | ||
| <a href="https://crates.io/crates/cbor2">crates.io</a>, supports CBOR tags | ||
| and a no_std/no_alloc feature matrix:</p> |
| <a href="https://crates.io/crates/cbor2">crates.io</a>. It supports: | ||
| async item I/O, serde round trips, canonical and deterministic encoding, | ||
| Value/RawValue, semantic tags, COSE integer keys and arrays, | ||
| validation, diagnostic notation, and no_std.</p> |
There was a problem hiding this comment.
Now you got me curious: How do you do validation? (I'm asking because maybe there should be an adjective there that reveals this.)
There was a problem hiding this comment.
Thank you — that is a good question, and I realize “validation” was too vague here.
What I meant is cbor2::validate: it checks that the input is exactly one well-formed CBOR item, including structural validity, nesting limits, text UTF-8, and no trailing bytes, without deserializing into a Rust type. So it is meant as a lightweight well-formedness / exact-one-item validation pass, not schema or application-level validation.
Would “well-formedness validation” or “exact-one-item validation” be a better phrase here? I’m happy to adjust the wording.
There was a problem hiding this comment.
", with separately available well-formedness check" would be a good summary, I think.
(Validation usually implies conformance to some application protocol.)
| for Rust, available on | ||
| <a href="https://crates.io/crates/cbor2">crates.io</a>. It supports: | ||
| async item I/O, serde round trips, canonical and deterministic encoding, | ||
| Value/RawValue, semantic tags, COSE integer keys and arrays, |
There was a problem hiding this comment.
"COSE integer keys and arrays" is a weird combination -- I'm assuming you support integer keys for maps, like they are used in COSE and many other protocols, and arrays (but is the latter noteworthy?)
There was a problem hiding this comment.
You are right — I compressed several things into a phrase that reads oddly.
What I meant is that #[derive(cbor2::Cbor)] supports integer map keys, such as the labels used by COSE / CWT-style structures, and also CBOR tags. Separately, it can represent array-shaped structs, which is useful for COSE-like structures such as COSE_Sign1, but “arrays” by itself is probably not noteworthy enough in this list.
I can reword this to something like:
“COSE-style integer map keys, semantic tags, and derive support for tagged / array-shaped structures”
or simply:
“COSE-style integer map keys and semantic tags”
if you prefer the shorter version.
Co-Authored-By: Anda Bot <noreply@anda.bot>
|
Thank you, that makes sense. I updated the summary to use “with separately available well-formedness check”, and also aligned the cbor2 README / Cargo metadata with this wording. If this looks good now, would you mind merging it? Thanks again for the careful review. |
Add cbor2 to the Rust implementations list on https://cbor.io/impls.html with links to crates.io and GitHub.