JMAP Object Metadata

1.1. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Addition to the Capabilities Object

The capabilities object is returned as part of the JMAP Session object; see Section 2 of [RFC8620]. This document defines one additional capability URI.¶

2.1. Object Types

This specification defines three metadata object types: Annotation, ImapMetadata, and WebDavMetadata. The Annotation type provides a generic mechanism for attaching metadata to any JMAP object and supports arbitrary vendor-specific properties. The ImapMetadata and WebDavMetadata types are specialized metadata objects that provide structured access to IMAP METADATA extension [RFC5464] entries and WebDAV [RFC4918] dead properties, respectively, enabling protocol interoperability for servers that support multiple protocols.¶

Additional specifications MAY define further metadata types as needed to address specific use cases or protocol requirements. Such specifications MUST define a unique type identifier and specify which JMAP data types the metadata type may be associated with.¶

Metadata objects MUST name their type in the @type property. If not specified, the type is assumed to be "Annotation".¶

2.2. Properties

{
  "{http://example.com/ns}priority": "high",
  "{http://example.com/ns}reviewedBy": "alice@example.com",
  "{DAV:}displayname": "Project Documents",
  "{http://example.com/ns}complexdata":
     "<item><name>Test</name><value>123</value></item>"
}

3.1. Metadata/set

This is a standard "/set" method as described in Section 5.2 of [RFC8620].¶

The Metadata/set method enforces a uniqueness constraint to ensure consistent metadata management. From the perspective of an authenticated user, their account MUST NOT contain multiple visible Metadata objects with the same combination of parentType, parentId, @type, and isPrivate values. This constraint ensures that for any given parent object and metadata type, the user sees at most one private Metadata object (their own) and at most one shared Metadata object.¶

For shared metadata (isPrivate: false), the server MUST enforce global uniqueness: only one shared Metadata object may exist for each combination of parentType, parentId, and @type across all users.¶

For private metadata (isPrivate: true), the server MUST enforce per-user uniqueness: each user may have at most one private Metadata object for each combination of parentType, parentId, and @type. The server internally may store multiple private Metadata objects for the same parent-type combination (one per user), but each user can only see and modify their own.¶

If a client attempts to create a Metadata object that would violate this uniqueness constraint for the authenticated user, the server MUST reject the create operation with an "invalidProperties" SetError. The SetError SHOULD include a description indicating that a Metadata object with the specified combination of properties already exists. Clients that wish to modify existing metadata should use the update operation rather than attempting to create a duplicate.¶

Similarly, if an update operation would change the parentType, parentId, @type, or isPrivate properties such that the resulting Metadata object would conflict with an existing object visible to the authenticated user, the server MUST reject the update with an "invalidProperties" SetError.¶

If the maySetPrivate capability is false for the account and a client attempts to create or update a Metadata object with isPrivate: true, the server MUST reject the operation with a "forbidden" SetError.¶

Servers SHOULD enforce quota limits when processing Metadata/set requests. If a create or update operation would cause the account's metadata storage to exceed its quota, the server MUST reject the operation with an "overQuota" SetError. The SetError MAY include additional information about the quota limit and current usage in its description property. Quota enforcement is discussed further in Section 6.¶

Servers MUST validate that the parentType and parentId values reference a valid existing object of the appropriate type. If the parent object does not exist or the parentType is not recognized, the server SHOULD reject the operation with an "invalidProperties" SetError, with the "properties" field including "parentType" and/or "parentId" as appropriate.¶

For ImapMetadata objects, servers MUST verify that the parentType is "Mailbox" (Section 2 of [RFC8621]). For WebDavMetadata objects, servers MUST verify that the parentType is one of the supported WebDAV-backed types (Calendar [I-D.ietf-jmap-calendars], CalendarEvent [I-D.ietf-jmap-calendars], AddressBook [RFC9610], ContactCard [RFC9610], FileNode [I-D.ietf-jmap-filenode], or other appropriate types as defined by the server).¶

