<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-gondwana-jmap-filenode-00" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" updates="8620" indexInclude="true" consensus="true">

<front>
<title abbrev="JMAP Filenode">JMAP File Storage extension</title><seriesInfo value="draft-gondwana-jmap-filenode-00" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>
<author role="editor" initials="B." surname="Gondwana" fullname="Bron Gondwana"><organization>Fastmail</organization><address><postal><street>Level 2, 114 William St</street>
<city>Melbourne</city>
<code>VIC 3000</code>
<country>Australia</country>
</postal><email>brong@fastmailteam.com</email>
<uri>https://www.fastmail.com</uri>
</address></author><date year="2024" month="November" day="2"></date>
<area>Applications</area>
<workgroup>JMAP</workgroup>
<keyword>jmap</keyword>

<abstract>
<t>The JMAP base protocol (RFC8620) provides the ability to upload and download
arbitrary binary data.  This binary data is called a &quot;blob&quot;, and can be used
in all other JMAP extensions.</t>
<t>This extension adds a method to expose blobs as a filesystem along with the
types of metadata that are provided by other remote filesystem protocols.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>JMAP (<xref target="RFC8620"></xref> <u format="char-num">—</u> 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.</t>
<t>In the same way that JMAP Calendars (<xref target="I-D.ietf-jmap-calendars"></xref>) replaces
CalDAV (<xref target="RFC5545"></xref>) and JMAP Contacts (<xref target="I-D.ietf-jmap-contacts"></xref>) replaces
CardDAV (<xref target="RFC6352"></xref>), this document replaces the use of WebDAV (<xref target="RFC4918"></xref>)
for remote filesystem access.</t>
</section>

<section anchor="conventions-used-in-this-document"><name>Conventions Used In This Document</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL
NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;,
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only when,
they appear in all capitals, as shown here.</t>
<t>The definitions of JSON keys and datatypes in the document follow
the conventions described in the core JMAP specification <xref target="RFC8620"></xref>.</t>
</section>

<section anchor="addition-to-the-capabilities-object"><name>Addition to the Capabilities Object</name>
<t>The capabilities object is returned as part of the JMAP Session
object; see <xref target="RFC8620"></xref>, Section 2.</t>
<t>This document defines an additional capability URI.</t>

<section anchor="urn-ietf-params-jmap-filenode"><name>urn:ietf:params:jmap:filenode</name>
<t>The capability <tt>urn:ietf:params:jmap:filenode</tt> being present in the
&quot;accountCapabilities&quot; property of an account represents support
for the Filenode datatype.  Servers that include the capability
in one or more &quot;accountCapabilities&quot; properties MUST also include
the property in the &quot;capabilities&quot; property.</t>
<t>The value of this property in the JMAP session &quot;capabilities&quot;
property MUST be an empty object.</t>
<t>The value of this property in an account's &quot;accountCapabilities&quot;
property is an object that MUST contain the following information
on server capabilities and permissions for that account:</t>

<ul spacing="compact">
<li>TODO: limits</li>
</ul>

<section anchor="capability-example"><name>Capability Example</name>
<t>TODO</t>
</section>
</section>
</section>

<section anchor="filenode-data-type"><name>Filenode Data Type</name>
<t>A Filenode is a set of metadata which behaves similar to an inode in
a filesystem.  In <xref target="RFC4918"></xref> terminology a Filenode can refer to either
a collection or a resource.</t>
<t>The following JMAP Methods are selected by the
<tt>urn:ietf:params:jmap:filenode</tt> capability.</t>

<section anchor="filenode-objects"><name>Filenode objects</name>
<t>The filenode object has the following keys:</t>

<ul>
<li><t>id: <tt>Id</tt> (server-set)</t>
<t>the Id of this node</t>
</li>
<li><t>parentId: <tt>Id|null</tt></t>
<t>the Id of the parent node, or null if this is the root node</t>
</li>
<li><t>blobId: <tt>Id|null</tt></t>
<t>the blobId for the content of this node, or null if this node has no data (the empty file, or a collection)</t>
</li>
<li><t>size: <tt>Number</tt> (server-set)</t>
<t>the size in bytes of the associated blob data.  This must be 0 if the blobId is null.</t>
</li>
<li><t>name: <tt>String</tt></t>
<t>User-visible name for the FileNode, This can be any UTF-8 string of at least 1 character in length, except:</t>

<ul spacing="compact">
<li>The name MUST be unique for all Filenodes with the same parentId.</li>
<li>The name MUST NOT be &quot;.&quot; or &quot;..&quot;</li>
<li>The name MUST NOT contain a &quot;/&quot;</li>
</ul>
<t>A server MAY limit the name length and will return an <tt>invalidProperties</tt> error if this limit is exceeded.</t>
</li>
<li><t>type: <tt>String|null</tt></t>
<t>The media type of the Filenode. This MUST be <tt>null</tt> if, and only if, the node does not have a <tt>blobId</tt>.</t>
<t>Valid values are found in the IANA media-types registry.  Servers MUST NOT reject media types that are not recognised.</t>
</li>
<li><t>created: <tt>UTCDate</tt></t>
<t>The date the node was created.</t>
</li>
<li><t>modifed: <tt>UTCDate</tt></t>
<t>The date the node was last updated.</t>
</li>
<li><t>accessed: <tt>UTCDate</tt></t>
<t>The date the node was last accessed.  NOTE: this is not updated by the server, clients must store a new value if they want to use this.  It is recommended to NOT use this field, or to only lazily update it when making other changes to the server.</t>
</li>
<li><t>executable: <tt>Boolean</tt></t>
<t>If true, the file is should be treated as an executable by operating systems that support this flag.</t>
</li>
<li><t>myRights: <tt>FilesRights</tt> (server-set)</t>
<t>The set of rights (ACLs) the user has in relation to this folder. A <strong>FilesRights</strong> object has the following properties:</t>

<ul spacing="compact">
<li>mayRead: <tt>Boolean</tt> The user may read the contents of this node.</li>
<li>mayWrite: <tt>Boolean</tt> The user may modify the properties of this node, including renaming children.</li>
<li>mayAdmin: <tt>Boolean</tt> The user may change the sharing of this node (see <xref target="I-D.ietf-jmap-sharing"></xref>)</li>
</ul></li>
<li><t>shareWith: <tt>String[FilesRights]|null</tt></t>
<t>A map of userId to rights for users this node is shared with. The owner of the node MUST NOT be in this set. This is <tt>null</tt> if the user requesting the object does not have <tt>myRights.mayAdmin</tt>, or if the node is not shared with anyone.</t>
</li>
</ul>
</section>

<section anchor="filenode-methods"><name>Filenode Methods</name>

<section anchor="filenode-set"><name>Filenode/set</name>
<t>This is a standard Foo/set method, except for some things:</t>
<t>An additional top level argument:</t>
<t>onDestroyRemoveChildren: <tt>Boolean</tt> (default: <tt>false</tt>)</t>
<t>If false, an attempt to destroy a Filenode which is the parentId of another Filenode will be rejected with a <tt>nodeHasChildren</tt> error.  NOTE: if the other nodes are also been destroyed in the same operation, then the server MUST NOT return this error.  Servers must either sort the destroys children before parents, or only check this constraint on the final state, remembering that JMAP <tt>set</tt> operations must be atomic.</t>
<t>If true, then all child nodes will also be destroyed when a node is destroyed.</t>
<t>Further, since parentId creates a tree structure, an attempt to move a node to a parent for which this node is also an ancestor is an error, and an <tt>invalidProperties</tt> error will be returned.</t>
</section>

<section anchor="filenode-get"><name>Filenode/get</name>
<t>This is a standard Foo/get method.</t>
</section>

<section anchor="filenode-changes"><name>Filenode/changes</name>
<t>This is a standard Foo/changes method.</t>
</section>

<section anchor="filenode-query"><name>Filenode/query</name>
<t>This is a standard Foo/query method except for the following:</t>
<t>There's one more property to the query:</t>

<ul>
<li><t>depth: <tt>Number|null</tt></t>
<t>The number of levels of subdiretories to recurse into.  If absent, null, or zero, do not recurse.</t>
</li>
</ul>
<t>The following filter criteria are defined:</t>

<ul>
<li><t>hasParentId: <tt>Boolean</tt></t>
<t>If true, the node must have a non-null parentId (i.e. is not a root node).</t>
</li>
<li><t>parentId: <tt>Id</tt></t>
<t>A Filenode id. A node must have a parentId equal to this to match the condition.</t>
</li>
<li><t>ancestorId: <tt>Id</tt></t>
<t>A Filenode id. A node must have an ancestor (parent, parent of parent, etc.) with an id equal to this to to match the condition.</t>
</li>
<li><t>hasType: <tt>Boolean</tt></t>
<t>If <tt>true</tt>, the Filenode must be a file/resource, not a directory/collection.</t>
</li>
<li><t>blobId: <tt>Id</tt></t>
<t>A Filenode must have a blobId equal to this to match the condition.</t>
</li>
<li><t>isExecutable: <tt>Boolean</tt></t>
<t>If <tt>true</tt>, the Filenode must have a true executable value.</t>
</li>
<li><t>createdBefore: <tt>Date</tt></t>
<t>The creation date of the node (as returned on the Filenode object) must be before this date to match the condition.</t>
</li>
<li><t>createdAfter: <tt>Date</tt></t>
<t>The creation date of the node (as returned on the Filenode object) must be on or after this date to match the condition.</t>
</li>
<li><t>modifiedBefore: <tt>Date</tt></t>
<t>The modified date of the node (as returned on the Filenode object) must be before this date to match the condition.</t>
</li>
<li><t>modifiedAfter: <tt>Date</tt></t>
<t>The modified date of the node (as returned on the Filenode object) must be on or after this date to match the condition.</t>
</li>
<li><t>accessedBefore: <tt>Date</tt></t>
<t>The accessed date of the node (as returned on the Filenode object) must be before this date to match the condition.</t>
</li>
<li><t>accessedAfter: <tt>Date</tt></t>
<t>The accessed date of the node (as returned on the Filenode object) must be on or after this date to match the condition.</t>
</li>
<li><t>minSize: <tt>Number</tt></t>
<t>The size of the node in bytes (as returned on the Filenode object) must be equal to or greater than this number to match the condition.</t>
</li>
<li><t>maxSize: <tt>Number</tt></t>
<t>The size of the node in bytes (as returned on the Filenode object) must be less than this number to match the condition.</t>
</li>
<li><t>name: <tt>String</tt></t>
<t>A Filenode must have exactly the same octets in its name property to match the condition</t>
</li>
<li><t>nameMatch: <tt>String</tt></t>
<t>Does a glob match of the specified name against the <em>name</em> property of the node.</t>
</li>
<li><t>type: <tt>String</tt></t>
<t>A Filenode must have exactly the same octets in its type property to match the condition</t>
</li>
<li><t>typeMatch: <tt>String</tt></t>
<t>Does a glob match of the specified type against the <em>type</em> property of the node.</t>
</li>
</ul>
<t>It also supports the following sort properties:</t>

<ul>
<li><t>name:</t>
<t>Sort by name only</t>
</li>
<li><t>tree:</t>
<t>Sort by tree; which means by name, but any directory/collection node is immediately followed by the recursive application of the same sort to its child nodes.  This is similar to the output of the <tt>find</tt> command on a filesystem with the depth parameter provided above.</t>
</li>
<li><t>hasType:</t>
<t>Sort directories before files (false sorts before true)</t>
</li>
<li><t>type:</t>
<t>Sort directories first, AND sort by media type for files</t>
</li>
<li><t>executable:</t>
<t>Sort non-executable files first</t>
</li>
<li><t>created:</t>
<t>Sort by creation time</t>
</li>
<li><t>modified:</t>
<t>Sort by modification time</t>
</li>
<li><t>accessed:</t>
<t>Sort by access time</t>
</li>
</ul>
</section>

<section anchor="filenode-querychanges"><name>Filenode/queryChanges</name>
<t>This is a standard Foo/queryChanges method.</t>
</section>
</section>
</section>

<section anchor="security-considerations"><name>Security considerations</name>
<t>TODO: lots of &quot;filesystems are risky&quot; - I guess look at the referenced
RFCs and what they said.</t>
</section>

<section anchor="iana-considerations"><name>IANA considerations</name>

<section anchor="jmap-capability-registration-for-filenode"><name>JMAP Capability registration for &quot;filenode&quot;</name>
<t>IANA is requested to register the &quot;filenode&quot; JMAP Capability as follows:</t>
<t>Capability Name: urn:ietf:params:jmap:filenode</t>
<t>Specification document: this document</t>
<t>Intended use: common</t>
<t>Change Controller: IETF</t>
<t>Security and privacy considerations: this document, Section XXX</t>
</section>

<section anchor="jmap-error-codes-registration-for-nodehaschildren"><name>JMAP Error Codes registration for &quot;nodeHasChildren&quot;</name>
<t>IANA is requested to register the &quot;nodeHasChildren&quot; JMAP Error Code as follows:</t>
<t>JMAP Error Code: nodeHasChildren</t>
<t>Intended use: common</t>
<t>Change Controller: IETF</t>
<t>Description: The node being destroyed is still referenced by other nodes which have not been destroyed.</t>
<t>Reference: this document</t>
</section>

<section anchor="jmap-data-types-registration-for-filenode"><name>JMAP Data Types registration for &quot;Filenode&quot;</name>
<t>IANA is requested to register the &quot;Filenode&quot; JMAP Data Type as follows:</t>
<t>Type Name: Filenode</t>
<t>Can Reference Blobs: Yes</t>
<t>Can Use For State Change: Yes</t>
<t>Capability: urn:ietf:params:jmap:filenode</t>
<t>Reference: this document</t>
</section>
</section>

<section anchor="todo"><name>TODO</name>

<ul>
<li><t>support SYMLINK types <xref target="RFC4437"></xref></t>
</li>
<li><t>design and document the capabilities object</t>
</li>
<li><t>create real-world clients to test this</t>
</li>
<li><t>security considerations</t>
</li>
</ul>
</section>

<section anchor="changes"><name>Changes</name>
<t>EDITOR: please remove this section before publication.</t>
<t>The source of this document exists on github at: <eref target="https://github.com/brong/draft-gondwana-jmap-filenode/">https://github.com/brong/draft-gondwana-jmap-filenode/</eref></t>
<t><strong>draft-gondwana-jmap-filenode-00</strong></t>

<ul spacing="compact">
<li>initial proposal</li>
</ul>
</section>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>Neil Jenkins and the JMAP working group at the IETF.</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-jmap-sharing.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8620.xml"/>
</references>
<references><name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-jmap-calendars.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-jmap-contacts.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4437.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5545.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6352.xml"/>
</references>

</back>

</rfc>
