Summary: Has a DISCUSS. Needs 7 more YES or NO OBJECTION positions to pass.
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4198 IMPORTANT: It's a bit hard to tell what the server is required to do. Which of the many properties of emails (headers, the like) is the server required to provide? DETAIL S 2. > > * *mayReadItems*: "Boolean" If true, the user may use this > mailbox as part of a filter in a _Email/query_ call and the > mailbox may be included in the _mailboxIds_ set of _Email_ > objects. If a sub-mailbox is shared but not the parent > mailbox, this may be "false". Corresponds to IMAP ACLs "lr". This doesn't have any impact on Email/get? that seems odd.
S 2. > A *Mailbox* object has the following properties: > > o *id*: "Id" (immutable; server-set) The id of the mailbox. > > o *name*: "String" User-visible name for the mailbox, e.g. "Inbox". > This may be any Net-Unicode string ([RFC5198]) of at least 1 MAY? S 2. > > o *role*: "String|null" (default: null) Identifies mailboxes that > have a particular common purpose (e.g. the "inbox"), regardless of > the _name_ (which may be localised). This value is shared with > IMAP (exposed in IMAP via the [RFC6154] SPECIAL-USE extension). > However, unlike in IMAP, a mailbox may only have a single role, MUST only S 2. > o *totalEmails*: "PositiveInt" (server-set) The number of emails in > this mailbox. > > o *unreadEmails*: "PositiveInt" (server-set) The number of emails in > this mailbox that have neither the "$seen" keyword nor the > "$draft" keyword. This is the first appearance of "keyword" in this document. Please provide some explanation of what that means before this. S 2. > o *totalThreads*: "PositiveInt" (server-set) The number of threads > where at least one email in the thread is in this mailbox. > > o *unreadThreads*: "PositiveInt" (server-set) An indication of the > number of "unread" threads in the mailbox. This may be presented > by the client as a badge or marker associated with the mailbox. I know we're in 8174-land, but it seems to me that this may is a bit confusing in any case. The client can do anything it wants with this at all, right? S 4.1. > list rather than a single part as messages may have headers and/or > footers appended/prepended as separate parts as they are > transmitted, and some clients send text and images intended to be > displayed inline in the body (or even videos and sound clips) as > multiple parts rather than a single HTML part with referenced > images. Does the server have to supply this? It seems like it's a bit of a pain if you don't otherwise have a bunch of MIME-parsing machiner. S 4.1.1. > properties is specified over the following three sub-sections. > > 4.1.1. Metadata > > These properties represent metadata about the [RFC5322] message, and > are not derived from parsing the message itself. As above, is the server required to supply all of these? S 18.104.22.168. > > o Resent-Cc > > o Resent-Bcc > > o Any header not defined in [RFC5322] or [RFC2369] Can this list be updated in the future? If so, how? S 9.2. > > Subtle differences in parsing of HTML can introduce security flaws: > to filter with 100% accuracy you need to use the same parser when > sanitizing that the HTML rendering engine will use. > > o Encapsulating the message in an "<iframe sandbox>" can help You need a reference to this.