RFC 9425: JSON Meta Application Protocol (JMAP) for Quotas

Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9425.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

The JSON Meta Application Protocol (JMAP) [RFC8620] is a generic protocol for synchronizing data, such as mails, calendars, or contacts between a client and a server. It is optimized for mobile and web environments and aims to provide a consistent interface to different data types.¶

This specification defines a data model for handling quotas over JMAP, allowing a user to obtain details about a certain quota.¶

This specification does not address quota administration, which should be handled by other means.¶

2. Addition to the Capabilities Object

The capabilities object is returned as part of the JMAP Session object; see [RFC8620], Section 2.¶

This document defines one additional capability URI.¶

3. Sub-types of the Quota Data Type

There are two fields within the Quota data type, which have an enumerated set of possible values. These are:¶

4. Quota

The Quota is an object that displays the limit set to an account usage. It then shows as well the current usage in regard to that limit.¶

5. Examples

[[ "Quota/get", {
  "accountId": "u33084183",
  "ids": null
}, "0" ]]

[[ "Quota/get", {
  "accountId": "u33084183",
  "state": "78540",
  "list": [{
    "id": "2a06df0d-9865-4e74-a92f-74dcc814270e",
    "resourceType": "count",
    "used": 1056,
    "warnLimit": 1600,
    "softLimit": 1800,
    "hardLimit": 2000,
    "scope": "account",
    "name": "bob@example.com",
    "description": "Personal account usage. When the soft limit is
                    reached, the user is not allowed to send mails or
                    create contacts and calendar events anymore.",
    "types" : [ "Mail", "Calendar", "Contact" ]
  }, {
    "id": "3b06df0e-3761-4s74-a92f-74dcc963501x",
    "resourceType": "octets",
    ...
  }, ...],
  "notFound": []
}, "0" ]]

[[ "Quota/changes", {
  "accountId": "u33084183",
  "sinceState": "78540",
  "maxChanges": 20
}, "0" ],
[ "Quota/get", {
  "accountId": "u33084183",
  "#ids": {
    "resultOf": "0",
    "name": "Quota/changes",
    "path": "/updated"
  },
  "#properties": {
    "resultOf": "0",
    "name": "Quota/changes",
    "path": "/updatedProperties"
  }
}, "1" ]]

[[ "Quota/changes", {
  "accountId": "u33084183",
  "oldState": "78540",
  "newState": "78542",
  "hasMoreChanges": false,
  "updatedProperties": ["used"],
  "created": [],
  "updated": ["2a06df0d-9865-4e74-a92f-74dcc814270e"],
  "destroyed": []
}, "0" ],
[ "Quota/get", {
  "accountId": "u33084183",
  "state": "10826",
  "list": [{
    "id": "2a06df0d-9865-4e74-a92f-74dcc814270e",
    "used": 1246
  }],
  "notFound": []
}, "1" ]]

6. Push

Servers MUST support the JMAP push mechanisms, as specified in [RFC8620], Section 7, to allow clients to receive notifications when the state changes for the Quota type defined in this specification.¶

7. IANA Considerations

8. Security Considerations

All security considerations of JMAP [RFC8620] apply to this specification.¶

Implementors should be careful to make sure the implementation of the extension specified in this document does not violate the site's security policy. The resource usage of other users is likely to be considered confidential information and should not be divulged to unauthorized persons.¶

As for any resource shared across users (for example, a quota with the "domain" or "global" scope), a user that can consume the resource can affect the resources available to the other users. For example, a user could spam themselves with events and make the shared resource hit the limit and unusable for others (implementors could mitigate that with some rate-limiting implementation on the server).¶

Also, revealing domain and global quota counts to all users may cause privacy leakage of other sensitive data, or at least the existence of other sensitive data. For example, some users are part of a private list belonging to the server, so they shouldn't know how many users are in there. However, by comparing the quota count before and after sending a message to the list, it could reveal the number of people of the list, as the domain or global quota count would go up by the number of people subscribed. In order to limit those attacks, quotas with "domain" or "global" scope SHOULD only be visible to server administrators and not to general users.¶

Acknowledgements

Thank you to Michael Bailly, who co-wrote the first draft version of this document, before deciding to turn to other matters.¶

Thank you to Benoit Tellier for his constant help and support on writing this document.¶

Thank you to Raphael Ouazana for sharing his own experience on how to write an RFC after finalizing his own document: [RFC9007].¶

Thank you to Bron Gondwana, Neil Jenkins, Alexey Melnikov, Joris Baum, and the people from the IETF JMAP working group in general, who helped with extensive discussions, reviews, and feedback.¶

Thank you to the people in the IETF organization, who took the time to read, understand, comment, and give great feedback in the last rounds.¶

Author's Address