JMAP File Storage extension

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 1 May 2027.¶

Copyright Notice

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

Table of Contents

1. Introduction

JMAP ([JMAP-CORE] — JSON Meta Application Protocol) is a generic protocol for synchronizing data between a client and a server. It is optimized for mobile and web environments, and aims to provide a consistent interface to different data types.¶

In the same way that JMAP Calendars ([JMAP-CALENDARS]) replaces CalDAV ([CALDAV]) and JMAP Contacts ([JMAP-CONTACTS]) replaces CardDAV ([CARDDAV]), this document replaces the use of WebDAV ([WEBDAV]) for remote filesystem access.¶

2. Addition to the Capabilities Object

The capabilities object is returned as part of the JMAP Session object; see Section 2 of [JMAP-CORE].¶

This document defines an additional capability URI.¶

{
  "urn:ietf:params:jmap:filenode": {
    "maxFileNodeDepth": 50,
    "maxSizeFileNodeName": 255,
    "fileNodeQuerySortOptions": [
      "name", "mediaType", "size", "created", "modified",
      "nodeType", "tree"
    ],
    "supportedNodeTypes": ["Directory", "File", "SymLink"],
    "forbiddenNameChars": "/<>:\"\\|?*",
    "caseInsensitiveNames": false,
    "mayCreateTopLevelFileNode": false,
    "webTrashUrl": "https://files.example.com/trash",
    "webUrlTemplate": "https://files.example.com/view/{id}",
    "webWriteUrlTemplate": "https://files.example.com/write/{id}"
  }
}

3. FileNode Data Type

A FileNode is a set of metadata which behaves similarly to an inode in a filesystem. In [WEBDAV] terminology a Directory corresponds to a collection and a File to a resource.¶

The urn:ietf:params:jmap:filenode capability selects the FileNode data type and the methods defined below.¶

[
  {
    "@type": "Directory",
    "id": "n1",
    "parentId": null,
    "name": "Documents",
    "role": "documents"
  },
  {
    "@type": "File",
    "id": "n3",
    "parentId": "n1",
    "name": "report.pdf",
    "blobId": "Bfa61c0",
    "size": 48576,
    "mediaType": "application/pdf",
    "executable": false
  },
  {
    "@type": "SymLink",
    "id": "n7",
    "parentId": null,
    "name": "latest-report",
    "target": ["Documents", "report.pdf"]
  }
]

4. Direct HTTP Write

When the server advertises a webWriteUrlTemplate, clients can update the content of a File directly via HTTP without using FileNode/set. The URL is constructed by expanding the template with the FileNode id. This is only valid for nodes with @type "File"; requests targeting any other type of node MUST be rejected with 400 (Bad Request). A request for a node that does not exist, or that the user cannot discover, MUST be rejected with 404 (Not Found).¶

The user MUST have mayModifyContent on the node, which for a File is in its parent's myRights (see "Access Control"). Requests without it MUST be rejected with 403 (Forbidden). Authentication uses the same mechanism as other JMAP HTTP endpoints.¶

{
  "blobId": "Bnewblob123",
  "size": 48576,
  "mediaType": "text/plain"
}

{
  "blobId": "Bpatched456",
  "size": 49152,
  "mediaType": "text/plain"
}

{
  "blobId": "Bpatched456",
  "size": 49152,
  "mediaType": "text/plain",
  "digest:sha-256": "lu2dEm1cr1Hg2GqVDXMTGP3sgQfFYyp8XUd2ZTgp5Qc="
}

5. Access Control

Access control lists are set with shareWith, which only nodes whose @type permits children can have. Rights are inherited down the tree: a node's myRights is the union of the rights granted to the user by the shareWith entries on the node and on all its ancestors. Inherited rights are a floor. A shareWith entry on a descendant can grant a user more rights on that subtree, but it cannot take away rights granted higher up.¶

A node whose @type does not permit children has no myRights. The user's rights on it are those in its parent's myRights; mayAddChildren and mayShare do not apply to it. Such a node with a null parentId is discoverable only by the account owner, who has all rights on it.¶