3.2. Metadata/get

This is a standard "/get" method as described in Section 5.1 of [RFC8620]. The "ids" argument MAY be null to fetch all Metadata objects in the account at once.¶

3.3. Metadata/changes

This is a standard "/changes" method as described in Section 5.2 of [RFC8620].¶

3.4. Metadata/query

This is a standard "/query" method as described in Section 5.5 of [RFC8620].¶

3.5. Metadata/queryChanges

This is a standard "/queryChanges" method as described in Section 5.6 of [RFC8620].¶

4.1. /get

This extension enhances the standard "/get" method defined in Section 5.1 of [RFC8620] for all JMAP data types specified in the dataTypes capability. The extension adds metadata retrieval capabilities to any supported data type's /get method (e.g., Email/get, Mailbox/get, Contact/get).¶

The following additional arguments are defined for the extended /get method:¶

metadataTypes: String[]|null (default: [])

A list of metadata object type identifiers (@type values) to retrieve for the requested objects. If not provided or an empty array is provided, no metadata is returned. If null is specified, all metadata is returned. If one or more type identifiers are specified, the server returns metadata objects of those types associated with the requested objects. Servers MUST support this argument for all data types listed in the dataTypes capability.¶

metadataProperties: String[]|null (default: null)

A list of metadata property names to include in the returned metadata objects. If null, all properties of the metadata objects are returned. If specified, only the requested properties are included in the response. The @type and parentId properties MUST always be included in metadata objects even if not explicitly requested, as they are necessary to correlate metadata with their parent objects and identify the metadata type. This argument follows the same semantics as the properties argument in the standard /get method. Servers MUST support this argument for all data types listed in the dataTypes capability.¶

The response to an extended /get method includes the following additional property:¶

metadata: Metadata[] (default: [])

An array of Metadata objects associated with the objects returned in the list property. The metadata array contains only those metadata objects whose parentId corresponds to an object id in the list response and whose @type matches one of the types specified in the metadataTypes request argument. If metadataTypes was null or empty, this property is an empty array or may be omitted. The parentId property of each metadata object allows clients to correlate metadata with their parent objects.¶

If a requested parent object does not have any metadata of the specified types, it simply will not have corresponding entries in the metadata array.¶

4.2. /set

This specification extends the standard "/set" method defined in Section 5.3 of [RFC8620] for all JMAP data types to ensure proper metadata lifecycle management.¶

When an object is destroyed through a /set method (e.g., Email/set with a destroy operation), the server MUST automatically delete all associated Metadata objects. This includes both private and shared metadata, regardless of which user created them. This cascading deletion ensures that metadata does not become orphaned when its parent object is removed.¶

The automatic deletion of metadata applies to all metadata types (Annotation, ImapMetadata, WebDavMetadata, and any other registered metadata types) associated with the destroyed object.¶

Servers SHOULD NOT generate separate Metadata/set responses or state changes for automatically deleted metadata. The deletion is considered an implicit consequence of destroying the parent object. However, servers MAY emit push notifications or update metadata state strings to reflect that metadata has been deleted, if such notifications would otherwise occur for explicitly deleted metadata.¶

Clients do not need to manually delete metadata before destroying parent objects, and attempting to do so would be inefficient. The server handles metadata cleanup automatically.¶

If an error occurs during parent object deletion that prevents the destruction from completing, the associated metadata MUST NOT be deleted either, maintaining referential integrity.¶

7.1. Creating a Mailbox with Annotation

This example shows how to create a new JMAP Mailbox and associate an Annotation object with vendor-specific properties in a single request.¶

