audriga

Alter Schlachthof 57 Karlsruhe 76137 Germany joris@audriga.com https://www.audriga.com

audriga

Alter Schlachthof 57 Karlsruhe 76137 Germany hans-joerg@audriga.com https://www.audriga.com

Applications JMAP jmap data portability migration 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.

Introduction JMAP 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.

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

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

• A single user login is tied to a single user account (this is then also the primary account).
• This implies that shared data shall not be exposed over the API. The API will only provide access to data owned by the current user.
• Each user has the same set of capabilities and restrictions (e.g. maxMailboxesPerEmail).
• apiUrl, downloadUrl, uploadUrl and eventSourceUrl are the same for ever user.

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.

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.

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.

Binary Data The advanced Blob/copy method call is not essential.

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.

• apiUrlSimple: String The URL to use for JMAP API requests. THE URL MUST contain accountId and methodCall. One MAY use ids.

Addition to the capabilities object The capabilities object is returned as part of the JMAP Session object; see , Section 2. This document defines one additional capability URI.

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.

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

Security considerations All security considerations of JMAP apply to this specification.

IANA considerations

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

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

Normative References

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:

• Export use cases: Minimal implementation for exporting data from an application server
• Import use cases: Minimal implementation for importing data into an application server

The last column lists more advanced features of JMAP Core recommended for data portability use cases. 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

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

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)	-	-

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

• 1: Can be modeled as a static JSON file for a lot of scenarios. Section 3 details for which use cases a static JSON file should be sufficient.
• 2: Some data types require using ids in /get .
• 3: maxObjectsInGet might not be sufficiently high in some products. Then /query and paging is required.
• 4: Some data types allow having attachments as base64 enconded strings inside a JMAP object. In those cases it is not necessary to implement a download or upload endpoint.

JMAP Debug extension

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.

Addition to the Capabilities Object The capabilities object is returned as part of the JMAP Session object; see , Section 2. This document defines one additional capability URI.

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.

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", ...

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.

Backend Info

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.

Addition to the capabilities object The capabilities object is returned as part of the JMAP Session object; see , Section 2. This document defines one additional capability URI.

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" } } } }, ... } }

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.

Addition to the capabilities object This document would then define one more additional capability URI.

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.

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}/" }

IANA Considerations

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