To rename or move a node the server checks mayRename, and to destroy it mayDelete, in the rights of the node itself; for a node with no myRights, these are its parent's rights. Moving a node also requires mayAddChildren on the new parent, or mayCreateTopLevelFileNode to move it to the top level. Without these rights, the operation fails with "forbidden".¶

A Directory with a role cannot be destroyed, renamed or moved; the server rejects any attempt with "forbidden". This does not change the rights it reports in myRights, which its children with no myRights of their own take as theirs: files in a directory with the "trash" role, for example, can still be destroyed.¶

A change to shareWith on a node is a change to every node in its subtree: the server MUST report all of them as changed in FileNode/changes, including nodes that have no myRights of their own and take their rights from their parent. A client therefore learns the new rights of everything below a node whose sharing changed from FileNode/changes alone, without working out which nodes are affected itself.¶

Nodes which are not "discoverable" MUST be reported in notFound if fetched with FileNode/get and MUST NOT be returned in response to FileNode/query. Nodes are discoverable in one of two ways:¶

1. If the node or an ancestor of the node has mayRead true.¶

2. If the node or a descendant of the node has a shareWith entry that grants the user any right.¶

When a node stops being discoverable by the user, for example because a shareWith entry was removed, the server reports it as destroyed in FileNode/changes.¶

A node that is discoverable only through the second rule has mayRead false. It is visible so that the user can use the rights granted on it, and can see the full path to the nodes they have access to. This means that a query with that node as the parent will only return those of its children which are otherwise discoverable through the second discoverability rule.¶

For a node that is discoverable but does not have mayRead, FileNode/get returns the real values of id, @type, name, parentId, myRights, isSubscribed, and shareWith (which follows its own rule for mayShare). It returns null for every other property defined for the node's @type, including created, changed, and role, even where that property's type does not otherwise allow null. A change to a property the user sees as null is not visible to the user, so the server SHOULD NOT report the node as updated in FileNode/changes because of it, but MAY do so if it cannot efficiently determine whether any property visible to the user changed.¶

Such a node can have descendants the user cannot discover. A destroy that would remove any of them, either through onDestroyRemoveChildren or as part of a node replaced through onExists, MUST be rejected with "forbidden", and the server MUST NOT destroy any node in that subtree. Without onDestroyRemoveChildren, destroying such a node while it has children fails with "nodeHasChildren" whether or not the user can discover those children.¶

This leads to a sharee seeing the full path to anything that they have access to, but nothing else.¶

For example, in a Unix home directory layout where Alice has shared her "forBob" directory, Bob might see:¶

/home
  /alice
    /shared
      /forBob
        file1.jpg
        file2.txt
        ...
  /bob
    bobfile.txt
    ...

Alice sees many more files and directories under "/home".¶

Sharing can make large changes to the set of nodes a user can see: when Alice first shared that directory, Bob would have been told of a large number of new nodes in response to a FileNode/changes query. The server might report these as "created" or "updated" — it is not always possible for the server to know whether a node was previously visible to the user.¶

6. Quotas

Servers that support JMAP Quotas ([JMAP-QUOTAS]) SHOULD provide Quota objects with "FileNode" in the types array. Both the octets resource type (total storage used by FileNode blobs) and the count resource type (number of FileNode objects) are applicable.¶

7. Integration with JMAP Blob Extensions

When a server advertises both urn:ietf:params:jmap:filenode and urn:ietf:params:jmap:blob2, the ArchiveEntry object type (defined in [JMAP-BLOBEXT]) is extended with two additional properties:¶

• nodeId: "Id|null"¶

  A FileNode id. When present, the server populates the archive entry from the referenced FileNode's properties. The blobId and name are taken from the FileNode. The FileNode's created and modified timestamps map to the archive entry's time metadata. The user's rights on the FileNode (specifically the mayModifyContent right) and, for a File, the executable property inform the mode field in the archive entry (for example, permissions and executable bit). If the ArchiveEntry also provides explicit values for any of these properties, the explicit values take precedence. Mutually exclusive with providing blobId directly when the FileNode's @type is "File".¶

• recurse: "Boolean" (default: false)¶

  Only valid when the referenced FileNode's @type is "Directory". When true, the server recursively includes all children of the directory in the archive. Each child entry's name is its full path relative to the directory. Directory names MUST include a trailing /.¶