[
  ["Mailbox/set", {
    "accountId": "A12345",
    "create": {
      "new-mailbox": {
        "name": "Project Alpha",
        "parentId": null,
        "role": null
      }
    }
  }, "c1"],
  ["Metadata/set", {
    "accountId": "A12345",
    "create": {
      "new-metadata": {
        "@type": "Annotation",
        "parentType": "Mailbox",
        "parentId": "#new-mailbox",
        "isPrivate": true,
        "acme.example.com:color": "blue",
        "acme.example.com:priority": "high",
        "acme.example.com:project": {
          "@type": "acme.example.com:ProjectInfo",
          "projectId": "ALPHA-2024",
          "deadline": "2024-12-31",
          "team": "Engineering"
        }
      }
    }
  }, "c2"]
]

7.2. Retrieving a Mailbox with Metadata

This example shows how to retrieve the created mailbox along with its associated Annotation metadata in a single request using the extended /get method:¶

Request:¶

[
  ["Mailbox/get", {
    "accountId": "A12345",
    "ids": ["MB789"],
    "properties": ["name", "parentId", "role"],
    "metadataTypes": ["Annotation"],
    "metadataProperties": ["acme.example.com:color",
                           "acme.example.com:priority"]
  }, "c3"]
]

Response:¶

[
  ["Mailbox/get", {
    "accountId": "A12345",
    "state": "m101",
    "list": [
      {
        "id": "MB789",
        "name": "Project Alpha",
        "parentId": null,
        "role": null
      }
    ],
    "metadata": [
      {
        "parentId": "MB789",
        "@type": "Annotation",
        "acme.example.com:color": "blue",
        "acme.example.com:priority": "high"
      }
    ],
    "notFound": []
  }, "c3"]
]

7.3. Attaching Photography Metadata to a FileNode

This example demonstrates using a fictional registered PhotoMetadata type to attach photography information to FileNode [I-D.ietf-jmap-filenode] objects. The PhotoMetadata type is assumed to be an IANA-registered metadata type specifically designed for photographic data.¶

Request:¶

[
  ["FileNode/set", {
    "accountId": "A12345",
    "update": {
      "F456": {
        "name": "lake-island.jpg"
      }
    }
  }, "c1"],
  ["Metadata/set", {
    "accountId": "A12345",
    "create": {
      "photo-meta": {
        "@type": "PhotoMetadata",
        "parentType": "FileNode",
        "parentId": "F456",
        "isPrivate": false,
        "geoLocation": {
          "latitude": 46.362,
          "longitude": 14.090
        },
        "cameraMake": "Canon",
        "cameraModel": "EOS R5",
        "aperture": "f/2.8",
        "shutterSpeed": "1/250",
        "iso": 400,
        "focalLength": "50mm",
        "dateTaken": "2023-10-01T01:14:00Z",
        "imageSize": {
          "width": 6000,
          "height": 4000
        }
      }
    }
  }, "c2"]
]

7.4. Retrieving a FileNode with Photography Metadata

Request:¶

[
  ["FileNode/get", {
    "accountId": "A12345",
    "ids": ["F456"],
    "metadataTypes": ["PhotoMetadata"],
    "metadataProperties": null
  }, "c3"]
]

Response:¶

[
  ["FileNode/get", {
    "accountId": "A12345",
    "state": "f201",
    "list": [
      {
        "id": "F456",
        "name": "lake-island.jpg",
        "type": "image/jpeg",
        "size": 2458624,
        "blobId": "Gabc123def456",
        "parentId": "folder789",
        "createdDate": "2024-07-15T20:00:00Z",
        "modifiedDate": "2024-10-20T15:30:00Z"
      }
    ],
    "metadata": [
      {
        "id": "photometa99",
        "@type": "PhotoMetadata",
        "parentId": "F456",
        "geoLocation": {
          "latitude": 46.362,
          "longitude": 14.090
        },
        "cameraMake": "Canon",
        "cameraModel": "EOS R5",
        "aperture": "f/2.8",
        "shutterSpeed": "1/250",
        "iso": 400,
        "focalLength": "50mm",
        "dateTaken": "2023-10-01T01:14:00Z",
        "imageSize": {
          "width": 6000,
          "height": 4000
        }
      }
    ],
    "notFound": []
  }, "c3"]
]

