JSON Meta Application Protocol (JMAP) for Quotas
Extracted elements (25)
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.
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.
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.
If the server is unable to determine whether only the 'used' Quota property changed in Quota/changes, the updatedProperties field MUST be null.
Objects in scope may not be created or updated if the hardLimit is reached.
Quotas with 'domain' or 'global' scope SHOULD only be visible to server administrators and not to general users, to limit privacy leakage attacks.
Servers MUST support the JMAP push mechanisms (RFC 8620, Section 7) to allow clients to receive notifications when the Quota type state changes.
Servers supporting this specification MUST add a property called 'urn:ietf:params:jmap:quota' to the capabilities object.
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.
The Quota object MUST contain the fields: id, resourceType, used, hardLimit, scope, name, and types.
The Quota/query method MUST support sorting by the 'name' and 'used' properties.
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.
The 'softLimit', if set, SHOULD be higher than the 'warnLimit' (if present and not null) but lower than the 'hardLimit'.
The 'warnLimit', if set, SHOULD be lower than the 'softLimit' (if present and not null) and the 'hardLimit'.
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.
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.
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.
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.
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.
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).
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).
IANA has registered the JMAP Capability 'urn:ietf:params:jmap:quota' with intended use 'common', change controller IETF, referencing RFC 9425.
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.
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.
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.