A FileNode with @type "SymLink", whether referenced directly by nodeId or reached by recurse, is added to the archive as an entry with entryType "symlink". The server never follows the symlink. The entry's linkTarget is the elements of the SymLink's target joined with "/". An absolute target, whose first element is the empty string, therefore produces a linkTarget that starts with "/".¶

Some archive formats cannot hold every node type. For example, "application/zip" has no symlink entries. The ArchiveRecipe (defined in [JMAP-BLOBEXT]) is extended with one additional property that controls how the server handles such nodes:¶

• onUnsupportedEntry: "String" (default: "error")¶

  This applies to any node, referenced by nodeId or reached by recurse, that the archive format cannot represent. If "error", the server rejects the Blob/convert creation with an "unsupportedEntry" SetError, and creates no archive. If "skip", the server leaves such nodes out of the archive. Any other value is an "invalidProperties" error.¶

This property applies only to entries that the server builds from FileNodes. An entry that the client gives in full, with an unsupported entryType, is still an "invalidProperties" error as [JMAP-BLOBEXT] requires.¶

If nodeId references a FileNode that the user does not have permission to read, or that does not exist, the server MUST reject the Blob/convert creation with a "notFound" SetError.¶

[["Blob/convert", {
  "accountId": "account1",
  "create": {
    "myarchive": {
      "archive": {
        "type": "application/zip",
        "entries": [{
          "nodeId": "dirabc",
          "name": "/",
          "recurse": true
        }]
      }
    }
  }
}, "R1"]]

[["Blob/convert", {
  "accountId": "account1",
  "create": {
    "selective": {
      "archive": {
        "type": "application/zip",
        "entries": [
          {
            "nodeId": "filenode1",
            "name": "README.txt"
          },
          {
            "nodeId": "dirnode2",
            "name": "docs/",
            "recurse": true
          }
        ]
      }
    }
  }
}, "R1"]]

[["Blob/convert", {
  "accountId": "account1",
  "create": {
    "e1": {
      "extract": {
        "blobId": "Barchive123",
        "type": "application/zip",
        "parentNodeId": "dir456"
      }
    }
  }
}, "R1"]]

[["Blob/convert", {
  "accountId": "account1",
  "created": {
    "e1": {
      "id": "Barchive123",
      "type": "application/zip",
      "size": 104857,
      "entries": [
        {
          "name": "docs/",
          "entryType": "directory",
          "nodeId": "node001"
        },
        {
          "name": "docs/readme.txt",
          "blobId": "Bdd001",
          "entryType": "file",
          "modified": "2026-03-01T12:00:00Z",
          "mode": "0644",
          "nodeId": "node002"
        },
        {
          "name": "docs/logo.png",
          "blobId": "Bdd002",
          "entryType": "file",
          "modified": "2026-02-15T09:30:00Z",
          "mode": "0644",
          "nodeId": "node003"
        }
      ]
    }
  },
  "notCreated": {}
}, "R1"]]

8. Extended Attributes and Named Streams

Operating systems associate named side-channel data with files: POSIX extended attributes (getxattr/setxattr), macOS extended attributes (including Finder tags and the quarantine flag) and resource forks, NTFS and SMB2 alternate data streams, and NFSv4 named attributes. A FileNode carries these using the JMAP Object Metadata extension ([JMAP-METADATA]). A server that supports named attributes on FileNodes lists "FileNode" in the "dataTypes" of its urn:ietf:params:jmap:metadata capability. Clients then read and write the attributes through the "metadata" property, and through the "privateMetadata" property where the server sets supportsPrivate. That extension adds both properties to the FileNode object. They are common properties, available on FileNodes of every @type, because platforms also attach named attributes to directories and symbolic links.¶

{
  "metadata": {
    "xattr": {
      "user.comment": "draft copy",
      "com.apple.FinderInfo": {
        "@type": "Binary",
        "base64": "VEVYVHR0eHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
      }
    }
  }
}

[["FileNode/set", {
  "accountId": "u1",
  "update": {
    "f42": {
      "metadata/xattr/Zone.Identifier":
        "[ZoneTransfer]\r\nZoneId=3\r\n"
    }
  }
}, "0"]]

9. Implementation Considerations