8.1. Metadata Confidentiality

Metadata objects may contain sensitive information, including personal notes, workflow states, application-specific data, and other user-generated content. Servers MUST enforce the access control mechanisms defined in Access Control (Section 5) to prevent unauthorized disclosure of metadata.¶

Private metadata (isPrivate: true) contains information intended only for the authenticated user who created it. Servers MUST ensure that private metadata is never exposed to other users through any interface, including JMAP, IMAP, WebDAV, or any other supported protocols. Each user's private metadata must remain isolated from all other users, even those who have full access to the parent object.¶

The per-user nature of private metadata introduces important implementation considerations. Since multiple users may each have their own private Metadata objects for the same parent object and metadata type, servers must carefully track which user created each private Metadata object. When processing queries or retrieval requests, servers MUST filter results to include only the private metadata belonging to the currently authenticated user. Failure to properly implement this filtering could result in serious privacy breaches where one user's private notes or annotations are exposed to other users.¶

Shared metadata visibility is tied to the permissions of the parent object. Servers MUST consistently enforce these permissions across all access methods. When sharing permissions on a parent object change, the visibility of associated shared metadata MUST change accordingly. Servers should be cautious about caching metadata in ways that could bypass updated permission checks.¶

For servers that bridge JMAP metadata to IMAP METADATA or WebDAV properties, special care must be taken to ensure that the visibility and access control semantics are correctly mapped between protocols. IMAP private metadata (entries under "/private/") must map to JMAP private metadata for the authenticated user. Access control on WebDAV properties must align with JMAP shared metadata permissions. Servers must ensure that the per-user isolation model is maintained when metadata is accessed through different protocol interfaces.¶

8.2. User Identity and Authentication

The private metadata model relies critically on accurate user authentication and identity management. Servers MUST:¶

• Reliably identify the authenticated user for all metadata operations¶

• Maintain accurate association between private Metadata objects and their creating users¶

• Prevent authentication bypass or identity spoofing that could allow access to other users' private metadata¶

