Internet-Draft JMAP Portability March 2023
Baum & Happel Expires 8 September 2023 [Page]
Workgroup:
JMAP
Internet-Draft:
draft-baum-jmap-portability-00
Published:
Intended Status:
Informational
Expires:
Authors:
J.M. Baum, Ed.
audriga
H.J. Happel, Ed.
audriga

JMAP for Migration and Data Portability

Abstract

The JMAP base protocol (RFC8620) is a generic, efficient, mobile friendly and scalable protocol that can be used for data of any type. This makes it a good fit for migrations or data portability use cases. However, due to its large set of features, it is also quite complex, which makes it difficult to explore new application domains in practice. The goal of this document is to provide a simplified version of JMAP for more rapid development.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 8 September 2023.

Table of Contents

1. Introduction

JMAP [RFC8620] is designed to be a generic, efficient, mobile friendly and scalable protocol. This comes with the cost of high complexity, even though this is necessary to meet JMAP's design goals.

Migration and data portability is about moving arbitrary user data between services. JMAP is a particularly good fit for meeting basic data portability requirements. It can be used as an open protocol in front of an application service, exposing data of any kind. However, implementing JMAP correctly can be complicated, which makes it difficult to explore new application domains in practice.

For basic data portability requirements, users need to be able to export their data from a product or import it into a product in real time. Providers that want to support JMAP for their service to meet data portability requirements are likely to not want to implement the full feature set that JMAP Core currently defines. Currently, there is no clear guidance on which parts of the JMAP specification are essential to migration and data portablity use cases.

This specification aims to provide guidance to identify essential parts of the JMAP spec for more rapid development. For the sole purpose of providing very basic data portability, there is no need to implement all parts of the JMAP protocol. In a second iteration developers could then extend upon this basic version of JMAP. It also defines a simplified version of the JMAP Request that has even less requirements.

2. Conventions Used In This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The definitions of JSON keys and datatypes in the document follow the conventions described in the core JMAP specification [RFC8620].

3. Session Resource

For a lot of basic portability use of cases for existing application services the following constraints are typically acceptable:

For use cases adhering to those restrictions, the session resource can be modeled as a simple static JSON file without the username property. The accountId is then the same as the username.

4. Structured Data exchange

While batching improves performance considerably, it imposes additional implementation effort on developers. It is not essential for portability and can be left out.

5. Standard Methods and Naming Convention

JMAP core defines 6 standard methods, which are then reused in most JMAP extensions. Not all JMAP Methods are required to provide essential portability. For some use-cases where the data is expected to be small, /set and /get should be enough. In case a large amount of data shall be supported, paging can be achieved via the /query method. Note that some specifications require specific IDs for /set .

/changes, /copy as well as /queryChanges are not required as all data can already be retrieved and set with above's three methods.

6. Binary Data

The advanced Blob/copy method call is not essential.

7. Simplified REST-like JMAP API

Structured data exchange over JMAP usually involves processing JMAP Request JSON payloads. This might impose unnecessary requirements for certain use cases of JMAP. Likely scenarios in which this is beneficiary are situations in which portability needs to be provided due to regulatory requirements or when migrating user data away from legacy platforms.

For rapid development of a JMAP API without support for batching, the essential properties of the Request object can instead be implemented as URI with query parameters.

7.1. 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.

7.1.1. urn:ietf:params:jmap:core-simple

The capability urn:ietf:params:jmap:core-simple being present in the "capabilities" property represents support for the simplified JMAP API.

The value of this property in the JMAP Session capabilities property and the account’s accountCapabilities property is an empty object.

7.1.2. Capability Example

{
  ...
  "capabilities": {
    ...,
    "urn:ietf:params:jmap:core-simple": {}
  },
  "apiUrlSimple": "https://jmap.me/api
    /?accountId=<account-id>&methodCall=<methodCall>&ids=<ids>"
}

8. Security considerations

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

9. IANA considerations

9.1. JMAP Capability registration for "core-simple"

IANA is requested to register the "core-simple" JMAP Capability as follows:

Capability Name: urn:ietf:params:jmap:core-simple

Specification document: this document

Intended use: common

Change Controller: IETF

Security and privacy considerations: this document, Section XXX

10. Acknowledgements

Bron Gondwana, Neil Jenkins, Alexey Melnikov, Ken Murchison, Robert Stepanek and the JMAP working group at the IETF.

11. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8620]
Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, , <https://www.rfc-editor.org/info/rfc8620>.

Appendix A. Required features for JMAP Portability

Not all features of JMAP Core are required for basic data portability use cases. Tables 1-4 list the required features for a minimal implementation of JMAP for Migration and Portability in more detail. It distinguishes between two common scenarios:

The last column lists more advanced features of JMAP Core recommended for data portability use cases.

Table 1: Session Object features essential for Migration and Portability use cases
JMAP Core Feature JMAP Portability export use cases JMAP Portability import use cases JMAP Portability advanced features
Session Object (static file) (yes)1 (yes)1
Session Object (full) some use cases1 some use cases1
Service Autodiscovery - - good for simple connection
Table 2: Structured Data Exchange features essential for Migration and Portability use cases
JMAP Core Feature JMAP Portability export use cases JMAP Portability import use cases JMAP Portability advanced features
Invocation (all properties) yes yes
Request (using) - -
Request (methodCalls, no batching) yes yes
Request (methodCalls, with batching) - -
Request (createdIds) - -
Response (methodResponses) yes yes
Response (createdIds) - -
Response (sessionState) - -
Errors - - good for debugging
References to Previous Method Results - -
Localisation of User-Visible String - -
Table 3: Method features essential for Migration and Portability
JMAP Core Feature JMAP Portability export use cases JMAP Portability import use cases JMAP Portability advanced features
Core/echo - - good for connection testing
/get method Request yes -
/get method Request (accountId) some use cases1 -
/get method Request (ids, only single id) for listing or paging2,3 -
/get method Request (ids) for listing or paging2,3 -
/get method Request (properties) - -
/get method Response yes -
/get method Response (accountId) some use cases1 -
/get method Response (state) - -
/get method Response (list) yes -
/get method Response (notFound) yes -
/changes method (full) - -
/set method Request - yes
/set method Request (accountId) - some use cases1
/set method Request (ifInState) - -
/set method Request (create, only single id) - yes
/set method Request (create, multiple ids) - -
/set method Request (update) - -
/set method Request (destroy) - - good for testing
/set method Response - yes
/set method Response (accountId) - some use cases1
/set method Response (oldState) - -
/set method Response (newState) - -
/set method Response (created) - yes
/set method Response (updated) - -
/set method Response (destroyed) - - good for testing
/set method Response (notCreated) - yes
/set method Response (notUpdated) - -
/set method Response (notDestroyed) - - good for testing
/set method SetError - - good for debugging
/copy method (full) - -
/query method Request for listing or paging2,3 -
/query method Request (accountId) some use cases1 -
/query method Request (filter) - - good for listing objects of a specific kind
/query method Request (sort) - -
/query method Request (position) for paging3 -
/query method Request (anchor) - -
/query method Request (anchorOffset) - -
/query method Request (limit) - -
/query method Request (calculateTotal) for paging3 -
/query method Response for listing or paging2,3 -
/query method Response (accountId) some use cases1 -
/query method Response (queryState) - - -
/query method Response (canCalculateChanges) - - -
/query method Response (position) for paging3 - -
/query method Response (ids) for listing or paging2,3 - -
/query method Response (total) for paging2,3 - -
/query method Response (limit) - - -
/query method FilterCondition - - good for listing objects of a specific kind
/query method FilterOperator - - -
/query method Comparator - - -
/queryChanges method (full) - -
Table 4: Blob and Push features essential for Migration and Portability
JMAP Core Feature JMAP Portability export use cases JMAP Portability import use cases JMAP Portability advanced features
Uploading Binary Data - for importing attachments4
Downloading Binary Data for exporting attachments4 -
Blob/copy (full) - -
Push - -

Appendix B. JMAP Debug extension

B.1. Introduction

Data exchanges between JMAP clients and server typically produces log lines from both the client and the server. Usually, logs are either stored locally on the instances or sent to a dedicated logging server. However, JMAP can also be used to supply log messages along-side the usual data exchange. This also removes the need to operate a separate logging infrastructure or have dedicated channels for log messages.

This extension adds a logs property to the JMAP method response (defined in RFC8620 Section 3.4) which contains the log lines of the JMAP server.

An example use case would be a JMAP API software running on a third-party infrastructure in which log messages from the API cannot be sent to a dedicated logging service. Access to the third-party infrastructure is restrictive in the sense that there is only access to the JMAP API endpoint.

B.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.

B.2.1. urn:ietf:params:jmap:debug

Represents support for the logs property in the JMAP method response (defined in RFC8620 Section 3.4) and the LogLine data type.

The value of this property in the JMAP Session and account's capabilities property is an empty object.

B.3. Response extension

The Response object will be extended via:

  • logs: LogLine[] (optional) An array of log lines for the sent request.