10. Security Considerations

All security considerations from [JMAP-CORE] apply to this document.¶

11. IANA Considerations

12. Changes

EDITOR: please remove this section before publication.¶

The source of this document exists on github at: https://github.com/brong/draft-gondwana-jmap-filenode/¶

draft-ietf-jmap-filenode-19¶

• The query depth argument is counted from the top level of the account (top-level nodes are at depth 0), whatever the filter, and absent or null now means no limit rather than "do not recurse". FileNode/queryChanges takes it too.¶

• Renaming, moving or destroying a node checks mayRename or mayDelete on the node itself, which for a node without myRights are its parent's rights. Moving also needs mayAddChildren on the new parent. A Directory with a role cannot be destroyed, renamed or moved, without changing the rights it reports.¶

• A node that stops being discoverable is reported as destroyed in FileNode/changes.¶

• isSubscribed is per user, and setting it needs no rights beyond discovering the node.¶

• A shareWith change MUST be reported as a change to every node in the subtree, including nodes without myRights, so clients need not work out which nodes it affects.¶

• Removed the forbiddenNodeNames capability: it could not express the names that matter (such as "CON.txt"), clients did not use it, and a server can reject names it cannot store regardless.¶

• Removed the "newest" and "unchanged" values of onExists. "newest" compared client clocks and was easily mistaken for a content precondition. "unchanged" duplicated, and conflicted with, [JMAP-CONDITIONAL]: to replace a node only if it is the one expected, a client destroys it and creates the replacement in one FileNode/set, with an "ifUnchangedBy" precondition on the destroy. [JMAP-CONDITIONAL] is now an informative reference.¶

• Creating or moving a node to the top level without mayCreateTopLevelFileNode fails with "forbidden".¶

• Direct HTTP Write PUT and PATCH set modified to the current server time.¶

• Direct HTTP Write accepts Repr-Digest and Content-Digest [DIGEST-FIELDS] on PUT and PATCH, rejecting a mismatch, and returns digests of the new content requested with Want-Repr-Digest.¶

• Fixed the blob capability name in the ArchiveEntry text to urn:ietf:params:jmap:blob2, matching [JMAP-BLOBEXT].¶

• Renaming or moving a node does not change its modified time; the guidance to update modified now applies to content changes.¶

• A server may store timestamps with less precision than clients send, down to whole seconds, truncating and returning the stored value.¶

• Direct HTTP Write digests use the algorithms listed in the supportedDigestAlgorithms capability of [JMAP-BLOBEXT], and clients use the first one they support.¶

• The "xattr" namespace maps an attribute name directly to its value: a String for UTF-8 text, or a [JMAP-METADATA] Binary value. Removed XattrValue and its "blobId", so attribute values are ordinary metadata and the metadata quota, copy and access rules apply to them. Removed the maxDepth requirement, which was wrong under [JMAP-METADATA]'s depth rules.¶

• Added security considerations for extended attributes that grant privileges and for download markers.¶

• Direct HTTP Write returns 404 for a node that does not exist or is not discoverable, and mayModifyContent for a File is its parent's. The modified definition notes that Direct HTTP Write sets it.¶

• Direct HTTP Write PUT sets mediaType from the type and subtype of Content-Type only, without parameters.¶

• The text query condition matches name and mediaType by substring rather than as a glob.¶

• Added a children column to the "JMAP FileNode Types" registry, and guidance for the Designated Expert of the "JMAP FileNode Roles" registry.¶

• [JMAP-BLOBEXT] and [JMAP-CONDITIONAL] now reference the working group drafts. [JMAP-MAIL], [JMAP-QUOTAS] and [UNICODE] are normative references.¶

• Removed the TODO section, and made editorial fixes throughout: American spelling, error codes and section references written consistently, heading case, and list formatting.¶

draft-ietf-jmap-filenode-18¶

• isSubscribed, myRights, and shareWith are defined only for nodes whose @type permits children. Other nodes take their rights from their parent, so a sharing change no longer marks every descendant File as changed.¶

• shareWith is the access control list on that node only; myRights is the union of the lists on the node and its ancestors, so a descendant cannot narrow inherited rights.¶

• A node with a shareWith entry for the user, or with such a descendant, is discoverable.¶