• Handle account delegation or administrative access carefully to ensure private metadata is not inadvertently exposed (administrators accessing an account on behalf of a user should not see other users' private metadata on shared objects)¶

Servers that support account delegation, impersonation, or administrative access features must carefully consider whether delegated access should include visibility into the account owner's private metadata, and should provide controls to limit such access when appropriate.¶

8.3. Injection Attacks Through Vendor-Specific Properties

The extensibility mechanism that allows vendor-specific properties introduces potential security risks if not properly handled. Malicious clients could attempt to inject harmful content through vendor-specific properties, including:¶

• Script injection: Embedding executable code in metadata properties that might be rendered in a web context without proper sanitization¶

• XML/JSON injection: Crafting property values that could break parsing or processing logic¶

• Path traversal: Using specially crafted property names to attempt unauthorized file system access¶

• SQL injection: If metadata is stored in SQL databases, unsanitized property values could lead to SQL injection vulnerabilities¶

Servers MUST treat all vendor-specific property values as untrusted user input. When storing, processing, or displaying metadata, servers and clients MUST:¶

• Validate property names conform to the specified format (domain-name prefix followed by colon and property name)¶

• Sanitize property values before use in any context where interpretation could occur (HTML rendering, script execution, database queries, etc.)¶

• Apply appropriate output encoding when displaying metadata to users¶

• Enforce length limits on property names and values to prevent resource exhaustion¶

• Reject or sanitize properties containing control characters or other potentially harmful content¶

For WebDavMetadata objects, special attention must be paid to the serialized XML content in property values. Servers MUST:¶

• Validate that XML content is well-formed before storage¶

• Sanitize XML to remove potentially harmful constructs (scripts, entity expansions, external entity references)¶

• Apply appropriate XML entity encoding when processing or displaying the content¶

• Implement protections against XML external entity (XXE) attacks and XML bomb attacks¶

Clients that display metadata to users MUST treat metadata content as untrusted and apply appropriate security measures, such as Content Security Policy restrictions, HTML sanitization, and context-appropriate escaping.¶

8.4. Resource Exhaustion and Denial of Service

Without proper controls, metadata management features could be abused to cause resource exhaustion or denial of service:¶

• Storage exhaustion: Attackers could create excessive metadata to consume storage quota or server resources. The per-user private metadata model amplifies this risk since multiple users could each create private metadata on the same shared objects.¶

• Processing exhaustion: Complex nested vendor-specific properties or deeply nested object structures could consume excessive CPU or memory during processing¶

• Query complexity: Expensive metadata queries, particularly those involving private metadata filtering across many users, could strain server resources¶

Servers SHOULD implement the quota mechanisms described in Section 6 to limit total metadata storage per account. Additionally, servers SHOULD:¶

• Enforce the maxDepth limit on nested vendor-specific properties¶

• Implement timeouts for metadata operations to prevent long-running queries¶

• Apply rate limiting to metadata creation and modification operations¶

• Monitor for unusual patterns of metadata usage that might indicate abuse (e.g., one user creating private metadata on unusually large numbers of objects)¶

• Implement reasonable limits on the size of individual property values¶

• Consider implementing separate quota tracking for private vs. shared metadata to prevent abuse¶

Servers MAY reject metadata creation or updates that appear abusive, returning appropriate SetError responses.¶

8.5. Protocol Bridging Risks

For servers that bridge JMAP metadata to IMAP METADATA or WebDAV properties, inconsistencies or vulnerabilities in the bridging logic could lead to security issues:¶

• Permission bypass: Differences in permission models between protocols could be exploited to gain unauthorized access. For example, IMAP and WebDAV may have different concepts of private vs. shared metadata that must be carefully reconciled.¶

• Metadata corruption: Improper format conversion could corrupt metadata or enable injection attacks. Special care is needed when converting between JMAP's JSON representation, IMAP's string values, and WebDAV's XML properties.¶

• Information leakage: Protocol-specific metadata might inadvertently be exposed through the bridging mechanism. For instance, internal IMAP server entries or WebDAV live properties should not be exposed as JMAP metadata.¶

• Synchronization inconsistencies: Race conditions or improper locking when synchronizing metadata across protocol boundaries could lead to data corruption or access control violations.¶

Servers that implement protocol bridging MUST carefully validate the security properties of their bridging implementation and ensure that the most restrictive applicable access control is enforced. The per-user isolation model for private metadata must be maintained consistently across all protocol interfaces.¶

For read-only ImapMetadata and WebDavMetadata access, servers should clearly document this limitation to prevent client confusion and ensure that clients do not assume modification capabilities that are not actually available.¶

8.6. Server Vulnerabilities

Implementations must be robust against malformed requests and unexpected data. Servers MUST:¶

• Validate all input according to the type specifications in this document¶

• Handle JSON/XML parsing errors gracefully without exposing server internals¶

• Protect against integer overflow, buffer overflow, and other common vulnerabilities when processing metadata¶

• Properly handle the per-user filtering of private metadata to prevent information leakage¶

• Implement proper database indexing and query optimization to handle private metadata filtering efficiently even with large numbers of users and objects¶

• Log security-relevant events (authentication failures, authorization failures, suspicious patterns, attempts to access other users' private metadata) for monitoring and incident response¶

8.7. Client Vulnerabilities

Clients that implement metadata management must also consider security:¶

• Clients MUST validate server responses and handle unexpected or malformed data gracefully¶

• Clients SHOULD warn users before displaying potentially sensitive metadata, particularly when displaying shared metadata that might have been created by other users¶

• Clients MUST NOT execute or interpret metadata content as code unless the user explicitly requests it and appropriate sandboxing is in place¶

• Clients accessing metadata through web browsers should utilize security features such as Content Security Policy¶

• Clients should clearly distinguish between private and shared metadata in the user interface to prevent users from inadvertently sharing private information¶

• When parsing XML content from WebDavMetadata properties, clients must use secure XML parsers and disable dangerous features like external entity resolution¶

9.1. JMAP Capability Registration for "metadata"

IANA will register the "metadata" JMAP Capability as follows:¶

Capability Name: urn:ietf:params:jmap:metadata
Specification document: this document
Intended use: common
Change Controller: IETF
Security and privacy considerations: this document, Section 8¶

9.2. JMAP Data Type Registration for "Metadata"

IANA will register "Metadata" in the "JMAP Data Types" registry as follows:¶

Type Name: Metadata
Can reference blobs: no
Can Use for State Change: yes
Capability: urn:ietf:params:jmap:metadata
Specification document: this document¶

9.3. Creation of the "JMAP Metadata Properties" Registry

IANA has created the "JMAP Metadata Properties" registry to allow interoperability of extensions to JMAP Metadata objects.¶

This registry follows the Expert Review process ([RFC8126], Section 4.5). If the "Intended Usage" field is common, sufficient documentation is required to enable interoperability. Preliminary community review for this registry is optional but strongly encouraged.¶

A registration can have an intended usage of common, reserved, or obsolete. IANA will list registrations with a common usage designation prominently and separately from those with other intended usage values.¶

A reserved registration reserves a property name without assigning semantics to avoid name collisions with future extensions or protocol use.¶

An obsolete registration denotes a property that is no longer expected to be added by up-to-date systems. A new property has probably been defined covering the obsolete property's semantics.¶

The JMAP Metadata property registration procedure is not a formal standards process but rather an administrative procedure intended to allow community comment and check it is coherent without excessive time delay. It is designed to encourage vendors to document and register new properties they add for use cases not covered by the original specification, leading to increased interoperability¶

9.4. Creation of the "JMAP Metadata Types" Registry

IANA has created the "JMAP Metadata Types" registry to avoid name collisions and provide a complete reference for all metadata types used for JMAP Metadata property values. The registration process is the same as for the "JMAP Metadata Properties" registry, as defined in Section 9.3.¶

10.1. Normative References

[I-D.ietf-jmap-calendars]

Jenkins, N. and M. Douglass, "JSON Meta Application Protocol (JMAP) for Calendars", Work in Progress, Internet-Draft, draft-ietf-jmap-calendars-25, 8 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-jmap-calendars-25>.

[I-D.ietf-jmap-filenode]

Gondwana, B., "JMAP File Storage extension", Work in Progress, Internet-Draft, draft-ietf-jmap-filenode-03, 17 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-jmap-filenode-03>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4918]

Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/rfc/rfc4918>.

[RFC5464]

Daboo, C., "The IMAP METADATA Extension", RFC 5464, DOI 10.17487/RFC5464, February 2009, <https://www.rfc-editor.org/rfc/rfc5464>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8620]

Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, <https://www.rfc-editor.org/rfc/rfc8620>.

[RFC9610]

Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP) for Contacts", RFC 9610, DOI 10.17487/RFC9610, December 2024, <https://www.rfc-editor.org/rfc/rfc9610>.

[RFC9670]

Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP) Sharing", RFC 9670, DOI 10.17487/RFC9670, November 2024, <https://www.rfc-editor.org/rfc/rfc9670>.

10.2. Informative References

[RFC3501]

Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/rfc/rfc3501>.

[RFC4791]

Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007, <https://www.rfc-editor.org/rfc/rfc4791>.

[RFC6352]

Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, DOI 10.17487/RFC6352, August 2011, <https://www.rfc-editor.org/rfc/rfc6352>.

[RFC8621]

Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, August 2019, <https://www.rfc-editor.org/rfc/rfc8621>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9425]

Cordier, R., Ed., "JSON Meta Application Protocol (JMAP) for Quotas", RFC 9425, DOI 10.17487/RFC9425, June 2023, <https://www.rfc-editor.org/rfc/rfc9425>.