<?xml version="1.0"encoding="utf-8"?>encoding="UTF-8"?> <!-- pre-edited by ST 04/19/24 --> <!-- draft submitted in xml v3 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc version="3" ipr="trust200902" docName="draft-ietf-jmap-sharing-09" number="9670" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude"indexInclude="true"tocInclude="true" consensus="true"updates="8620">updates="8620" obsoletes="" symRefs="true" sortRefs="true"> <front> <!-- [rfced] Please note that the title of the document has been updated as follows: Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. Original: JMAP Sharing Current: JSON Meta Application Protocol (JMAP) Sharing --> <title abbrev="JMAPSharing">JMAPSharing">JSON Meta Application Protocol (JMAP) Sharing</title> <seriesInfovalue="draft-ietf-jmap-sharing-09" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>name="RFC" value="9670"/> <author role="editor"initials="N.M."initials="N." surname="Jenkins" fullname="Neil Jenkins"> <organization>Fastmail</organization> <address> <postal> <street>PO Box 234, Collins St West</street> <city>Melbourne</city><code>VIC 8007</code><region>VIC</region> <code>8007</code> <country>Australia</country> </postal> <email>neilj@fastmailteam.com</email> <uri>https://www.fastmail.com</uri> </address> </author> <date year="2024"month="April" day="18"></date> <area>Applications</area> <workgroup>JMAP</workgroup>month="October"/> <area>ART</area> <workgroup>jmap</workgroup> <keyword>JMAP</keyword> <keyword>JSON</keyword> <keyword>sharing</keyword> <abstract> <t>This document specifies a data model for sharing data between users usingJMAP.the JSON Meta Application Protocol (JMAP). Future documents can reference this document when defining data types to support a consistent model of sharing.</t> </abstract> </front> <middle> <section anchor="introduction"><name>Introduction</name><t>JMAP (<xref target="RFC8620"></xref><t>The JSON Meta ApplicationProtocol)Protocol (JMAP) <xref target="RFC8620"/> is a generic protocol for synchronizing data, such as mail,calendarscalendars, or contacts, between a client and a server. It is optimized for mobile and webenvironments,environments and provides a consistent interface to query, read, and modify different data types, including comprehensive error handling.</t> <t>This specification defines a data model to represent entities in a collaborativeenvironment,environment and a framework for sharing data between them that can be used to provide a consistent sharing model for different data types. It does not define <em>what</em> may beshared,shared or the granularity of permissions, as this will depend on the data in question.</t> <section anchor="notational-conventions"><name>Notational Conventions</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>Type signatures, examples, and property descriptions in this document follow the conventions established in <xref target="RFC8620" section="1.1" sectionFormat="of"></xref>. Data types defined in the core specification are also used in this document.</t> <t>Examples of API exchanges only show the methodCalls array of the Request object or the methodResponses array of the Response object. For compactness, the rest of the Request/Response object is omitted.</t> </section> <section anchor="terminology"><name>Terminology</name> <t>The same terminology is used in this document as in the core JMAPspecification, seespecification. See <xref target="RFC8620" section="1.6" sectionFormat="comma"></xref>.</t> <t>The termsPrincipal,"Principal" andShareNotification"ShareNotification" (withthesethis specificcapitalizations)capitalization) are used to refer to the data types defined in this document and instances of those data types.</t> </section> <section anchor="data-model-overview"><name>Data Model Overview</name> <t>A Principal (see <xref target="principals"/>) represents an individual, team, or resource (e.g., a room or projector). The object contains information about the entity being represented, such as a name, description, and time zone. It may also hold domain-specific information. A Principal may be associated with zero or more Accounts (see <xref target="RFC8620" section="1.6.2" sectionFormat="comma"></xref>) containing data belonging to the Principal. Managing the set of Principals within a system is out of scope for this specification, as it is highly domain specific. It is likely to map directly from a directory service or other user management system.</t> <t>Data types may allow users to share data with others by assigning permissions to Principals. When a user's permissions are changed, a ShareNotification object is created for them so a client can inform the user of the changes.</t> </section> <section anchor="subscriptions"><name>Subscribing to Shared Data</name> <t>Permissions determine whether a user <em>may</em> accessdata,data but not whether they <em>want</em> to. Some shared data is of equal importance as the user's own, while other data is just there should the user wish to explicitly go find it. Clients will often want to differentiate the two. For example, a company may share mailing list archives for all departments with all employees, but a user may only generally be interested in the few they belong to. They would have <em>permission</em> to access manymailboxes,mailboxes but can <em>subscribe</em> to just the ones they care about. The client would provide separate interfaces for reading mail in subscribed mailboxes and browsing all mailboxes they have permission to access in order to managewhichthose that they are subscribed to.</t> <t>The JMAP Session object (see <xref target="RFC8620" section="2" sectionFormat="comma"></xref>) is defined to include an object in the <tt>accounts</tt> property for every account that the user has access to. Collaborative systems may share data between a very large number of Principals, most of which the user does not care aboutday-to-day.day to day. For servers implementing this specification, the Session object <bcp14>MUST</bcp14> only include Accounts where either the user is subscribed to at least one record (see <xref target="RFC8620" section="1.6.3" sectionFormat="comma"></xref>) in theaccount,account or the account belongs to the user. StateChange events (<xref target="RFC8620" section="7.1" sectionFormat="comma"></xref>) for changes to data <bcp14>SHOULD</bcp14> only be sent for data the user has subscribed to and <bcp14>MUST NOT</bcp14> be sent for any account where the user is not subscribed to any records in the account, except where that account belongs to the user.</t> <t>The server <bcp14>MAY</bcp14> reject the user's attempt to subscribe to some resources even if they have permission to access them (e.g., a calendar representing a location).</t> <t>A user can query the set of Principals they have access to with "Principal/query" (see <xref target="principal-query"/>). The Principal object will contain an Account object for all accounts where the user has permission to access data for that Principal, even if they are not yet subscribed.</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" section="2" sectionFormat="comma"></xref>. This document defines two additional capability URIs.</t> <section anchor="urn-ietf-params-jmap-principals"><name>urn:ietf:params:jmap:principals</name> <t>The <tt>urn:ietf:params:jmap:principals</tt> capability represents support for the Principal and ShareNotification data types and associated API methods.</t> <t>The value of this property in the JMAP Session capabilities property is an empty object.</t> <t>The value of this property in anaccount’saccount's accountCapabilities property is an object that <bcp14>MUST</bcp14> contain the following information on server capabilities and permissions for that account:</t> <ul spacing="compact"> <li><t><strong>currentUserPrincipalId</strong>: <tt>Id|null</tt></t> <t>The id of the Principal in this account that corresponds to the user fetching this object, if any.</t></li> </ul> </section> <section anchor="urn-ietf-params-jmap-principals-owner"><name>urn:ietf:params:jmap:principals:owner</name> <t>The URI <tt>urn:ietf:params:jmap:principals:owner</tt> is solely used as a key in anaccount’saccount's accountCapabilities property. It does not appear in the JMAP Session capabilities—-- support is indicated by the <tt>urn:ietf:params:jmap:principals</tt> URI being present in the session capabilities.</t> <t>If the <tt>urn:ietf:params:jmap:principals:owner</tt> is a key in anaccount’saccount's accountCapabilities, that account (and the data therein) is owned by a Principal. Some accounts may not be owned by a Principal (e.g., the account that contains the data for the Principals themselves), in which case this property is omitted.</t> <t>The value of this property is an object with the following properties:</t><ul spacing="compact"><!--[rfced] Formatting of lists. Throughout the document, each list uses <ul> (with bullets) and the <strong> element, which adds asterisks around the terms and makes the .txt file hard to read. To avoid this, we formatted the lists using <dl> with the descriptions starting on a new line. This way, we were able to retain the normal spacing and <strong> elements in all output files, including the HTML and PDF files, and the .txt file is easier to read. Otherwise, another option would be to format the lists using <ul> with the descriptions on a new line, but "compact" spacing has to be used to avoid an extra line of space between the term and the description. With <ul>, you can choose to use bullets and no <strong> element (option A) or no bullets with the <strong> element (option B). Note that if you opt to not use <strong>, there will be no bolding in the output files (which includes the HTML and PDF files). Please review and let us know if the current formatting is acceptable or if you prefer option A or B. One example from Section 1.5.2. Current: Format in the .txt file using <dl>, normal spacing, and the <strong> element: *accountIdForPrincipal*: Id The id of an account with the urn:ietf:params:jmap:principals capability that contains the corresponding Principal object. *principalId*:Id The id of the Principal that owns this account. Perhaps A: Format in the .txt file using <ul> with bullets, compact spacing, and no <strong> element: * accountIdForPrincipal: Id The id of an account with the urn:ietf:params:jmap:principals capability that contains the corresponding Principal object. * principalId: Id The id of the Principal that owns this account. Or Perhaps B: Format in the .txt file using <ul> with no bullets, compact spacing, and the <strong> element: *accountIdForPrincipal*: Id The id of an account with the urn:ietf:params:jmap:principals capability that contains the corresponding Principal object. *principalId*: Id The id of the Principal that owns this account. --> <dl spacing="normal" newline="true"> <dt><strong>accountIdForPrincipal</strong>: <tt>Id</tt></dt><dd> The id of an account with the <tt>urn:ietf:params:jmap:principals</tt> capability that contains the corresponding Principal object.</dd> <dt><strong>principalId</strong>:<tt>Id</tt></dt><dd> The id of the Principal that owns this account.</dd> </dl> <!--NOTE: original format--> <!--<ul spacing="compact" empty="true"> <li><t><strong>accountIdForPrincipal</strong>: <tt>Id</tt></t> <t>The id of an account with the <tt>urn:ietf:params:jmap:principals</tt> capability that contains the corresponding Principal object.</t></li> <li><t><strong>principalId</strong>: <tt>Id</tt></t> <t>The id of the Principal that owns this account.</t></li> </ul> --> </section> </section> </section> <section anchor="principals"><name>Principals</name> <t>A Principal represents an individual, a group, a location (e.g., a room), a resource (e.g., aprojector)projector), orotheranother entity in a collaborative environment. Sharing in JMAP is generally configured by assigning rights to certain data within an account to other Principals. For example, a user may assign permission to read their calendar to a Principal representing another user or their team.</t> <t>In a sharedenvironmentenvironment, such as a workplace, a user may have access to a large number of Principals.</t> <t>In most systems, the user will have access to a single Account containing Principal objects. In some situations, forexampleexample, when aggregating data from different places, there may be multiple Accounts containing Principal objects.</t> <t>A <strong>Principal</strong> object has the following properties:</t> <!--[rfced] Section 2. Should the links to the IANA Time Zone Database and "JMAP Data Types" registry perhaps be citations with corresponding entries in the Informative Reference section as shown below? Current (.txt file): *timeZone*: String|null The time zone for this Principal, if known. If not null, the value MUST be a time zone name from the IANA Time Zone Database (TZDB) (https://www.iana.org/time-zones). *objectType*: String (immutable; server-set) The name of the data type for the object whose permissions have changed, as registered in the IANA "JMAP Data Types" registry (https://www.iana.org/assignments/jmap/), e.g., "Calendar" or "Mailbox". Perhaps: *timeZone*: String|null The time zone for this Principal, if known. If not null, the value MUST be a time zone name from the IANA Time Zone Database [IANA-TZDB]. *objectType*: String (immutable; server-set) The name of the data type for the object whose permissions have changed, as registered in the IANA "JMAP Data Types" registry [IANA-JMAP], e.g., "Calendar" or "Mailbox". Informative Reference Entries: [IANA-TZDB] IANA, "Time Zone Database", <https://www.iana.org/time-zones>. [IANA-JMAP] IANA, "JMAP Data Types", <https://www.iana.org/assignments/jmap>. --> <dl spacing="normal" newline="true"> <dt><strong>id</strong>: <tt>Id</tt> (immutable; server-set)</dt> <dd>The id of the Principal.</dd> <dt><strong>type</strong>: <tt>String</tt></dt> <dd><t>This <bcp14>MUST</bcp14> be one of the following values:</t> <ul spacing="compact"> <li><tt>individual</tt>: This represents a single person.</li> <li><tt>group</tt>: This represents a group of other Principals.</li> <li><tt>resource</tt>: This represents some resource, e.g., a projector.</li> <li><tt>location</tt>: This represents a location.</li> <li><tt>other</tt>: This represents some other undefined Principal.</li> </ul></dd> <dt><strong>name</strong>: <tt>String</tt></dt> <dd>The name of the Principal, e.g., "Jane Doe" or "Room 4B".</dd> <dt><strong>description</strong>: <tt>String|null</tt></dt> <dd>A longer description of the Principal, for example, details about the facilities of a resource, or null if no description is available.</dd> <dt><strong>email</strong>: <tt>String|null</tt></dt> <dd>An email address for the Principal, or null if no email is available. If given, the value <bcp14>MUST</bcp14> conform to the "addr-spec" syntax, as defined in <xref target="RFC5322" section="3.4.1" sectionFormat="comma" />.</dd> <dt><strong>timeZone</strong>: <tt>String|null</tt></dt> <dd>The time zone for this Principal, if known. If not null, the value <bcp14>MUST</bcp14> be a time zone name from the IANA Time Zone Database <eref target="https://www.iana.org/time-zones">(TZDB)</eref>.</dd> <dt><strong>capabilities</strong>: <tt>String[Object]</tt> (server-set)</dt> <dd>A map of JMAP capability URIs to domain-specific information about the Principal in relation to that capability, as defined in the document that registered the capability.</dd> <dt><strong>accounts</strong>: <tt>Id[Account]|null</tt> (server-set)</dt> <dd>A map of account id to Account object for each JMAP Account containing data for this Principal that the user has access to, or null if none.</dd> </dl> <!--NOTE: original format--> <!--<ul spacing="compact"> <li><t><strong>id</strong>: <tt>Id</tt> (immutable; server-set)</t> <t>The id of the Principal.</t></li> <li><t><strong>type</strong>: <tt>String</tt></t> <t>This <bcp14>MUST</bcp14> be one of the following values:</t> <ul spacing="compact"> <li><tt>individual</tt>: This represents a single person.</li> <li><tt>group</tt>: This represents a group of other Principals.</li> <li><tt>resource</tt>: This represents some resource, e.g., a projector.</li> <li><tt>location</tt>: This represents a location.</li> <li><tt>other</tt>: This represents some other undefined Principal.</li> </ul></li> <li><t><strong>name</strong>: <tt>String</tt></t> <t>The name of the Principal, e.g., "JaneDoe",Doe" or "Room 4B".</t></li> <li><t><strong>description</strong>: <tt>String|null</tt></t> <t>A longer description of the Principal, forexampleexample, details about the facilities of a resource, or null if no description is available.</t></li> <li><t><strong>email</strong>: <tt>String|null</tt></t> <t>An email address for the Principal, or null if no email is available. If given, the valueMUST<bcp14>MUST</bcp14> conform to the "addr-spec" syntax, as defined in <xref target="RFC5322" section="3.4.1" sectionFormat="comma" />.</t></li> <li><t><strong>timeZone</strong>: <tt>String|null</tt></t> <t>The time zone for this Principal, if known. If not null, the value <bcp14>MUST</bcp14> be a time zone name from the IANA Time Zone Database <ereftarget="https://www.iana.org/time-zones">TZDB</eref>.</t></li>target="https://www.iana.org/time-zones">(TZDB)</eref>.</t></li> <li><t><strong>capabilities</strong>: <tt>String[Object]</tt> (server-set)</t> <t>A map of JMAP capability URIs todomain specificdomain-specific information about the Principal in relation to that capability, as defined in the document that registered the capability.</t></li> <li><t><strong>accounts</strong>: <tt>Id[Account]|null</tt> (server-set)</t> <t>A map of account id to Account object for each JMAP Account containing data for this Principal that the user has access to, or null if none.</t></li></ul></ul>--> <section anchor="principal-get"><name>Principal/get</name> <t>This is a standard "/get" method as described in <xref target="RFC8620" section="5.1" sectionFormat="comma"></xref>.</t> </section> <section anchor="principal-changes"><name>Principal/changes</name> <t>This is a standard "/changes" method as described in <xref target="RFC8620" section="5.2"sectionFormat="comma"></xref>. Note: implementationssectionFormat="comma"></xref>.</t> <!--[rfced] Sections 2.2 and 2.5. FYI: We enclosed the "Notes" (two instances) in the aside element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). If this is not desired, please let us know. --> <aside><t>Note: Implementations backed by an external directory may be unable to calculate changes. In this case, they will always return a "cannotCalculateChanges" error as described in the core JMAPspecification.</t>specification.</t></aside> </section> <section anchor="principal-set"><name>Principal/set</name> <t>This is a standard "/set" method as described in <xref target="RFC8620" section="5.3" sectionFormat="comma"></xref>.</t> <t>Managing Principals is likely tied to a directory service or some other vendor-specific solution. This management may occurout-of-band,out of band or via an additional capability defined elsewhere. Allowing direct user modification of properties has security considerations, as noted in <xref target="security-considerations" />.Servers MUSTA server <bcp14>MUST</bcp14> reject any change itdoesn’tdoesn't allow with a <tt>forbidden</tt> SetError.</t> <t>Where a server does support changes via this API, it <bcp14>SHOULD</bcp14> allow an update to the "name","description""description", and "timeZone" properties of the Principal with the same id as the "currentUserPrincipalId" in the Account capabilities. This allows the user to update their own details.</t> </section> <section anchor="principal-query"><name>Principal/query</name> <t>This is a standard "/query" method as described in <xref target="RFC8620" section="5.5"sectionFormat="comma"></xref></t>sectionFormat="comma"></xref>.</t> <section anchor="filtering"><name>Filtering</name> <t>A <strong>FilterCondition</strong> object has the following properties, all of which are optional:</t><ul<dl spacing="normal" newline="true"> <dt><strong>accountIds</strong>: <tt>String[]</tt></dt> <dd>A list of account ids. The Principal matches if any of the ids in this list are keys in the Principal's "accounts" property (i.e., if any of the account ids belong to the Principal).</dd> <dt><strong>email</strong>: <tt>String</tt></dt> <dd>The email property of the Principal contains the given string.</dd> <dt><strong>name</strong>: <tt>String</tt></dt> <dd>The name property of the Principal contains the given string.</dd> <dt><strong>text</strong> <tt>String</tt></dt> <dd>The name, email, or description property of the Principal contains the given string.</dd> <dt><strong>type</strong>: <tt>String</tt></dt> <dd>The type must be exactly as given to match the condition.</dd> <dt><strong>timeZone</strong>: <tt>String</tt></dt> <dd>The timeZone must be exactly as given to match the condition.</dd> </dl> <!--NOTE: original formatting--> <!--<ul spacing="compact"> <li><t><strong>accountIds</strong>: <tt>String[]</tt></t> <t>A list of account ids. The Principal matches if any of the ids in this list are keys in the Principal's "accounts" property (i.e., if any of the account ids belong to the Principal).</t></li> <li><t><strong>email</strong>: <tt>String</tt></t> <t>The email property of the Principal contains the given string.</t></li> <li><t><strong>name</strong>: <tt>String</tt></t> <t>The name property of the Principal contains the given string.</t></li> <li><t><strong>text</strong> <tt>String</tt></t> <t>The name, email, or description property of the Principal contains the given string.</t></li> <li><t><strong>type</strong>: <tt>String</tt></t> <t>The type must be exactly as given to match the condition.</t></li> <li><t><strong>timeZone</strong>: <tt>String</tt></t> <t>The timeZone must be exactly as given to match the condition.</t></li> </ul> --> <t>All given conditions in the FilterCondition object must match for the Principal to match.</t> <t>Text matches for "contains"SHOULD<bcp14>SHOULD</bcp14> be simple substring matches.</t> </section> </section> <section anchor="principal-querychanges"><name>Principal/queryChanges</name> <t>This is a standard "/queryChanges" method as described in <xref target="RFC8620" section="5.6"sectionFormat="comma"></xref>. Note: implementationssectionFormat="comma"></xref>.</t> <aside><t>Note: Implementations backed by an external directory may be unable to calculate changes. In this case, they will always return a "cannotCalculateChanges" error as described in the core JMAPspecification.</t>specification.</t></aside> </section> </section> <!-- [rfced] We have a couple of questions regarding "ShareNotification": A) Section 3 has the title "Share Notifications" (with a space) while the information that follows uses "ShareNotification" (no space). Should we update the title to no space (e.g., "ShareNotifications")? B) We see ShareNotification with <tt> tags, <strong> tags, and no tags. How may we update for consistency? ShareNotification <tt>ShareNotification</tt> <strong>ShareNotification</strong> --> <section anchor="share-notifications"><name>Share Notifications</name> <t>The ShareNotification data type records when the user's permissions to access a shared object changes.ShareNotificationShareNotifications are only created by the server; users cannot create them explicitly. Notifications are stored in the same Account as the Principals.</t> <t>Clients may present the list of notifications to the user and allowthemthe user to dismiss them. To dismiss anotification younotification, use a standard "/set" call to destroy it.</t> <t>The server <bcp14>SHOULD</bcp14> create a ShareNotification whenever the user's permissions change on an object. It <bcp14>MAY</bcp14> choose not to create a notification for permission changes to a group Principal, even if the user is in the group, if this is more likely to be overwhelming than helpful, or if it would create excessive notifications within the system.</t> <sectionanchor="auto-deletion-of-notifications"><name>Auto-deletionanchor="auto-deletion-of-notifications"><name>Auto-Deletion of Notifications</name> <t>The server <bcp14>MAY</bcp14> limit the maximum number of notifications it will store for a user. When the limit is reached, any new notification will cause the previously oldest notification to be automatically deleted.</t> <t>The server <bcp14>MAY</bcp14> coalesce notifications ifappropriate,appropriate or remove notifications after a certain period of time or that it deems are no longerrelevant or after a certain period of time.</t>relevant.</t> </section> <section anchor="object-properties"><name>Object Properties</name> <t>The <strong>ShareNotification</strong> object has the following properties:</t> <dl spacing="normal" newline="true"> <dt><strong>id</strong>: <tt>String</tt> (immutable; server-set)</dt> <dd>The id of the ShareNotification.</dd> <dt><strong>created</strong>: <tt>UTCDate</tt> (immutable; server-set)</dt> <dd>The time this notification was created.</dd> <dt><strong>changedBy</strong>: <tt>Entity</tt> (immutable; server-set)</dt> <dd><t>Who made the change.</t> <ul spacing="compact"> <li><t><strong>name</strong>: <tt>String</tt></t> <t>The name of the entity who made the change.</t></li> <li><t><strong>email</strong>: <tt>String|null</tt></t> <t>The email of the entity who made the change, or null if no email is available.</t></li> <li><t><strong>principalId</strong>: <tt>Id|null</tt></t> <t>The id of the Principal corresponding to the entity who made the change, or null if no associated Principal.</t></li> </ul></dd> <dt><strong>objectType</strong>: <tt>String</tt> (immutable; server-set)</dt> <dd>The name of the data type for the object whose permissions have changed, as registered in the <eref target="https://www.iana.org/assignments/jmap/">IANA "JMAP Data Types" registry</eref>, e.g., "Calendar" or "Mailbox".</dd> <dt><strong>objectAccountId</strong>: <tt>Id</tt> (immutable; server-set)</dt> <dd>The id of the account where this object exists.</dd> <dt><strong>objectId</strong>: <tt>Id</tt> (immutable; server-set)</dt> <dd>The id of the object that this notification is about.</dd> <dt><strong>oldRights</strong>: <tt>String[Boolean]|null</tt> (immutable; server-set)</dt> <dd>The "myRights" property of the object for the user before the change.</dd> <dt><strong>newRights</strong>: <tt>String[Boolean]|null</tt> (immutable; server-set)</dt> <dd>The "myRights" property of the object for the user after the change.</dd> <dt><strong>name</strong>: <tt>String</tt> (immutable; server-set)</dt> <dd>The name of the object at the time the notification was made. Determining the name will depend on the data type in question. For example, it might be the "title" property of a CalendarEvent or the "name" of a Mailbox. The name is to show users who have had their access rights to the object removed what it is that they can no longer access. </dd> </dl> <!--NOTE: original format--> <!--<ul spacing="compact"> <li><t><strong>id</strong>: <tt>String</tt> (immutable; server-set)</t> <t>The id of the ShareNotification.</t></li> <li><t><strong>created</strong>: <tt>UTCDate</tt> (immutable; server-set)</t> <t>The time this notification was created.</t></li> <li><t><strong>changedBy</strong>: <tt>Entity</tt> (immutable; server-set)</t> <t>Who made the change.</t> <ul spacing="compact"> <li><t><strong>name</strong>: <tt>String</tt></t> <t>The name of the entity who made the change.</t></li> <li><t><strong>email</strong>: <tt>String|null</tt></t> <t>The email of the entity who made the change, or null if no email is available.</t></li> <li><t><strong>principalId</strong>: <tt>Id|null</tt></t> <t>The id of the Principal corresponding to the entity who made the change, or null if no associated Principal.</t></li> </ul></li> <li><t><strong>objectType</strong>: <tt>String</tt> (immutable; server-set)</t> <t>The name of the data type for the object whose permissions have changed, as registered in the <eref target="https://www.iana.org/assignments/jmap/jmap.xhtml#jmap-data-types">IANAJMAP"JMAP DataTypes registry</eref>.Types" registry</eref>, e.g., "Calendar" or "Mailbox".</t></li> <li><t><strong>objectAccountId</strong>: <tt>Id</tt> (immutable; server-set)</t> <t>The id of the account where this object exists.</t></li> <li><t><strong>objectId</strong>: <tt>Id</tt> (immutable; server-set)</t> <t>The id of the object that this notification is about.</t></li> <li><t><strong>oldRights</strong>: <tt>String[Boolean]|null</tt> (immutable; server-set)</t> <t>The "myRights" property of the object for the user before the change.</t></li> <li><t><strong>newRights</strong>: <tt>String[Boolean]|null</tt> (immutable; server-set)</t> <t>The "myRights" property of the object for the user after the change.</t></li> <li><t><strong>name</strong>: <tt>String</tt> (immutable; server-set)</t> <t>The name of the object at the time the notification was made. Determining the name will depend on the data type in question. For example, it might be the "title" property of a CalendarEvent or the "name" of a Mailbox. The name is to show to users who have had their access rights to the object removed, so that these users know what it is they can no longer access.</t></li> </ul> --> </section> <section anchor="sharenotification-get"><name>ShareNotification/get</name> <t>This is a standard "/get" method as described in <xref target="RFC8620" section="5.1" sectionFormat="comma"></xref>.</t> </section> <section anchor="sharenotification-changes"><name>ShareNotification/changes</name> <t>This is a standard "/changes" method as described in <xref target="RFC8620" section="5.2" sectionFormat="comma"></xref>.</t> </section> <section anchor="sharenotification-set"><name>ShareNotification/set</name> <t>This is a standard "/set" method as described in <xref target="RFC8620" section="5.3" sectionFormat="comma"></xref>.</t> <t>Only destroy is supported; any attempt to create/update <bcp14>MUST</bcp14> be rejected with a <tt>forbidden</tt> SetError.</t> </section> <section anchor="sharenotification-query"><name>ShareNotification/query</name> <t>This is a standard "/query" method as described in <xref target="RFC8620" section="5.5" sectionFormat="comma"></xref>.</t> <section anchor="filtering-1"><name>Filtering</name> <t>A <strong>FilterCondition</strong> object has the following properties, all of which are optional:</t><ul<dl spacing="normal" newline="true"> <dt><strong>after</strong>: <tt>UTCDate|null</tt></dt> <dd>The creation date must be on or after this date to match the condition.</dd> <dt><strong>before</strong>: <tt>UTCDate|null</tt></dt> <dd>The creation date must be before this date to match the condition.</dd> <dt><strong>objectType</strong>: <tt>String</tt></dt> <dd>The objectType value must be identical to the given value to match the condition.</dd> <dt><strong>objectAccountId</strong>: <tt>Id</tt></dt> <dd>The objectAccountId value must be identical to the given value to match the condition.</dd> </dl> <!-- NOTE: original format--> <!--<ul spacing="compact"> <li><t><strong>after</strong>: <tt>UTCDate|null</tt></t> <t>The creation date must be on or after this date to match the condition.</t></li> <li><t><strong>before</strong>: <tt>UTCDate|null</tt></t> <t>The creation date must be before this date to match the condition.</t></li> <li><t><strong>objectType</strong>: <tt>String</tt></t> <t>The objectType value must be identical to the given value to match the condition.</t></li> <li><t><strong>objectAccountId</strong>: <tt>Id</tt></t> <t>The objectAccountId value must be identical to the given value to match the condition.</t></li> </ul> --> <t>All given conditions in the FilterCondition object must match for the ShareNotification to match.</t> </section> <section anchor="sorting"><name>Sorting</name> <t>The "created" property <bcp14>MUST</bcp14> be supported for sorting.</t> </section> </section> <section anchor="sharenotification-querychanges"><name>ShareNotification/queryChanges</name> <t>This is a standard "/queryChanges" method as described in <xref target="RFC8620" section="5.6" sectionFormat="comma"></xref>.</t> </section> </section> <section anchor="framework-for-shared-data"><name>Framework for Shared Data</name> <t>Shareable data types <bcp14>MUST</bcp14> define the following three properties:</t><ul<dl spacing="normal" newline="true"> <dt><strong>isSubscribed</strong>: <tt>Boolean</tt></dt> <dd>The value "true" indicates that the user wishes to subscribe to see this data. The value "false" indicates that the user does not wish to subscribe to see this data. The initial value for this property when data is shared by another user is implementation dependent, although data types may give advice on appropriate defaults.</dd> <dt><strong>myRights</strong>: <tt>String[Boolean]</tt></dt> <dd>The set of permissions the user currently has. Appropriate permissions are domain specific and must be defined per data type. Each key is the name of a permission defined for that data type. The value for the key is "true" if the user has the permission or "false" if they do not.</dd> <dt><strong>shareWith</strong>: <tt>Id[String[Boolean]]|null</tt></dt> <dd><t>The value of this property is null if the data is not shared with anyone. Otherwise, it is a map where each key is the id of a Principal with which this data is shared, and the value associated with that key is the rights to give that Principal, in the same format as the <tt>myRights</tt> property. The account id for the Principal id can be found in the capabilities of the Account this object is in (see <xref target="urn-ietf-params-jmap-principals-owner"/>).</t> <t>Users with appropriate permission may set this property to modify who the data is shared with. The Principal that owns the account that this data is in <bcp14>MUST NOT</bcp14> be in the set of sharees since the owner's rights are implicit.</t></dd> </dl> <!--NOTE: original format--> <!--<ul spacing="compact"> <li><t><strong>isSubscribed</strong>: <tt>Boolean</tt></t><t>> The<t>The valuetrue"true" indicates the user wishes to subscribe to see this data. The valuefalse"false" indicates the user does not wish to subscribe to see this data. The initial value for this property when data is shared by another user is implementation dependent, although data types may give advice on appropriate defaults.</t></li> <li><t><strong>myRights</strong>: <tt>String[Boolean]</tt></t> <t>The set of permissions the user currently has. Appropriate permissions are domain specific and must be defined per data type. Each key is the name of a permission defined for that data type. The value for the key is<tt>true</tt>true if the user has thepermission,permission or<tt>false</tt>false if they do not.</t></li> <li><t><strong>shareWith</strong>: <tt>Id[String[Boolean]]|null</tt></t> <t>The value of this property is null if the data is not shared with anyone. Otherwise, it is a map where each key is the id of a Principal with which this data is shared, and the value associated with that key is the rights to give that Principal, in the same format as the <tt>myRights</tt> property. The account id for the Principal id can be found in the capabilities of the Account this object is in (see <xref target="urn-ietf-params-jmap-principals-owner"/>). </t> <t>Users with appropriate permission may set this property to modify who the data is shared with. The Principal that owns the account that this data is in <bcp14>MUST NOT</bcp14> be in the set of sharees since the owner's rights are implicit.</t></li></ul></ul>--> <section anchor="example"><name>Example</name> <t>Suppose we are designing a data model for a very simple todo list. There is a Todo data type representing a single item to do, each of which belongs to a single TodoList. The specification makes the lists shareable by referencing this document and defining the common properties.</t><t>First<t>First, it would define a set of domain-specific rights. For example, a TodoListRights object may have the following properties:</t><ul<dl spacing="normal" newline="true"> <dt><strong>mayRead</strong>: <tt>Boolean</tt></dt> <dd>The user may fetch this TodoList and any Todos that belong to this TodoList.</dd> <dt><strong>mayWrite</strong>: <tt>Boolean</tt></dt> <dd>The user may create, update, or destroy Todos that belong to this TodoList and may change the "name" property of this TodoList.</dd> <dt><strong>mayAdmin</strong>: <tt>Boolean</tt></dt> <dd>The user may see and modify the "myRights" property of this TodoList and may destroy this TodoList.</dd> </dl> <!--NOTE: original format--> <!--<ul spacing="compact"> <li><t><strong>mayRead</strong>: <tt>Boolean</tt></t> <t>The user may fetch thisTodoList,TodoList and any Todos that belong to this TodoList.</t></li> <li><t><strong>mayWrite</strong>: <tt>Boolean</tt></t> <t>The user may create, update, or destroy Todos that belong to thisTodoList,TodoList and may change the "name" property of this TodoList.</t></li> <li><t><strong>mayAdmin</strong>: <tt>Boolean</tt></t> <t>The user may see and modify the "myRights" property of thisTodoList,TodoList and may destroy this TodoList.</t></li> </ul> --> <!--[rfced] Are the three common properties that this sentence refers to the ones that are explained directly above (i.e., mayRead, mayWrite, and mayAdmin)? If not, please clarify. If so, may we update the sentence to include "described above" as shown below? Original: Then in the TodoList data type, we would include the three common properties, in addition to any type-specific properties (like "name" in this case): Perhaps: Then in the TodoList data type, we would include the three common properties described above, in addition to any type-specific properties (like "name" in this case): --> <t>Then in the TodoList data type, we would include the three common properties, in addition to any type-specific properties (like "name" in this case):</t><ul<dl spacing="normal" newline="true"> <dt><strong>id</strong>: <tt>Id</tt> (immutable; server-set)</dt> <dd>The id of the object.</dd> <dt><strong>name</strong>: <tt>String</tt></dt> <dd>A name for this list of todos.</dd> <dt><strong>isSubscribed</strong>: <tt>Boolean</tt></dt> <dd>True if the user has indicated they wish to see this list. If false, clients should not display this todo list with the user's other lists but should provide a means for users to see and subscribe to all lists that have been shared with them.</dd> <dt><strong>myRights</strong>: <tt>TodoListRights</tt></dt> <dd>The set of permissions the user currently has for this todo list.</dd> <dt><strong>shareWith</strong>: <tt>Id[TodoListRights]|null</tt></dt> <!--[rfced] Section 4.1. Would it be correct to say that the id-to-rights map is "given to the Principal" (instead of "to give that Principal") as shown below? Original: *shareWith*: Id[TodoListRights]|null A map of Principal id to rights to give that Principal, or null if not shared with anyone or the user does not have the "mayAdmin" right for this list. Perhaps: *shareWith*: Id[TodoListRights]|null A Principal id-to-rights map given to the Principal, or null if not shared with anyone or if the user does not have the "mayAdmin" right for this list. --> <dd>A map of Principal id to rights to give that Principal, or <tt>null</tt> if not shared with anyone or the user does not have the "mayAdmin" right for this list. Users with the "mayAdmin" right may set this property to modify who the data is shared with. The Principal that owns the account that this data is in <bcp14>MUST NOT</bcp14> be in the set of sharees; their rights are implicit.</dd> </dl> <!--NOTE: original format--> <!--<ul spacing="compact"> <li><t><strong>id</strong>: <tt>Id</tt> (immutable; server-set)</t> <t>The id of the object.</t></li> <li><t><strong>name</strong>: <tt>String</tt></t> <t>A name for this list of todos.</t></li> <li><t><strong>isSubscribed</strong>: <tt>Boolean</tt></t> <t>True if the user has indicated they wish to see this list. If false, clients should not display this todo list with the user's otherlists,lists but should provide a means for users to see and subscribe to all lists that have been shared with them.</t></li> <li><t><strong>myRights</strong>: <tt>TodoListRights</tt></t> <t>The set of permissions the user currently has for this todo list.</t></li> <li><t><strong>shareWith</strong>: <tt>Id[TodoListRights]|null</tt></t> <t>A map of Principal id to rights to give that Principal, or <tt>null</tt> if not shared with anyone or the user does not have the "mayAdmin" right for this list. Users with the "mayAdmin" right may set this property to modify who the data is shared with. The Principal that owns the account that this data is in <bcp14>MUST NOT</bcp14> be in the set of sharees; their rights are implicit.</t></li> </ul> --> <t>We would also define a new Principal capability with two properties:</t><ul<dl spacing="normal" newline="true"> <dt><strong>accountId</strong>: <tt>Id|null</tt></dt> <dd>The accountId containing the todo data for this Principal, if it has been shared with the requesting user.</dd> <dt><strong>mayShareWith</strong>: <tt>Boolean</tt></dt> <dd>The user may add this Principal as a sharee of a todo list.</dd> </dl> <!--NOTE: original format--> <!--<ul spacing="compact"> <li><t><strong>accountId</strong>: <tt>Id|null</tt></t> <t>The accountId containing the todo data for this Principal, if it has been shared with the requesting user.</t></li> <li><t><strong>mayShareWith</strong>: <tt>Boolean</tt></t><t>May the<t>The user may add this Principal as a sharee of a todolist?</t></li>list.</t></li> </ul> --> <!--[rfced] Section 4.1. Figures 1-4 do not have titles. If you would like to include titles, please provide the text. --> <t>A client wishing to let the user configure sharing would look at the account capabilities for the Account containing the user's Tododata,data and find the "urn:ietf:params:jmap:principals:owner" property, as per <xref target="urn-ietf-params-jmap-principals-owner"></xref>. For example, the JMAP Session object might contain:</t><figure><artwork><figure> <sourcecode type="json"> { "accounts": { "u12345678": { "name": "jane.doe@example.com", "isPersonal": true, "isReadOnly": false, "accountCapabilities": { "urn:com.example:jmap:todo": {}, "urn:ietf:params:jmap:principals:owner": { "accountIdForPrincipal": "u33084183", "principalId": "P105aga511jaa" } } }, ... }, ...} </artwork></figure> <t>From}</sourcecode> </figure> <!--[rfced] Section 4.1. Does "it" refer to the "client" in this sentence? Please let us know if we may rephrase the text as shown below for clarity. Original: From this it now knows which account has the Principal data, and can fetch the list of Principals to offer the user to share the list with, making an API request like this: Perhaps: From this, the client now knows which account has the Principal data, and it can fetch the list of Principals and offer to share it with the user by making an API request like this: --> <t>From this, it now knows which account has the Principal data and can fetch the list of Principals to offer the user to share the list with, making an API request like this:</t><figure><artwork><figure> <sourcecode type="json"> [[ "Principal/get", { "accountId": "u33084183", "ids": null }, "0"]] </artwork></figure> <t>Here's]]</sourcecode> </figure> <!--[rfced] Section 4.1. May we update "but who has not" to "even though Joe has not" as shown below? Please let us know if the suggested update provides clarity or if you prefer otherwise. Original: Here's an example response (where Joe Bloggs is another user that this user could share their todo list with, but who has not shared any data in their own account with this user): Perhaps: Here's an example response (where "Joe Bloggs" is another user who this user could share their todo list with, even though Joe has not shared any data from its account): --> <t>Here's an example response (where "Joe Bloggs" is another user that this user could share their todo list with, but who has not shared any data in their own account with this user): </t><figure><artwork><figure> <sourcecode type="json"> [[ "Principal/get", { "accountId": "u33084183", "state": "7b8eff5zz", "list": [{ "id": "P2342fnddd20", "type": "individual", "name": "Joe Bloggs", "description": null, "email": "joe.bloggs@example.com", "timeZone": "Australia/Melbourne", "capabilities": { "urn:com.example:jmap:todo": { "accountId": null, "mayShareWith": true } }, "accounts": null }, { "id": "P674pp24095qo49pr", "name": "Board room", "type": "location", ... }, ... ], "notFound": [] }, "0"]] </artwork></figure>]]</sourcecode> </figure> <t>A todo list can be shared withJoe Bloggs"Joe Bloggs" by updating its shareWith property, as in this example request:</t><figure><artwork><figure> <sourcecode type="json"> [[ "TodoList/set", { "accountId": "u12345678", "update": { "tl01n231": { "shareWith": { "P2342fnddd20": { "mayRead": true, "mayWrite": true, "mayAdmin": false } } } } }, "0"]] </artwork></figure>]]</sourcecode> </figure> </section> </section><section><name>Internationalisation<section><name>Internationalization Considerations</name> <t>Experience has shown that unrestricted use of Unicode can lead to problems such as inconsistent rendering, users reading text and interpreting it differently than intended, and unexpected results when copying text from one location to another. ServersMAY<bcp14>MAY</bcp14> choose to mitigate this by restricting the set of characters allowed in otherwise unconstrained <tt>String</tt> fields. The FreeformClass, as documented in <xref target="RFC8264" section="4.3" sectionFormat="comma"/>/>, might be a good starting point for this.</t> <t>Attempts to set a value containing code points outside of the permissible set can be handled in a few ways by the server. The first option is to simply strip the forbidden characters and store the resulting string. This is likely to be appropriate for controlcharacterscharacters, for example, where they can end up in data accidentally due to copy-and-pasteissues,issues and are probably invisible to the end user. JMAP allows the server to transform data on create/update, as long as any changed properties are returned to the client in the <tt>/set</tt>response,response so it knows what has changed, as per <xref target="RFC8620" section="5.3" sectionFormat="comma" />. Alternatively, the serverMAY<bcp14>MAY</bcp14> just reject the create/update with an <tt>invalidProperties</tt> SetError.</t> </section> <section anchor="security-considerations"><name>Security Considerations</name> <t>All security considerations of JMAP <xref target="RFC8620"></xref> apply to this specification. Additional considerations are detailed below.</t> <section anchor="spoofing"><name>Spoofing</name> <t>Allowing users to edit their own Principal's name (and, to a lesser extent, email, description, or type) could allow a user to change their Principal to look like another user in the system, potentially tricking others into sharing private data with them. Servers may choose to forbidthis,this and <bcp14>SHOULD</bcp14> keep logs of such changes to provide an audit trail.</t> <t>Note that simply forbidding the use of a name already in the system is insufficient protection, as a malicious user could still change their name to something easily confused with the existing name by using trivial misspellings or visually similar Unicode characters.</t> </section> <section anchor="unnoticed-sharing"><name>Unnoticed Sharing</name> <t>Sharing data with another user allows someone to turn a transitory account compromise (e.g., brief access to an unlocked or logged-in client) into a persistent compromise (by setting up sharing with a user that is controlled by the attacker). This can be mitigated by requiring furtherauthorisationauthorization for configuringsharing,sharing or sending notifications to the sharer via another channel whenever a new sharee is added.</t> </section> <section anchor="dos"><name>Denial of Service</name> <t>By creating many changes to the sharing status of objects, a user can cause many ShareNotifications to be generated, which could lead to resource exhaustion. Servers can mitigate this by coalescing multiple changes to the same object into a single notification, limiting the maximum number of notifications it stores peruser,user and/orrate limitingrate-limiting the changes to sharing permissions in the first place. Automatically deleting older notifications after reaching a limit can mean the user is not made aware of a sharing change, which can itself be a security issue. For this reason, it is better to coalesce changes and use other mitigation strategies.</t> </section> <sectionanchor="unauthorised-principals"><name>Unauthorisedanchor="unauthorised-principals"><name>Unauthorized Principals</name> <t>The set of Principals within a shared environment <bcp14>MUST</bcp14> be strictly controlled. If adding a new Principal is open to the public, risks include:</t> <ul spacing="compact"> <li>An increased risk of a user accidentally sharing data with an unintended person.</li> <li>An attackermay sharesharing unwanted or offensive information with the user.</li> <li>An attackermay sharesharing items with spam content in the names in order to generate ShareNotification objects, which are likely to be prominently displayed to the sharee.</li> </ul> </section> </section> <section anchor="iana-considerations"><name>IANA Considerations</name> <!--[rfced] IANA Considerations (Section 7) Please review all of the IANA-related updates carefully and let us know if any further updates are needed. FYI: In Sections 7.1-7.4, note that we made the registrations match IANA's registrations at https://www.iana.org/assignments/jmap/. --> <section anchor="jmap-capability-registration-for-principals"><name>JMAP Capability Registration for "principals"</name> <t>IANAwill registerhas registered the "principals" JMAP Capability in the "JMAP Capabilities" registry as follows:</t><t>Capability Name: <tt>urn:ietf:params:jmap:principals</tt></t> <t>Specification document: this document</t> <t>Intended use: common</t> <t>Change Controller: IETF</t> <t>Security<dl newline="false" spacing="compact"> <dt>Capability Name:</dt> <dd><tt>urn:ietf:params:jmap:principals</tt></dd> <dt>Intended Use:</dt> <dd>common</dd> <dt>Change Controller:</dt> <dd>IETF</dd> <dt>Security andprivacy considerations: this document,Privacy Considerations:</dt> <dd>RFC 9670, <xref target="security-considerations"/></t>/></dd> <dt>Reference:</dt> <dd>RFC 9670</dd> </dl> </section> <section anchor="jmap-capability-registration-for-principals-owner"><name>JMAP Capability Registration for "principals:owner"</name> <t>IANAwill registerhas registered the "principals:owner" JMAP Capability in the "JMAP Capabilities" registry as follows:</t><t>Capability Name: <tt>urn:ietf:params:jmap:principals:owner</tt></t> <t>Specification document: this document</t> <t>Intended use: common</t> <t>Change Controller: IETF</t> <t>Security<dl newline="false" spacing="compact"> <dt>Capability Name:</dt> <dd><tt>urn:ietf:params:jmap:principals:owner</tt></dd> <dt>Intended Use:</dt> <dd>common</dd> <dt>Change Controller:</dt> <dd>IETF</dd> <dt>Security andprivacy considerations: this document,Privacy Considerations:</dt> <dd>RFC 9670, <xref target="security-considerations"/></t>/></dd> <dt>Reference:</dt> <dd>RFC 9670</dd> </dl> </section> <section anchor="jmap-data-type-registration-for-principal"><name>JMAP Data Type Registration for "Principal"</name> <t>IANAwill registerhas registered the "Principal" JMAP Data Type in the "JMAP Data Types" registry as follows:</t><t>Type Name: <tt>Principal</tt></t> <t>Can reference blobs: no</t> <t>Can<dl newline="false" spacing="compact"> <dt>Type Name:</dt> <dd><tt>Principal</tt></dd> <dt>Can Reference Blobs:</dt> <dd>No</dd> <dt>Can Use for StateChange: yes</t> <t>Capability: <tt>urn:ietf:params:jmap:principals</tt></t> <t>Specification document: this document</t>Change:</dt> <dd>Yes</dd> <dt>Capability:</dt> <dd><tt>urn:ietf:params:jmap:principals</tt></dd> <dt>Reference:</dt> <dd>RFC 9670</dd> </dl> </section> <section anchor="jmap-data-type-registration-for-sharenotification"><name>JMAP Data Type Registration for "ShareNotification"</name> <t>IANAwill registerhas registered the "ShareNotification" JMAP Data Type in the "JMAP Data Types" registry as follows:</t><t>Type Name: <tt>ShareNotification</tt></t> <t>Can reference blobs: no</t> <t>Can<dl newline="false" spacing="compact"> <dt>Type Name:</dt> <dd><tt>ShareNotification</tt></dd> <dt>Can Reference Blobs:</dt> <dd>No</dd> <dt>Can Use for StateChange: yes</t> <t>Capability: <tt>urn:ietf:params:jmap:principals</tt></t> <t>Specification document: this document</t>Change:</dt> <dd>Yes</dd> <dt>Capability:</dt> <dd><tt>urn:ietf:params:jmap:principals</tt></dd> <dt>Reference:</dt> <dd>RFC 9670</dd> </dl> </section> </section> </middle> <back> <references> <name>References</name> <references><name>Normative References</name> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8620.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8620.xml"/> </references> <references><name>Informative References</name> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8264.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8264.xml"/> <!--NOTE: IANA reference entry below in case the authors decide to use it instead of the URL in the running text. <reference anchor="IANA-TZDB" target="https://www.iana.org/time-zones"> <front> <title>Time Zone Database</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> --> </references> </references> </back> <!-- [rfced] The files below list terms enclosed in <tt>, <em>, and <strong>, respectively, in this document. Please review to ensure the usage of these attributes is correct and consistent. Let us know if any updates are needed. https://www.rfc-editor.org/authors/rfc9670-TT.txt https://www.rfc-editor.org/authors/rfc9670-EM.txt https://www.rfc-editor.org/authors/rfc9670-ST.txt Specifically, please review the following terms that appear both inside and outside of <tt> tags and sometimes <strong> tags: Accounts vs. accounts vs. <tt>accounts</tt> forbidden vs. <tt>forbidden</tt> group vs. <tt>group</tt> ID vs. id vs. <tt>Id</tt> individual vs. <tt>individual</tt> location vs. <tt>location</tt> myRights vs. <tt>myRights</tt> vs. <strong>myRights</strong> null vs. <tt>null</tt> <tt>other</tt> Principal vs. <tt>Principal</tt> TodoListRights vs. <tt>TodoListRights</tt> --> <!-- [rfced] For the terms related to "todo", we spotted several variations of capitalization and formatting. Please review and let us know if/how we can make these consistent. Should the lowercase forms of "todo" perhaps be capital? todo list TodoList TodoList data type Todo data type Todo data vs. todo data Todos vs. todos --> <!-- [rfced] FYI - we updated the artwork elements to sourcecode with the type set to "json". Please review the XML file to ensure correctness. Note that the current list of preferred values for "type" is listed at <https://www.rfc-editor.org/materials/sourcecode-types.txt>. It is also acceptable to leave the "type" attribute not set. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>