• Defined which properties FileNode/get returns for a node that is discoverable but not readable, and how FileNode/query filters and sorts treat it; body never matches it.¶

• A destroy that would remove undiscoverable nodes fails with "forbidden".¶

• onExists checks rights before comparing against the existing node; "newest" and "unchanged" also require mayRead.¶

• FileNode/copy returns a destroyed list for nodes replaced through onExists.¶

draft-ietf-jmap-filenode-17¶

• Setting a property with a default to null resets it to that default (as in RFC 8620), for example created to the current server time and isSubscribed to true.¶

• Setting mediaType to null now resets it to "application/octet-stream" rather than being an error. (Thanks to Mark Atwood.)¶

draft-ietf-jmap-filenode-16¶

• A name collision with an undiscoverable node returns "forbidden" without existingId; only onExists "rename" proceeds. (Thanks to Mehdi Kouhen.)¶

• onExists replacement requires mayDelete on the existing node.¶

draft-ietf-jmap-filenode-15¶

• Replaced nodeType with an @type property (File, Directory, SymLink). Each type defines only the properties relevant to it; properties of other types are omitted rather than null. @type is now required on creation instead of being inferred.¶

• Moved blobId, size, type, and executable to File, role to Directory, and target to SymLink.¶

• Renamed the File type property to mediaType, with a default of "application/octet-stream", so that it is not confused with @type. Renamed the type and typeMatch filters to mediaType and mediaTypeMatch, and the type sort property to mediaType.¶

• Added the supportedNodeTypes capability.¶

• Removed the X-FileNode-Type header field. A Direct HTTP Write PATCH no longer changes mediaType; clients use PUT or FileNode/set.¶

• Defined how SymLinks are archived (as symlink entries, never followed) and extracted (created as SymLinks if supported).¶

• Added onUnsupportedEntry ("error", the default, or "skip") to the archive and extract recipes, for entries the archive format or the server cannot represent, and the "unsupportedEntry" SetError.¶

• Defined the order among nodes that lack a sort property.¶

• Breaking change: the node type values changed from "file", "directory", and "symlink" to "File", "Directory", and "SymLink". Clients MUST now provide @type on creation.¶

• FileNode/get always returns @type, and omits requested properties that are not defined for a node's @type.¶

• Query filters on type-specific properties now match only nodes of that type, for both true and false values. For example, hasAnyRole: false no longer matches Files or SymLinks, and isExecutable: false no longer matches Directories or SymLinks.¶

• Added "unchanged" value for onExists, replacing a colliding node only when a precondition on that node, supplied via "ifUnchangedBy" ([JMAP-CONDITIONAL]), is satisfied. The precondition binds to the current id of the node that occupies the contested name, so a client can only replace the one node it expected.¶

• Added Extended Attributes and Named Streams: file nodes carry POSIX xattrs, macOS extended attributes, NTFS/SMB alternate data streams, and NFSv4 named attributes via the JMAP Object Metadata extension ([JMAP-METADATA]), defining the "xattr" namespace (attribute name to an XattrValue holding either inline "data" or a "blobId" for large/binary values). Registered the "xattr" namespace with IANA.¶

• Escaped bracket characters in "String[]" type signatures.¶

• Editorial: applied a subset of ASD-STE100 Simplified Technical English — removed "e.g."/"i.e.", split over-long sentences (notably onExists "unchanged"), and reworded noun clusters and idioms. No normative change.¶

draft-ietf-jmap-filenode-14¶

• Added "newest" value for onExists.¶

draft-ietf-jmap-filenode-13¶

• Reordered methods to get/changes/set/copy/query/queryChanges per RFC 8620 convention.¶

• Promoted Direct HTTP Write to top-level section.¶

• Moved Access Control before Quotas and integrations.¶

• Added caseInsensitiveNames capability and compareCaseInsensitively parameter on FileNode/set.¶

draft-ietf-jmap-filenode-12¶

• Added symlink support: nodeType property (file, directory, symlink) with IANA registry, and target property (array of path elements).¶

• Replaced isFile/isDirectory query filters and sort with nodeType.¶

• Expanded myRights: replaced mayWrite with mayAddChildren, mayRename, mayDelete, mayModifyContent.¶

