RFC 8620
The JSON Meta Application Protocol (JMAP)
8. Security Considerations
8.1. Transport Confidentiality
To ensure the confidentiality and integrity of data sent and received via JMAP, all requests MUST use TLS 1.2 [RFC5246] [RFC8446] or later, following the recommendations in [RFC7525]. Servers SHOULD support TLS 1.3 [RFC8446] or later. Clients MUST validate TLS certificate chains to protect against man-in-the-middle attacks [RFC5280].8.2. Authentication Scheme
A number of HTTP authentication schemes have been standardised (see <https://www.iana.org/assignments/http-authschemes/>). Servers should take care to assess the security characteristics of different schemes in relation to their needs when deciding what to implement. Use of the Basic authentication scheme is NOT RECOMMENDED. Services that choose to use it are strongly recommended to require generation of a unique "app password" via some external mechanism for each client they wish to connect. This allows connections from different devices to be differentiated by the server and access to be individually revoked.8.3. Service Autodiscovery
Unless secured by something like DNSSEC, autodiscovery of server details using SRV DNS records is vulnerable to a DNS poisoning attack, which can lead to the client talking to an attacker's server instead of the real JMAP server. The attacker may then intercept requests to execute man-in-the-middle attacks and, depending on the authentication scheme, steal credentials to generate its own requests. Clients that do not support SRV lookups are likely to try just using the "/.well-known/jmap" path directly against the domain of the username over HTTPS. Servers SHOULD ensure this path resolves or redirects to the correct JMAP Session resource to allow this to work. If this is not feasible, servers MUST ensure this path cannot be controlled by an attacker, as again it may be used to steal credentials.
8.4. JSON Parsing
The Security Considerations of [RFC8259] apply to the use of JSON as the data interchange format. As for any serialization format, parsers need to thoroughly check the syntax of the supplied data. JSON uses opening and closing tags for several types and structures, and it is possible that the end of the supplied data will be reached when scanning for a matching closing tag; this is an error condition, and implementations need to stop scanning at the end of the supplied data. JSON also uses a string encoding with some escape sequences to encode special characters within a string. Care is needed when processing these escape sequences to ensure that they are fully formed before the special processing is triggered, with special care taken when the escape sequences appear adjacent to other (non-escaped) special characters or adjacent to the end of data (as in the previous paragraph). If parsing JSON into a non-textual structured data format, implementations may need to allocate storage to hold JSON string elements. Since JSON does not use explicit string lengths, the risk of denial of service due to resource exhaustion is small, but implementations may still wish to place limits on the size of allocations they are willing to make in any given context, to avoid untrusted data causing excessive memory allocation.8.5. Denial of Service
A small request may result in a very large response and require considerable work on the server if resource limits are not enforced. JMAP provides mechanisms for advertising and enforcing a wide variety of limits for mitigating this threat, including limits on the number of objects fetched in a single method call, number of methods in a single request, number of concurrent requests, etc. JMAP servers MUST implement sensible limits to mitigate against resource exhaustion attacks.8.6. Connection to Unknown Push Server
When a push subscription is registered, the application server will make POST requests to the given URL. There are a number of security considerations that MUST be considered when implementing this.
The server MUST ensure the URL is externally resolvable to avoid server-side request forgery, where the server makes a request to a resource on its internal network. A malicious client may use the push subscription to attempt to flood a third party server with requests, creating a denial-of-service attack and masking the attacker's true identity. There is no guarantee that the URL given to the JMAP server is actually a valid push server. Upon creation of a push subscription, the JMAP server sends a PushVerification object to the URL and MUST NOT send any further requests until the client verifies it has received the initial push. The verification code MUST contain sufficient entropy to prevent the client from being able to verify the subscription via brute force. The verification code does not guarantee the URL is a valid push server, only that the client is able to access the data submitted to it. While the verification step significantly reduces the set of potential targets, there is still a risk that the server is unrelated to the client and being targeted for a denial-of-service attack. The server MUST limit the number of push subscriptions any one user may have to ensure the user cannot cause the server to send a large number of push notifications at once, which could again be used as part of a denial-of-service attack. The rate of creation MUST also be limited to minimise the ability to abuse the verification request as an attack vector.8.7. Push Encryption
When data changes, a small object is pushed with the new state strings for the types that have changed. While the data here is minimal, a passive man-in-the-middle attacker may be able to gain useful information. To ensure confidentiality and integrity, if the push is sent via a third party outside of the control of the client and JMAP server, the client MUST specify encryption keys when establishing the PushSubscription and ignore any push notification received that is not encrypted with those keys. The privacy and security considerations of [RFC8030] and [RFC8291] also apply to the use of the PushSubscription mechanism. As there is no crypto algorithm agility in Web Push Encryption [RFC8291], a new specification will be needed to provide this if new algorithms are required in the future.
8.8. Traffic Analysis
While the data is encrypted, a passive observer with the ability to monitor network traffic may be able to glean information from the timing of API requests and push notifications. For example, suppose an email or calendar invitation is sent from User A (hosted on Server X) to User B (hosted on Server Y). If Server X hosts data for many users, a passive observer can see that the two servers connected but does not know who the data was for. However, if a push notification is immediately sent to User B and the attacker can observe this as well, they may reasonably conclude that someone on Server X is connecting to User B.9. IANA Considerations
9.1. Assignment of jmap Service Name
IANA has assigned the 'jmap' service name in the "Service Name and Transport Protocol Port Number Registry" [RFC6335]. Service Name: jmap Transport Protocol(s): tcp Assignee: IESG Contact: IETF Chair Description: JSON Meta Application Protocol Reference: RFC 8620 Assignment Notes: This service name was previously assigned under the name "JSON Mail Access Protocol". This has been de-assigned and re-assigned with the approval of the previous assignee.9.2. Registration of Well-Known URI Suffix for JMAP
IANA has registered the following suffix in the "Well-Known URIs" registry for JMAP, as described in [RFC8615]: URI Suffix: jmap Change Controller: IETF Specification Document: RFC 8620, Section 2.2.
9.3. Registration of the jmap URN Sub-namespace
IANA has registered the following URN sub-namespace in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry within the "Uniform Resource Name (URN) Namespace for IETF Use" registry as described in [RFC3553]. Registered Parameter Identifier: jmap Reference: RFC 8620, Section 9.4 IANA Registry Reference: http://www.iana.org/assignments/jmap9.4. Creation of "JMAP Capabilities" Registry
IANA has created the "JMAP Capabilities" registry as described in Section 2. JMAP capabilities are advertised in the "capabilities" property of the JMAP Session resource. They are used to extend the functionality of a JMAP server. A capability is referenced by a URI. The JMAP capability URI can be a URN starting with "urn:ietf:params:jmap:" plus a unique suffix that is the index value in the jmap URN sub-namespace. Registration of a JMAP capability with another form of URI has no impact on the jmap URN sub-namespace. This registry follows the expert review process unless the "intended use" field is "common" or "placeholder", in which case registration follows the specification required process. A JMAP capability registration can have an intended use of "common", "placeholder", "limited", or "obsolete". IANA will list common-use registrations prominently and separately from those with other intended use values. The JMAP capability registration procedure is not a formal standards process but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay. A "placeholder" registration reserves part of the jmap URN namespace for another purpose but is typically not included in the "capabilities" property of the JMAP Session resource.9.4.1. Preliminary Community Review
Notice of a potential JMAP common-use registration SHOULD be sent to the JMAP mailing list <jmap@ietf.org> for review. This mailing list is appropriate to solicit community feedback on a proposed JMAP
capability. Registrations that are not intended for common use MAY be sent to the list for review as well; doing so is entirely OPTIONAL, but is encouraged. The intent of the public posting to this list is to solicit comments and feedback on the choice of the capability name, the unambiguity of the specification document, and a review of any interoperability or security considerations. The submitter may submit a revised registration proposal or abandon the registration completely at any time.9.4.2. Submit Request to IANA
Registration requests can be sent to <iana@iana.org>.9.4.3. Designated Expert Review
For a limited-use registration, the primary concern of the designated expert (DE) is preventing name collisions and encouraging the submitter to document security and privacy considerations; a published specification is not required. For a common-use registration, the DE is expected to confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available. The DE should also verify that the capability does not conflict with work that is active or already published within the IETF. Before a period of 30 days has passed, the DE will either approve or deny the registration request and publish a notice of the decision to the JMAP WG mailing list or its successor, as well as inform IANA. A denial notice must be justified by an explanation, and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided. If the DE does not respond within 30 days, the registrant may request the IESG take action to process the request in a timely manner.9.4.4. Change Procedures
Once a JMAP capability has been published by the IANA, the change controller may request a change to its definition. The same procedure that would be appropriate for the original registration request is used to process a change request. JMAP capability registrations may not be deleted; capabilities that are no longer believed appropriate for use can be declared obsolete by a change to their "intended use" field; such capabilities will be clearly marked in the lists published by the IANA.
Significant changes to a capability's definition should be requested only when there are serious omissions or errors in the published specification. When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition. The owner of a JMAP capability may pass responsibility to another person or agency by informing the IANA; this can be done without discussion or review. The IESG may reassign responsibility for a JMAP capability. The most common case of this will be to enable changes to be made to capabilities where the author of the registration has died, moved out of contact, or is otherwise unable to make changes that are important to the community.9.4.5. JMAP Capabilities Registry Template
Capability name: (see capability property in Section 2) Specification document: Intended use: (one of common, limited, placeholder, or obsolete) Change controller: ("IETF" for Standards Track / BCP RFCs) Security and privacy considerations:9.4.6. Initial Registration for JMAP Core
Capability Name: "urn:ietf:params:jmap:core" Specification document: RFC 8620, Section 2 Intended use: common Change Controller: IETF Security and privacy considerations: RFC 8620, Section 8.
9.4.7. Registration for JMAP Error Placeholder in JMAP Capabilities Registry
Capability Name: "urn:ietf:params:jmap:error:" Specification document: RFC 8620, Section 9.5 Intended use: placeholder Change Controller: IETF Security and privacy considerations: RFC 8620, Section 8.9.5. Creation of "JMAP Error Codes" Registry
IANA has created the "JMAP Error Codes" registry. JMAP error codes appear in the "type" member of a JSON problem details object (as described in Section 3.6.1), the "type" member in a JMAP error object (as described in Section 3.6.2), or the "type" member of a JMAP method-specific error object (such as SetError in Section 5.3). When used in a problem details object, the prefix "urn:ietf:params:jmap:error:" is always included; when used in JMAP objects, the prefix is always omitted. This registry follows the expert review process. Preliminary community review for this registry follows the same procedures as the "JMAP Capabilities" registry, but it is optional. The change procedures for this registry are the same as the change procedures for the "JMAP Capabilities" registry.9.5.1. Expert Review
The designated expert should review the following aspects of the registration: 1. Verify the error code does not conflict with existing names. 2. Verify the error code follows the syntax limitations (does not require URI encoding). 3. Encourage the submitter to follow the naming convention of previously registered errors. 4. Encourage the submitter to describe client behaviours that are recommended in response to the error code. These may distinguish the error code from other error codes.
5. Encourage the submitter to describe when the server should issue
the error as opposed to some other error code.
6. Encourage the submitter to note any security considerations
associated with the error, if any (e.g., an error code that might
disclose existence of data the authenticated user does not have
permission to know about).
Steps 3-6 are meant to promote a higher-quality registry. However,
the expert is encouraged to approve any registration that would not
actively harm JMAP interoperability to make this a relatively
lightweight process.
9.5.2. JMAP Error Codes Registry Template
JMAP Error Code:
Intended use: (one of "common", "limited", "obsolete")
Change Controller: ("IETF" for Standards Track / BCP RFCs)
Reference: (Optional. Only required if defined in an RFC.)
Description:
9.5.3. Initial Contents for the JMAP Error Codes Registry
o JMAP Error Code: accountNotFound
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: The accountId does not correspond to a valid account.
o JMAP Error Code: accountNotSupportedByMethod
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: The accountId given corresponds to a valid account,
but the account does not support this method or data type.
o JMAP Error Code: accountReadOnly
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: This method modifies state, but the account is read-
only (as returned on the corresponding Account object in the JMAP
Session resource).
o JMAP Error Code: anchorNotFound
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.5
Description: An anchor argument was supplied, but it cannot be
found in the results of the query.
o JMAP Error Code: alreadyExists
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.4
Description: The server forbids duplicates, and the record already
exists in the target account. An existingId property of type Id
MUST be included on the SetError object with the id of the
existing record.
o JMAP Error Code: cannotCalculateChanges
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Sections 5.2 and 5.6
Description: The server cannot calculate the changes from the
state string given by the client.
o JMAP Error Code: forbidden
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Sections 3.6.2, 5.3, and 7.2.1
Description: The action would violate an ACL or other permissions
policy.
o JMAP Error Code: fromAccountNotFound
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Sections 5.4 and 6.3
Description: The fromAccountId does not correspond to a valid
account.
o JMAP Error Code: fromAccountNotSupportedByMethod
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.4
Description: The fromAccountId given corresponds to a valid
account, but the account does not support this data type.
o JMAP Error Code: invalidArguments
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: One of the arguments is of the wrong type or
otherwise invalid, or a required argument is missing.
o JMAP Error Code: invalidPatch
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: The PatchObject given to update the record was not a
valid patch.
o JMAP Error Code: invalidProperties
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: The record given is invalid.
o JMAP Error Code: notFound
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: The id given cannot be found.
o JMAP Error Code: notJSON
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.1
Description: The content type of the request was not application/
json, or the request did not parse as I-JSON.
o JMAP Error Code: notRequest
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.1
Description: The request parsed as JSON but did not match the type
signature of the Request object.
o JMAP Error Code: overQuota
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: The create would exceed a server-defined limit on the
number or total size of objects of this type.
o JMAP Error Code: rateLimit
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: Too many objects of this type have been created
recently, and a server-defined rate limit has been reached. It
may work if tried again later.
o JMAP Error Code: requestTooLarge
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Sections 5.1 and 5.3
Description: The total number of actions exceeds the maximum
number the server is willing to process in a single method call.
o JMAP Error Code: invalidResultReference
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: The method used a result reference for one of its
arguments, but this failed to resolve.
o JMAP Error Code: serverFail
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: An unexpected or unknown error occurred during the
processing of the call. The method call made no changes to the
server's state.
o JMAP Error Code: serverPartialFail
Intended Use: Limited
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: Some, but not all, expected changes described by the
method occurred. The client MUST resynchronise impacted data to
determine the server state. Use of this error is strongly
discouraged.
o JMAP Error Code: serverUnavailable
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: Some internal server resource was temporarily
unavailable. Attempting the same operation later (perhaps after a
backoff with a random factor) may succeed.
o JMAP Error Code: singleton
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: This is a singleton type, so you cannot create
another one or destroy the existing one.
o JMAP Error Code: stateMismatch
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: An ifInState argument was supplied, and it does not
match the current state.
o JMAP Error Code: tooLarge
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: The action would result in an object that exceeds a
server-defined limit for the maximum size of a single object of
this type.
o JMAP Error Code: tooManyChanges
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.6
Description: There are more changes than the client's maxChanges
argument.
o JMAP Error Code: unknownCapability
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.1
Description: The client included a capability in the "using"
property of the request that the server does not support.
o JMAP Error Code: unknownMethod
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 3.6.2
Description: The server does not recognise this method name.
o JMAP Error Code: unsupportedFilter
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.5
Description: The filter is syntactically valid, but the server
cannot process it.
o JMAP Error Code: unsupportedSort
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.5
Description: The sort is syntactically valid but includes a
property the server does not support sorting on or a collation
method it does not recognise.
o JMAP Error Code: willDestroy
Intended Use: Common
Change Controller: IETF
Reference: RFC 8620, Section 5.3
Description: The client requested an object be both updated and
destroyed in the same /set request, and the server has decided to
therefore ignore the update.
10. References
10.1. Normative References
[EventSource]
Hickson, I., "Server-Sent Events", World Wide Web
Consortium Recommendation REC-eventsource-20150203,
February 2015, <https://www.w3.org/TR/eventsource/>.
[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/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>. [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, DOI 10.17487/RFC4790, March 2007, <https://www.rfc-editor.org/info/rfc4790>. [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, DOI 10.17487/RFC5051, October 2007, <https://www.rfc-editor.org/info/rfc5051>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>. [RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <https://www.rfc-editor.org/info/rfc6186>. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>. [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>. [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, <https://www.rfc-editor.org/info/rfc6764>. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>. [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/info/rfc6901>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>. [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>. [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>. [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <https://www.rfc-editor.org/info/rfc7807>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>. [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/info/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/info/rfc8174>. [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>. [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/info/rfc8264>. [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, DOI 10.17487/RFC8291, November 2017, <https://www.rfc-editor.org/info/rfc8291>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.10.2. Informative References
[RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, DOI 10.17487/RFC8246, September 2017, <https://www.rfc-editor.org/info/rfc8246>.
Authors' Addresses
Neil Jenkins Fastmail PO Box 234, Collins St. West Melbourne, VIC 8007 Australia Email: neilj@fastmailteam.com URI: https://www.fastmail.com Chris Newman Oracle 440 E. Huntington Dr., Suite 400 Arcadia, CA 91006 United States of America Email: chris.newman@oracle.com