rfc-9425

JSON Meta Application Protocol (JMAP) for Quotas

R. Cordier (Editor)
date2023-06 streamIETF areaart wgjmap statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc9425 doi10.17487/RFC9425
This document specifies a data model for handling quotas on accounts with a server using the JSON Meta Application Protocol (JMAP).

Extracted elements (25)

design-rationale §4.3

The Quota/changes method tracks 'used' property changes separately from other state changes because usage changes frequently while other properties rarely change. The 'updatedProperties' back-reference allows clients to fetch only changed properties in a subsequent Quota/get, optimizing data transfer.

http, json

design-rationale §1

This specification deliberately excludes quota administration, leaving that to be handled by other means. The scope is limited to read-only quota visibility for clients.

http, json

interoperability-note §8

All security considerations of the core JMAP specification (RFC 8620) apply to this extension. The Quota methods follow standard JMAP /get, /changes, /query, and /queryChanges conventions from RFC 8620.

http, json

normative-requirement §4.3 MUST

If the server is unable to determine whether only the 'used' Quota property changed in Quota/changes, the updatedProperties field MUST be null.

http, json

normative-requirement §4.1 MUST

Objects in scope may not be created or updated if the hardLimit is reached.

http, json

normative-requirement §8 SHOULD

Quotas with 'domain' or 'global' scope SHOULD only be visible to server administrators and not to general users, to limit privacy leakage attacks.

http, json, privacy, security

normative-requirement §6 MUST

Servers MUST support the JMAP push mechanisms (RFC 8620, Section 7) to allow clients to receive notifications when the Quota type state changes.

http, json

normative-requirement §2.1 MUST

Servers supporting this specification MUST add a property called 'urn:ietf:params:jmap:quota' to the capabilities object.

http, json

normative-requirement §4.1 MUST

The 'description' field MUST be encoded in UTF-8 and selected based on an Accept-Language header in the request or out-of-band information about the user's language or locale.

http, json

normative-requirement §4.1 MUST

The Quota object MUST contain the fields: id, resourceType, used, hardLimit, scope, name, and types.

http, json

normative-requirement §4.4 MUST

The Quota/query method MUST support sorting by the 'name' and 'used' properties.

http, json

normative-requirement §4.1 MUST NOT

The server MUST filter out any types from the Quota 'types' field for which the client did not request the associated capability, and MUST NOT return Quota objects for which there are no types recognized by the client.

http, json

normative-requirement §4.1 SHOULD

The 'softLimit', if set, SHOULD be higher than the 'warnLimit' (if present and not null) but lower than the 'hardLimit'.

http, json

normative-requirement §4.1 SHOULD

The 'warnLimit', if set, SHOULD be lower than the 'softLimit' (if present and not null) and the 'hardLimit'.

http, json

privacy-consideration §8

Revealing domain and global quota counts to general users can expose the existence of other sensitive data. For example, comparing quota counts before and after sending to a private mailing list can reveal the number of list subscribers. Domain and global scope quotas SHOULD only be visible to administrators.

privacy, security, http, json

protocol-element §4.3

Quota/changes extends the standard JMAP /changes method with an 'updatedProperties' field: if only 'used' changed since the old state, this is a list containing only that property; otherwise it is null if the server cannot determine this.

http, json

protocol-element §4.4

Quota/query supports FilterCondition with properties: name (string contains), scope (exact match), resourceType (exact match), and type (types array contains). A Quota matches only if all given conditions match; zero conditions match all objects.

http, json

protocol-element §4.1

The Quota object represents a limit set on an account's resource usage, displaying both the limit and current usage. Required fields are: id, resourceType, used, hardLimit, scope, name, and types.

http, json

protocol-element §4.1

The Quota 'softLimit' field can be used to block outgoing events (sending emails, creating calendar events) while still allowing incoming events, or other server-defined partial restrictions before the hard limit is reached.

http, json

protocol-element §3.2

The ResourceType enumeration defines two units of measure: 'count' (quota measured in number of data type objects) and 'octets' (quota measured in size in octets).

http, json

protocol-element §3.1

The Scope enumeration defines three values for quota applicability: 'account' (applies to the client's account only), 'domain' (applies to all accounts sharing a domain), and 'global' (applies to all accounts on the server).

http, json

registry §7.1

IANA has registered the JMAP Capability 'urn:ietf:params:jmap:quota' with intended use 'common', change controller IETF, referencing RFC 9425.

registry, http, json

registry §7.2

IANA has registered the JMAP Data Type 'Quota' with Can Reference Blobs: No, Can Use for State Change: Yes, capability urn:ietf:params:jmap:quota, referencing RFC 9425.

registry, http, json

security-consideration §8

Resource usage of other users is likely confidential and should not be divulged to unauthorized persons. Implementors must ensure the extension does not violate the site's security policy.

security, http, json

security-consideration §8

With shared quotas (domain or global scope), a malicious user can exhaust the shared resource for all other users, e.g., by spamming themselves with events. Implementors should consider rate-limiting to mitigate this.

security, http, json