| Internet-Draft | JMAP Blob Extended | February 2026 |
| Gondwana | Expires 25 August 2026 | [Page] |
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions.¶
The JMAP blob extension (RFC9404) added additional ways to create and access blobs by making inline method calls within a standard JMAP request.¶
This extension adds more methods to work with blobs, including handling large blobs by processing them in chunks (building on RFC9404's blob construction support), and providing ways to efficiently describe small changes.¶
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 25 August 2026.¶
Copyright (c) 2026 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.¶
The JMAP Blob extension ([JMAP-BLOB] — JSON Blob Management) offers additional ways to create blobs, and query where they are used.¶
This extension builds on that work, offering ways to find more information about the internal structure of the server's blob store in order to work efficiently with it, and ways to efficiently transfer small changes to an existing blob without copying all the data.¶
The capabilities object is returned as part of the JMAP Session object; see [JMAP-CORE], Section 2.¶
This document defines an additional capability URI.¶
The capability urn:ietf:params:jmap:blobext being present in the
"accountCapabilities" property of an account represents support for
these extended properties on that account. If this capability is
present in one or more "accountCapabilities" properties then the
server MUST also include the key in the "capabilities" property.¶
The value of this property in the JMAP session "capabilities" property MUST be an empty object.¶
The value of this property in an account's "accountCapabilities" property is an object that MUST contain the following information on server capabilities and permissions for that account:¶
resumableUploadUrl: "String|null"¶
If present, a [URI-TEMPLATE] which supports [HTTP-RESUMABLE-UPLOADS]. This MAY be the same as the uploadUrl, and has the same keys.¶
chunkSize: "UnsignedInt|null"¶
The size in octets which the server users to split large files into chunks. If a client uploads blobs with exactly this size except for the final chunk, and uses Blob/upload with data blobs containing these chunks, it is expected that the server can optimise these chunks. Servers MUST allow other sizes for the individual data blocks in Blob/upload though, and will then choose whether to store them as an array of blobs still, or to combine them.¶
Blob/get returns an additional parameter (returned by default when this capability
is included in using)¶
chunks: Array[DataSourceObject]¶
An array of one or more data source objects. The file is created by concatenating the DataSourceObjects in the listed order. While it is expected that DataSourceObjects will include the entire blob and offset, it is legal for the server to give offset and length values which do not cover the entire blob in the same way that Blob/upload can, and client MUST use the length and offset to figure out what to append to the resulting file.¶
rdiffSignature: blobId¶
Returns a blobId which can be fetched to download the rdiff signature of the blobId being fetched.¶
All DataSourceObjects (including data: objects) can have an offset and length to trim the
final values, though it's just a waste of data when applied to data: objects. This allows
client and server code to be more consistent for all types.¶
Every DataSourceObject (on both upload and get) is extended to include any supported digest which is requested, so a client could request 'digest:sha' and every DataSourceObject would include the 'digest:sha' as well as the top level, allowing each blob to be separately validated.¶
There is a new parameter to each DataSourceObject¶
rdiffPatch: blobId¶
If provided, apply the patch in the given blobId to the result of this DataSourceObject AFTER applying any length and offset. If a digest value is given, the digest is calculated on the resulting octets AFTER applying the patch. The sequence is:¶
1) decode any base64 or fetch any blob 2) apply and offset or length to find the raw octets 3) apply any rdiffPatch to get new raw octets 4) check any supported digest: value that was provided to ensure the result matches¶
NOTE: do we want to add any ability to create zip/tar files out of multiple blobs here?¶
Other than the security considerations present in [JMAP-CORE] and [JMAP-BLOB], this document adds the security considerations around ridff handling, including server load and denial of service risks, and any ability to smuggle content through security scanners by splitting it into multiple parts is exacerbated by the ability to split things into parts and use rdiff patches.¶
IANA is requested to register the "Blob Extended" Capability as follows¶
Capability: urn:ietf:params:jmap:filenode¶
Reference: this document¶
EDITOR: please remove this section before publication.¶
The source of this document exists on github at: https://github.com/brong/draft-gondwana-jmap-blobext/¶
draft-gondwana-jmap-blobext-00¶
initial proposal¶
TODO¶
{backmatter}¶