1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
//! JMAP Blob Content Identifiers extension types
//! (draft-atwood-jmap-cid-00).
//!
//! Normative reference: draft-atwood-jmap-cid-00 — the
//! `urn:ietf:params:jmap:cid` JMAP capability. When a server
//! advertises this capability, it extends the blob upload response
//! defined in RFC 8620 §6.1 with a `sha256` field carrying the
//! SHA-256 digest of the uploaded content as a lowercase hex string
//! of exactly 64 characters. When the JMAP FileNode extension
//! (draft-ietf-jmap-filenode) is also supported, a `sha256` property
//! is added to FileNode objects.
//!
//! CID is independent of any single consumer extension. It is a
//! Blob/FileNode-level extension that any JMAP deployment can
//! advertise, and the `sha256` field defined here is also referenced
//! by draft-atwood-jmap-chat-00 (which defers to this document as
//! the normative definition).
//!
//! ## Crate posture
//!
//! This is a wire-format type crate, per the workspace AGENTS.md
//! kit-vs-jig posture:
//!
//! - No async dependencies.
//! - No JMAP-server / handler-library dependency.
//! - Forbids `unsafe`.
//!
//! ## Crate family position
//!
//! ```text
//! jmap-types
//! └── jmap-cid-types ← this crate (capability + sha256 type)
//! ```
//!
//! ## Public surface
//!
//! - [`Sha256`] — the 64-character lowercase-hex `sha256-value`
//! from draft §2, with parse-time ABNF validation on construction
//! and on deserialize.
//! - [`Sha256DigestError`] / [`Sha256DigestErrorKind`] — parse error
//! reported by [`Sha256::from_hex`] and the [`Sha256`]
//! `Deserialize` impl.
//!
//! ## What this crate is not (yet)
//!
//! Blob upload-response wiring and the `supports_cid()` Session
//! advertisement detection are tracked separately as follow-up beads
//! (bd:JMAP-v9py.13 and bd:JMAP-v9py.14 — see `PLAN.md`).
pub use ;