A LogLine object has the following properties:

  • level: String The log level of the log message. Must be one of the eight levels defined in RFC5424: debug, info, notice, warning, error, critical, alert or emergency.
  • message: String The log message
  • timestamp: UTCDate The date the log message was logged.
  • class: String|null The name of the class that is currently logging.
  • file: String|null The file that initiated the log line.
  • line: String|null The exact line in the file where the log function is being called.

An example list of logs sent alongside a response to Core/echo would look like:

{
  "logs" : [
    {
      "file" : "Logger.php",
      "level" : "info",
      "line" : 32,
      "message" : "Array Logger has been successfully initialized",
      "timestamp" : "2022-01-18T10:26:56+01:00"
    },
    {
      "file" : "ErrorHandler.php",
      "level" : "warning",
      "line" : 52,
      "message" : "fopen(bridge.php):
        failed to open stream: No such file or directory",
      "timestamp" : "2022-01-18T10:26:56+01:00"
    },
    ...
  ],
  "methodResponses" : [
    [
      "Core/echo",
      ...

B.4. Security Considerations

Log messages might contain sensitive user data as well as detailed information about the system on which an API server has been installed. Appropriate measures must be taken to restrict access to JMAP Debug to privileged parties only.

Appendix C. Backend Info

C.1. Introduction

Every server-side software has its own quirks. For example, the JMAP standard might only have been partially implemented by a server or design decisions might have been taken that let the server deviate from what is actually required by the standard. Servers might also have unintended bugs or have certain restrictions that are not advertised by their list of supported server capabilities.

Interoperable clients that still want to have a successful structured data exchange with such "unique" servers need to handle these quirks with workarounds on the client-side. These clients only want to apply special workarounds in situations where they are truly necessary. This is typically done by identifying which server-side software they are communicating with.

JMAP does not provide a standardized way to retrieve an identifier of the product that is residing on the server side. Due to the lack of standardization clients are left to identify misbehaving servers by error prone means. Examples are checking against a list of known URLs or checking known unique responses typically only sent by certain products. This makes identifying products time-consuming and brittle.

iCalendar and vCard already define a PRODID which property which allows identifying the product that produced the files.

C.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.

C.2.1. urn:ietf:params:jmap:core:backendinfo

This extension defines one additional urn:ietf:params:jmap:core:backendinfo capability that provides details about the product, backend and environment.

  • backend String
  • product String
  • environment String
  • cababilityInfo String[CapabilityInfo] For example, the capability urn:ietf:params:jmap:sieve:backendinfo would provide additional meta data for the JMAP Sieve extension.

JSON snippet:

{
  "capabilities": {
    "urn:ietf:params:jmap:core:backendinfo": {
      "backend": "OpenXPort/Horde v1.0.0",
      "product": "Horde Webmailer v1.0.0",
      "environment": "PHP v5.5",
      "capabilityInfo": {
        "urn:ietf:params:jmap:sieve": {
          "backend": "Cyrus timsieved",
          "product": "Horde Ingo v1.0.0",
          "fileType": "SIEVE/HORDE"
        }
      }
    }
  },
    ...
  }
}

Appendix D. Turning JMAP Portability into a different version of JMAP Core

Because this document contradicts in parts what was stated in JMAP Core (e.g., leave out certain required properties), one might also realize this as a separate protocol that is basically just a subset of JMAP Core. Then we would need to advertise this as a new capability.

D.1. Addition to the capabilities object

This document would then define one more additional capability URI.

D.1.1. urn:ietf:params:jmap:core-essential-portability

The capability urn:ietf:params:jmap:core-essential-portability being present in the "capabilities" property represents support for the essential parts of Core JMAP data types and associated API methods as defined in this document.

The value of this property in the JMAP Session capabilities property and the account’s accountCapabilities property is an empty object.

D.1.2. Capability Example

{
  "capabilities": {
    ...,
    "urn:ietf:params:jmap:core-essential-portability": {}
  },
  "apiUrl": "https://jmap.example.com/api/",
  "downloadUrl": "https://jmap.example.com
    /download/{accountId}/{blobId}/{name}?accept={type}",
  "uploadUrl": "https://jmap.example.com/upload/{accountId}/"
}

D.2. IANA Considerations

D.2.1. JMAP Capability registration for "core-essential-portability"

IANA is requested to register the "core-essential-portability" JMAP Capability as follows:

Capability Name: urn:ietf:params:jmap:core-essential-portability

Specification document: this document

Intended use: common

Change Controller: IETF

Security and privacy considerations: this document, Section XXX

Authors' Addresses

Joris Baum (editor)
audriga
Alter Schlachthof 57
76137 Karlsruhe
Germany
Hans-Joerg (editor)
audriga
Alter Schlachthof 57
76137 Karlsruhe
Germany