JSON Meta Application Protocol
draft-ietf-jmap-core-08
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8620.
|
|
|---|---|---|---|
| Authors | Neil Jenkins , Chris Newman | ||
| Last updated | 2018-09-11 (Latest revision 2018-09-10) | ||
| Replaces | draft-jenkins-jmap | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8620 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-jmap-core-08
Jenkins & Newman Expires March 14, 2019 [Page 61] Internet-Draft JMAP September 2018 where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided. 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, 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: this document, section 2 Jenkins & Newman Expires March 14, 2019 [Page 62] Internet-Draft JMAP September 2018 Intended use: common Change Controller: IETF Security and privacy considerations: this document, section 8. 9.4.7. Registration for JMAP error placeholder in JMAP capabilities registry Capability Name: `urn:ietf:params:jmap:error:' Specification document: this document, next section. Intended use: placeholder Change Controller: IETF Security and privacy considerations: this document, section 8. 9.5. Creation of "JMAP Error Codes" registry IANA will create a registry for JMAP error codes. JMAP error codes appear in the "type" member of a JSON problem details object (as described in section 3.5.1), in the "type" member in a JMAP error object (as described in section 3.5.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, and 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 is optional. The change procedures for this registry are the same as the change procedures for the JMAP capabilities registry. 9.5.1. Designated 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 error code to follow the naming convention of previously registered errors. Jenkins & Newman Expires March 14, 2019 [Page 63] Internet-Draft JMAP September 2018 4. Encourage description of client behaviors that are recommended in response to the error code. These may distinguish the error code from other error codes. 5. Encourage description of 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. For example, 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 light- weight 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) Description or Reference: 9.5.3. Initial JMAP Error Codes registry +------------------------------+---------+------------+-------------+ | JMAP Error Code | Intende | Change | Description | | | d Use | Controller | or | | | | | Reference | +------------------------------+---------+------------+-------------+ | accountNotFound | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | accountNotSupportedByMethod | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | accountReadOnly | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | anchorNotFound | common | IETF | RFC XXXX | | | | | section 5.5 | | alreadyExists | common | IETF | RFC XXXX | | | | | section 5.4 | | cannotCalculateChanges | common | IETF | RFC XXXX | Jenkins & Newman Expires March 14, 2019 [Page 64] Internet-Draft JMAP September 2018 | | | | sections | | | | | 5.2 and 5.6 | | forbidden | common | IETF | RFC XXXX | | | | | sections | | | | | 3.5.2, 5.3, | | | | | and 7.2.1 | | fromAccountNotFound | common | IETF | RFC XXXX | | | | | sections | | | | | 5.4 and 6.3 | | fromAccountNotSupportedByMet | common | IETF | RFC XXXX | | hod | | | section 5.4 | | invalidArguments | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | invalidPatch | common | IETF | RFC XXXX | | | | | section 5.3 | | invalidProperties | common | IETF | RFC XXXX | | | | | section 5.3 | | notFound | common | IETF | RFC XXXX | | | | | section 5.3 | | notJSON | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.1 | | notRequest | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.1 | | overQuota | common | IETF | RFC XXXX | | | | | section 5.3 | | rateLimit | common | IETF | RFC XXXX | | | | | section 5.3 | | requestTooLarge | common | IETF | RFC XXXX | | | | | sections | | | | | 5.1 and 5.3 | | invalidResultReference | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | serverFail | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | serverPartialFail | limited | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | serverUnavailable | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | singleton | common | IETF | RFC XXXX | | | | | section 5.3 | | stateMismatch | common | IETF | RFC XXXX | Jenkins & Newman Expires March 14, 2019 [Page 65] Internet-Draft JMAP September 2018 | | | | section 5.3 | | toAccountNotFound | common | IETF | RFC XXXX | | | | | sections | | | | | 5.4 and 6.3 | | toAccountNotSupportedByMetho | common | IETF | RFC XXXX | | d | | | section 5.4 | | tooLarge | common | IETF | RFC XXXX | | | | | section 5.3 | | tooManyChanges | common | IETF | RFC XXXX | | | | | section 5.6 | | unknownCapability | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.1 | | unknownMethod | common | IETF | RFC XXXX | | | | | section | | | | | 3.5.2 | | unsupportedFilter | common | IETF | RFC XXXX | | | | | section 5.5 | | unsupportedSort | common | IETF | RFC XXXX | | | | | section 5.5 | | willDestroy | common | IETF | RFC XXXX | | | | | section 5.3 | +------------------------------+---------+------------+-------------+ 10. References 10.1. Normative References [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>. [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>. Jenkins & Newman Expires March 14, 2019 [Page 66] Internet-Draft JMAP September 2018 [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>. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>. [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>. Jenkins & Newman Expires March 14, 2019 [Page 67] Internet-Draft JMAP September 2018 [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>. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <https://www.rfc-editor.org/info/rfc7159>. [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>. [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>. [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>. [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>. Jenkins & Newman Expires March 14, 2019 [Page 68] Internet-Draft JMAP September 2018 [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>. [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, DOI 10.17487/RFC8291, November 2017, <https://www.rfc-editor.org/info/rfc8291>. 10.2. URIs [1] https://html.spec.whatwg.org/multipage/server-sent-events.html 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 Jenkins & Newman Expires March 14, 2019 [Page 69]