You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by rc...@apache.org on 2020/07/30 08:27:18 UTC
[james-project] 06/08: JAMES-3099 Annotate JMAP RFC-8621 mail
specifications
This is an automated email from the ASF dual-hosted git repository.
rcordier pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/james-project.git
commit c9ccd9f0a8b29fdd2da45e52abe342a450e5c74c
Author: Rene Cordier <rc...@linagora.com>
AuthorDate: Tue Jul 28 16:34:08 2020 +0700
JAMES-3099 Annotate JMAP RFC-8621 mail specifications
---
.../doc/specs/spec/mail/identity.mdown | 4 ++++
.../jmap-rfc-8621/doc/specs/spec/mail/intro.mdown | 28 ++++++++++++++++++++++
.../doc/specs/spec/mail/mailbox.mdown | 20 ++++++++++++++++
.../doc/specs/spec/mail/message.mdown | 4 ++++
.../doc/specs/spec/mail/messagesubmission.mdown | 4 ++++
.../doc/specs/spec/mail/searchsnippet.mdown | 4 ++++
.../jmap-rfc-8621/doc/specs/spec/mail/thread.mdown | 4 ++++
.../doc/specs/spec/mail/vacationresponse.mdown | 4 ++++
8 files changed, 72 insertions(+)
diff --git a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/identity.mdown b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/identity.mdown
index be3f64b..c1b8431 100644
--- a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/identity.mdown
+++ b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/identity.mdown
@@ -1,5 +1,9 @@
# Identities
+<aside class="warning">
+ Not implemented yet
+</aside>
+
An **Identity** object stores information about an email address or domain the user may send from. It has the following properties:
- **id**: `Id` (immutable; server-set)
diff --git a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/intro.mdown b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/intro.mdown
index 006ce4c..05691e3 100644
--- a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/intro.mdown
+++ b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/intro.mdown
@@ -50,17 +50,33 @@ This document defines three additional capability URIs.
### urn:ietf:params:jmap:mail
+<aside class="notice">
+ Implemented
+</aside>
+
This represents support for the Mailbox, Thread, Email, and SearchSnippet data types and associated API methods. The value of this property in the JMAP session *capabilities* property is an empty object.
The value of this property in an account's *accountCapabilities* property is an object that MUST contain the following information on server capabilities and permissions for that account:
- **maxMailboxesPerEmail**: `UnsignedInt|null`
+<aside class="warning">
+ Not enforced yet
+</aside>
The maximum number of Mailboxes (see Section 2) that can be can assigned to a single Email object (see Section 4). This MUST be an integer >= 1, or `null` for no limit (or rather, the limit is always the number of Mailboxes in the account).
- **maxMailboxDepth**: `UnsignedInt|null`
+<aside class="warning">
+ Not enforced yet
+</aside>
The maximum depth of the Mailbox hierarchy (i.e., one more than the maximum number of ancestors a Mailbox may have), or `null` for no limit.
- **maxSizeMailboxName**: `UnsignedInt`
+<aside class="warning">
+ Not enforced yet
+</aside>
The maximum length, in (UTF-8) octets, allowed for the name of a Mailbox. This MUST be at least 100, although it is recommended servers allow more.
- **maxSizeAttachmentsPerEmail**: `UnsignedInt`
+<aside class="warning">
+ Not enforced yet
+</aside>
The maximum total size of attachments, in octets, allowed for a single Email object. A server MAY still reject the import or creation of an Email with a lower attachment size total (for example, if the body includes several megabytes of text, causing the size of the encoded MIME structure to be over some server-defined limit).
Note that this limit is for the sum of unencoded attachment sizes. Users are generally not knowledgeable about encoding overhead, etc., nor should they need to be, so marketing and help materials normally tell them the "max size attachments". This is the unencoded size they see on their hard drive, so this capability matches that and allows the client to consistently enforce what the user understands as the limit.
@@ -75,6 +91,10 @@ The value of this property in an account's *accountCapabilities* property is an
### urn:ietf:params:jmap:submission
+<aside class="warning">
+ Not implemented yet
+</aside>
+
This represents support for the Identity and EmailSubmission data types and associated API methods. The value of this property in the JMAP session *capabilities* property is an empty object.
The value of this property in an account's *accountCapabilities* property is an object that MUST contain the following information on server capabilities and permissions for that account:
@@ -103,6 +123,10 @@ The value of this property in an account's *accountCapabilities* property is an
### urn:ietf:params:jmap:vacationresponse
+<aside class="warning">
+ Not implemented yet
+</aside>
+
This represents support for the VacationResponse data type and associated API methods. The value of this property is an empty object in both the JMAP session *capabilities* property and an account's *accountCapabilities* property.
## Data Type Support in Different Accounts
@@ -111,6 +135,10 @@ The server MUST include the appropriate capability strings as keys in the *accou
## Push
+<aside class="warning">
+ Not implemented yet
+</aside>
+
Servers MUST support the JMAP push mechanisms, as specified in [@!RFC8620] Section 7, to receive notifications when the state changes for any of the types defined in this specification.
In addition, servers that implement the "urn:ietf:params:jmap:mail" capability MUST support pushing state changes for a type called "EmailDelivery". There are no methods to act on this type; it only exists as part of the push mechanism. The state string for this MUST change whenever a new Email is added to the store, but it SHOULD NOT change upon any other change to the Email objects, for example, if one is marked as read or deleted.
diff --git a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/mailbox.mdown b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/mailbox.mdown
index d144ca6..b92eee3 100644
--- a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/mailbox.mdown
+++ b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/mailbox.mdown
@@ -5,6 +5,9 @@ A Mailbox represents a named set of Emails. This is the primary mechanism for or
For compatibility with IMAP, an Email MUST belong to one or more Mailboxes. The Email id does not change if the Email changes Mailboxes.
A **Mailbox** object has the following properties:
+<aside class="notice">
+ Implemented
+</aside>
- **id**: `Id` (immutable; server-set)
The id of the Mailbox.
@@ -13,6 +16,10 @@ A **Mailbox** object has the following properties:
- **parentId**: `Id|null` (default: null)
The Mailbox id for the parent of this Mailbox, or `null` if this Mailbox is at the top level. Mailboxes form acyclic graphs (forests) directed by the child-to-parent relationship. There MUST NOT be a loop.
- **role**: `String|null` (default: null)
+ <aside class="warning">
+ Partially implemented. Role are based on the name of the mailbox. An evolution would be to use a mailbox annotation to hold its
+ value, removing the link with the name, and allow the user to define locale based system mailboxes. This value cannot be updated.
+ </aside>
Identifies Mailboxes that have a particular common purpose (e.g., the "inbox"), regardless of the *name* property (which may be localised).
This value is shared with IMAP (exposed in IMAP via the SPECIAL-USE extension [@!RFC6154]). However, unlike in IMAP, a Mailbox MUST only have a single role, and there MUST NOT be two Mailboxes in the same account with the same role. Servers providing IMAP access to the same data are encouraged to enforce these extra restrictions in IMAP as well. Otherwise, modifying the IMAP attributes to ensure compliance when exposing the data over JMAP is implementation dependent.
@@ -22,6 +29,9 @@ A **Mailbox** object has the following properties:
An account is not required to have Mailboxes with any particular roles.
- **sortOrder**: `UnsignedInt` (default: 0)
+ <aside class="warning">
+ Partially implemented. Based on the role. This value cannot be updated.
+ </aside>
Defines the sort order of Mailboxes when presented in the client's UI, so it
is consistent between devices. The number MUST be an integer in the range
0 <= sortOrder < 2^31.
@@ -33,8 +43,14 @@ A **Mailbox** object has the following properties:
- **unreadEmails**: `UnsignedInt` (server-set)
The number of Emails in this Mailbox that have neither the `$seen` keyword nor the `$draft` keyword.
- **totalThreads**: `UnsignedInt` (server-set)
+ <aside class="warning">
+ Threads are not implemented. So far, each email is its own thread, so totalThreads will have the same value than totalEmails
+ </aside>
The number of Threads where at least one Email in the Thread is in this Mailbox.
- **unreadThreads**: `UnsignedInt` (server-set)
+ <aside class="warning">
+ Threads are not implemented. So far, each email is its own thread, so unreadThreads will have the same value than unreadEmails
+ </aside>
An indication of the number of "unread" Threads in the Mailbox.
For compatibility with existing implementations, the way "unread Threads" is
@@ -84,6 +100,10 @@ The following JMAP methods are supported.
## Mailbox/get
+<aside class="notice">
+ Implemented
+</aside>
+
This is a standard "/get" method as described in [@!RFC8620], Section 5.1. The *ids* argument may be `null` to fetch all at once.
## Mailbox/changes
diff --git a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/message.mdown b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/message.mdown
index 285fc80..126f421 100644
--- a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/message.mdown
+++ b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/message.mdown
@@ -1,5 +1,9 @@
# Emails
+<aside class="warning">
+ Not implemented yet
+</aside>
+
An **Email** object is a representation of a message [@!RFC5322], which allows clients to avoid the complexities of MIME parsing, transfer encoding, and character encoding.
## Properties of the Email Object
diff --git a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/messagesubmission.mdown b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/messagesubmission.mdown
index 71f8718..2609aeb 100644
--- a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/messagesubmission.mdown
+++ b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/messagesubmission.mdown
@@ -1,5 +1,9 @@
# Email Submission
+<aside class="warning">
+ Not implemented yet
+</aside>
+
An **EmailSubmission** object represents the submission of an Email for delivery to one or more recipients. It has the following properties:
- **id**: `Id` (immutable; server-set)
diff --git a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/searchsnippet.mdown b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/searchsnippet.mdown
index 7d83411..299a625 100644
--- a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/searchsnippet.mdown
+++ b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/searchsnippet.mdown
@@ -1,5 +1,9 @@
# Search Snippets
+<aside class="warning">
+ Not implemented
+</aside>
+
When doing a search on a `String` property, the client may wish to show the relevant section of the body that matches the search as a preview and to highlight any matching terms in both this and the subject of the Email. Search snippets represent this data.
A **SearchSnippet** object has the following properties:
diff --git a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/thread.mdown b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/thread.mdown
index 13b9589..f32556f 100644
--- a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/thread.mdown
+++ b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/thread.mdown
@@ -1,5 +1,9 @@
# Threads
+<aside class="warning">
+ Not implemented yet
+</aside>
+
Replies are grouped together with the original message to form a Thread. In JMAP, a Thread is simply a flat list of Emails, ordered by date. Every Email MUST belong to a Thread, even if it is the only Email in the Thread.
The exact algorithm for determining whether two Emails belong to the same Thread is not mandated in this spec to allow for compatibility with different existing systems. For new implementations, it is suggested that two messages belong in the same Thread if both of the following conditions apply:
diff --git a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/vacationresponse.mdown b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/vacationresponse.mdown
index 8639ea2..bc425f2 100644
--- a/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/vacationresponse.mdown
+++ b/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/vacationresponse.mdown
@@ -1,5 +1,9 @@
# Vacation Response
+<aside class="warning">
+ Not implemented yet
+</aside>
+
A vacation response sends an automatic reply when a message is delivered to the mail store, informing the original sender that their message may not be read for some time.
Automated message sending can produce undesirable behaviour. To avoid this, implementors MUST follow the recommendations set forth in [@!RFC3834].
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org