Network Working Group B. Gondwana Internet-Draft Fastmail Updates: 8620 (if approved) 21 February 2026 Intended status: Standards Track Expires: 25 August 2026 JMAP Blob Extensions draft-gondwana-jmap-blobext-00 Abstract 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. 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 25 August 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Gondwana Expires 25 August 2026 [Page 1] Internet-Draft JMAP Blob Extended February 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Addition to the Capabilities Object . . . . . . . . . . . . . 2 2.1. urn:ietf:params:jmap:blobext . . . . . . . . . . . . . . 3 2.1.1. Capability Example . . . . . . . . . . . . . . . . . 3 2.2. Additions to Blob/get . . . . . . . . . . . . . . . . . . 3 2.3. Additions to DataSourceObject . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4.1. JMAP Capability Registration for urn:ietf:params:jmap:blobext . . . . . . . . . . . . . . 5 5. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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. 2. Addition to the Capabilities Object The capabilities object is returned as part of the JMAP Session object; see [JMAP-CORE], Section 2. This document defines an additional capability URI. Gondwana Expires 25 August 2026 [Page 2] Internet-Draft JMAP Blob Extended February 2026 2.1. urn:ietf:params:jmap:blobext 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. 2.1.1. Capability Example TODO 2.2. Additions to Blob/get Blob/get returns an additional parameter (returned by default when this capability is included in using) * chunks: Array[DataSourceObject] Gondwana Expires 25 August 2026 [Page 3] Internet-Draft JMAP Blob Extended February 2026 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. 2.3. Additions to DataSourceObject 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? Gondwana Expires 25 August 2026 [Page 4] Internet-Draft JMAP Blob Extended February 2026 3. Security Considerations 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. 4. IANA Considerations 4.1. JMAP Capability Registration for urn:ietf:params:jmap:blobext IANA is requested to register the "Blob Extended" Capability as follows Capability: urn:ietf:params:jmap:filenode Reference: this document 5. TODO * Look into ZIP files, compression, etc. 6. Changes 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 7. Acknowledgements TODO {backmatter} 8. Normative References Gondwana Expires 25 August 2026 [Page 5] Internet-Draft JMAP Blob Extended February 2026 [HTTP-RESUMABLE-UPLOADS] Kleidl, M., Zhang, G., and L. Pardue, "Resumable Uploads for HTTP", Work in Progress, Internet-Draft, draft-ietf- httpbis-resumable-upload-10, 20 October 2025, . [JMAP-BLOB] Gondwana, B., Ed., "JSON Meta Application Protocol (JMAP) Blob Management Extension", RFC 9404, DOI 10.17487/RFC9404, August 2023, . [JMAP-CORE] Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, . [URI-TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . Author's Address Bron Gondwana Fastmail Email: brong@fastmailteam.com Gondwana Expires 25 August 2026 [Page 6]