• Added forbiddenNameChars and forbiddenNodeNames capabilities; removed hardcoded name restrictions from spec.¶

• Added changed (server-set) timestamp.¶

• Added Implementation Considerations section with guidance on timestamps, access times, and filename restrictions.¶

draft-ietf-jmap-filenode-11¶

• Updated for blobext recipe renames (ExtractRecipe).¶

draft-ietf-jmap-filenode-10¶

• Added ExtractRecipe parentNodeId extension for extracting archives directly into FileNode trees.¶

draft-ietf-jmap-filenode-09¶

• Renamed hasType filter to isFile and isDirectory (separate filters).¶

• Renamed hasRole filter to role for consistency.¶

• Defined glob matching syntax for nameMatch/typeMatch.¶

• Added fetchParents argument to FileNode/get.¶

• Added descendantId filter to FileNode/query.¶

draft-ietf-jmap-filenode-08¶

• Removed immutability restriction on blobId, size, and type — nodes can now have their content updated via FileNode/set.¶

• Added webWriteUrlTemplate capability for direct HTTP PUT/PATCH writes to file nodes.¶

• Added documents, downloads, music, pictures, and videos roles.¶

• Added Quotas section referencing RFC 9425.¶

draft-ietf-jmap-filenode-07¶

• added webTrashUrl and webUrlTemplate to the capabilities object¶

• added capability example JSON¶

• added explicit Errors sections to FileNode/set and FileNode/copy¶

• fixed typos and spelling errors¶

• added BCP 14 boilerplate¶

• fleshed out Security Considerations¶

• replaced role TODO with IANA registry¶

• documented webUrlTemplate variables¶

• clarified modified/accessed semantics: client-managed with null to reset to server time¶

• clarified blobId constraints and blob lifetime¶

• documented myRights inheritance and FileNode/changes behaviour when shareWith changes¶

• wrapped long lines throughout¶

• added Integration with JMAP Blob Extensions section (ArchiveEntry extension with nodeId and recurse)¶

draft-ietf-jmap-filenode-06¶

• Documented FileNode/copy and detailed that it has the same new top-level keys¶

draft-ietf-jmap-filenode-05¶

• Renamed onDuplicate to onExists for name alignment¶

• added "role" for directories¶

• added a "TODO" for putting more restrictions on node names¶

• changed hasParentId to isTopLevel with reversed boolean meaning¶

draft-ietf-jmap-filenode-04¶

• Documented that blobId, size, and type are immutable after creation.¶

• Documented that creating a file and deleting the old copy of the file within a transaction is legal.¶

• Added onDuplicate top-level option for FileNode/set, giving both "rename" and "replace" options.¶

• Updated the definition of shareWith to say that the keys of the hash are Ids, not arbitrary strings¶

draft-ietf-jmap-filenode-03¶

• Added 'text' and 'body' searches (added JMAP-MAIL reference as additional information for body search)¶

• Updated JMAP-CONTACTS and JMAP-SHARING references to published RFC numbers rather than draft names¶

• Noted that the server MUST included the nodeids of deleted child nodes.¶

• Added isSubscribed¶

• Renamed mayAdmin to mayShare to align with other specs¶

• Described the inheritance of ACLs¶

draft-ietf-jmap-filenode-02¶

• Convert to Kramdown-RFC format (no intentional changes)¶

draft-ietf-jmap-filenode-01¶

• Refreshing draft only¶

draft-ietf-jmap-filenode-00¶

• upload as a working group document¶

draft-gondwana-jmap-filenode-01¶

• require a blobId for the zero-byte file¶

• make size also null for collections¶

• add more to the TODO section¶

• bikeshed; FileNode¶

• correct UTCDate, UnsignedInt, and normalised UTF-8.¶

• add some fields to the capabilities object¶

draft-gondwana-jmap-filenode-00¶

• initial proposal¶

13. Acknowledgements

Mark Atwood, Ben Bucksch, Mauro De Gennaro, Seph Gentle, Arnt Gulbradson, Neil Jenkins, Mehdi Kouhen, Ricardo Signes, and members of the JMAP Working Group at IETF.¶

{backmatter}¶

14. References

Author's Address