The JSON Meta Application Protocol (JMAP) for Mail
draft-ietf-jmap-mail-16
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-08-01
|
16 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-06-17
|
16 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-05-20
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-04-29
|
16 | (System) | RFC Editor state changed to REF from EDIT |
2019-04-03
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-04-03
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2019-03-28
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-03-26
|
16 | (System) | IANA Action state changed to In Progress from On Hold |
2019-03-23
|
16 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-03-15
|
16 | (System) | IANA Action state changed to On Hold from In Progress |
2019-03-11
|
16 | (System) | RFC Editor state changed to MISSREF |
2019-03-11
|
16 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-03-11
|
16 | (System) | Announcement was received by RFC Editor |
2019-03-11
|
16 | (System) | IANA Action state changed to In Progress |
2019-03-11
|
16 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-03-11
|
16 | Amy Vezza | IESG has approved the document |
2019-03-11
|
16 | Amy Vezza | Closed "Approve" ballot |
2019-03-11
|
16 | Amy Vezza | Ballot approval text was generated |
2019-03-08
|
16 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-03-08
|
16 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my DISCUSS (and COMMENT!) points! |
2019-03-08
|
16 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-03-07
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-03-07
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-03-07
|
16 | Neil Jenkins | New version available: draft-ietf-jmap-mail-16.txt |
2019-03-07
|
16 | (System) | New version approved |
2019-03-07
|
16 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2019-03-07
|
16 | Neil Jenkins | Uploaded new revision |
2019-03-07
|
15 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2019-03-07
|
15 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-03-06
|
15 | Eric Rescorla | [Ballot comment] Thank you for addressing my DISCUSS |
2019-03-06
|
15 | Eric Rescorla | [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss |
2019-03-06
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-03-05
|
15 | Ben Campbell | [Ballot comment] Thanks for addressing most of my comments. I have one remaining: Please expand JMAP in the title and in the abstract. |
2019-03-05
|
15 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2019-03-04
|
15 | Benjamin Kaduk | [Ballot discuss] Length of review comments aside, this is actually a quite nice document -- thank you to the authors for making it so clear … [Ballot discuss] Length of review comments aside, this is actually a quite nice document -- thank you to the authors for making it so clear and well-organized. The only readability complaint I have is that I don't get a great picture of how all the bits of the Email object fit together, but it's complicated enough that maybe a generic schema wouldn't actually be helpful. Section 2 I think we need more precise language than "corresponds to" for the relationship between JMAP MailboxRights and IMAP ACLs, specifically because JMAP distinguishes mayRename and mayDelete but IMAP just has the single 'x' ACL. (More in the COMMENT section, but the non-isomporphic mapping of 'x' is the only DISCUSS-worthy part.) Section 4.1.1 We only describe the "\" to "$" translation for the four supported system keywords, but it seems that it should be more generic (not that we expect more IMAP system keywords to appear anytime soon)? Section 4.1.2.1 A server SHOULD replace any octet or octet run with the high bit set that violates UTF-8 syntax with the unicode replacement character (U+FFFD). [...] This seems problematic, given that this is supposed to be the "Raw" format. I guess the justification for the replacement is that we use JSON and JSON requires UTF-8, but if that's the case then shouldn't this be a MUST and not a SHOULD? In particular, a client can't rely on the server providing the SHOULD, so it doesn't seem to provide much value. Section 4.7 The server MAY forbid two email objects with the same exact [RFC5322] content, or even just with the same [RFC5322] Message-ID, to coexist within an account; if the target account already has the email the copy will be rejected with a standard "alreadyExists" error. This has some security considerations that should probably be mentioned in Section 9.4: when a user only has read privileges to a subset of the folders in an account, this behavior can be abused as an oracle to determine whether a given message exists in the inaccessible portions of that account. (Similarly for /import.) Section 4.9 The following metadata properties on the Email objects will be "null" if requested: [...] o mailboxIds This seems in conflict with the Section 4.1.1 text that every Email "MUST belong to one or more mailboxes at all times (until it is deleted)." Presumably we want a broader disclaimer in 4.1.1 rather than any changes here... There may also be a related condition wherein an EmailSubmission object refers to an Email after the Email is deleted -- I didn't (yet) see text to indicate whether the emailId in the EmailSubmission is expected to still be resolvable, in which case there would potentially not be an associated Mailbox. Section 9.3 It's 2019. Why are we still recommending SASL PLAIN? We have better options even if we are resigned to passwords, like SCRAM. |
2019-03-04
|
15 | Benjamin Kaduk | [Ballot comment] Section 1.3.1 o *maxMailboxesPerEmail*: "UnsignedInt|null" The maximum number of mailboxes that can be can assigned to a single email. … [Ballot comment] Section 1.3.1 o *maxMailboxesPerEmail*: "UnsignedInt|null" The maximum number of mailboxes that can be can assigned to a single email. [...] nit: My understanding (shaped solely by experience and inference) is that "email" is generally used to refer to a message, whereas "email account" or "email address" would be used to refer to or associate with a thing that can be a container for folders. o *maxSizeMailboxName*: "UnsignedInt" 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. The Unicode normalization form used by client/server could cause disagreement about whether a given name is permitted, though for the type of use this will get it's not clear that we need to be more rigorous. Section 1.3.2 o *submissionExtensions*: "String[String[]]" A JMAP implementation that talks to a Submission [RFC6409] server SHOULD have a configuration setting that allows an administrator to expose a new submission EHLO capability in this field. This allows a JMAP I think I'm confused by the workflow here. Suppose we have a JMAP client A talking to a JMAP server B, and B is also an SMTP client that talks to MTA C. This capability is supposed to be about letting B expose a new EHLO capability to A, but only when C supports it? We probably need some more text here to explain the scenario, even if my guess is correct. server to gain access to a new submission extension without code changes. By default, the JMAP server should hide EHLO capabilities that are to do with the transport mechanism and thus are only relevant to the JMAP server (for example PIPELINING, CHUNKING, or STARTTLS). Each key in the object is the _ehlo- name_, and the value is a list of _ehlo-args_. Examples of Submission extensions to include: The description here could probably be reworded/reorderd for clarity, since we don't start talking about what the actual map keys/values are until the penultimate sentence, at present. Section 1.5 In addition, servers MUST support pushing state changes for a type called "EmailDelivery". [...] Er, is this only servers that are implementing urn:ietf:params:jmap:mail? Or is the bit about "Servers MUST support all properties specified for the new data types defined in this document" supposed to imply that I have to implement all three as a unit, even if not all of them are going to be available for every account/credentials? Section 2 o *id*: "Id" (immutable; server-set) The id of the mailbox. Since jmap-core now has all Ids as immutable and server-set, is this sort of notation considered redundant in jmap-mail? (Throughout; this is just the first instance.) o *role*: "String|null" (default: null) Identifies mailboxes that [...] same role. Servers providing IMAP access to the same data are encouraged to enforce these extra restrictions in IMAP as well. Otherwise, it is implementation dependent how to modify the IMAP attributes to ensure compliance when exposing the data over JMAP. If we had a "see also" document relation, this might justify one from IMAP to here. It probably doesn't qualify for Updates: though. Nonetheless, I'd consider having a top-level "Updates Affecting IMAP" section like RFC 8446 did for TLS 1.2, to collect all the bits that someone deploying IMAP and JMAP together might need to think about for their IMAP implementation. o *sortOrder*: "UnsignedInt" (default: 0) Defines the sort order of [...] equal order SHOULD be sorted in alphabetical order by name. The sorting SHOULD take into account locale-specific character order convention. I think this last SHOULD is probably not a 2119 SHOULD, and therefore should just be "should". o *unreadThreads*: "UnsignedInt" (server-set) An indication of the number of "unread" threads in the mailbox. For compatibility with existing implementations, the way "unread threads" is determined is not mandated in this document. The simplest solution to Do we really have competing *J*MAP implementations that disagree on this? Or is the idea to preserve compatibility with IMAP clients or other current implementations that attempt to determine threading relationships (in which case, that should probably be mentioned)? o *myRights*: "MailboxRights" (server-set) The set of rights (ACLs) the user has in relation to this mailbox. These are backwards compatible with IMAP ACLs, as defined in [RFC4314]. A _MailboxRights_ object has the following properties: I read this as saying that all of the properties must be present in the object, such that omitting a property is not a permitted synonym for it having a value of false. Is this reading correct? If so, what should a client do if the server misbehaves? * *mayReadItems*: "Boolean" If true, the user may use this [...] but not the parent mailbox, this may be "false". Corresponds to IMAP ACLs "lr". "Corresponds to" is perhaps imprecise, if one is thinking about the IMAP ACL as being the authoritative source of information (which not all readers will!). The point being that just 'l' or just 'r' would not be enough to get this, and since JMAP is specifying a slightly more abstract mapping than standard IMAP rights, we should be precise about the mapping, and arguably in both directions. (Not just here, but for all the compound ACLs, of course. Also for IMAP ACL 'x', which has two corresponding JMAP permissions.) * *maySetSeen*: "Boolean" The user may add or remove the "$seen" keyword to/from an email. If an email belongs to multiple mailboxes, the user may only modify "$seen" if *all* of the mailboxes have this permission. Corresponds to IMAP ACL "s". nit: in the intro, we talk of "rights the user has in relation to this mailbox", so it's a bit disjoint to talk of mailboxes having permissons. (Here and below.) o *isSubscribed*: "Boolean" Has the user indicated they wish to see [...] choose to ignore this property, either entirely for ease of implementation, or just for the primary account (which is normally nit: We don't really provide a formal definition of "primary account" either here or in jmap-core. Section 2.1 Standard "/get" method. The _ids_ argument may be "null" to fetch I thought I had said something on jmap-core but maybe I only thought about it: my personal preference would be for section references into jmap-core to provide a foundation for what the "standard method" is, though I will not insist upon it. all at once. (Also, this behavior is part of the standard method now.) Section 2.2 I might say explicitly that "a non-null updatedProperties response argument indicates that the mailbox contents are unchanged from the old state, with only the counts having changed", since these semantics are potentially unexpected. Section 2.3 Standard "/query" method, but with the following additional argument: (Generic comment, not scoped to just this section): are we going to need to draw a distinction between input and ouput arguments for any of the additions we make to standard methods? o *role*: "String|null" The Mailbox _role_ property must match the given value exactly. So the client is responsible for lower-casing values from the IMAP Mailbox Name Attributes registry and the server must not do a case-insensitive comparison? The following properties MUST be supported for sorting: Just to be pedantic, we're talking about the values of the "property" property within the Comparator object, right? (This is one of those annoying things at the intersection of technical specifications and natural English language.) Section 4 Due to the number of properties involved, the set of _Email_ properties is specified over the following three sub-sections. It's probably worth a note that the subsections are for purposes of document organization and are not reflected in the wire protocol structure -- the properties involved are all top-level peers, across the three subsections. (Assuming that's correct, of course.) Section 4.1 I assume it was a conscious WG decision to not present a full consolidated schema for Email. But I want to check, since I think (not having one) that it would have helped my understanding, and I try to be open to discovering the errors of my ways... o _textBody_/_htmlBody_: These provide a list of parts that should be rendered sequentially as the "body" of the message. This is a 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. Some guidance related to interpreting these lists and avoiding the eFail (efail.de) class of attacks is probably in order -- the HTML parts should get some different containers around their processing. This could potentially go here, or in Section 9.2. Because MIME allows for multiple representations of the same data (using "multipart/alternative"), there is a textBody property (which prefers a plain text representation) and an htmlBody property (which prefers an HTML representation) to accommodate the two most common client requirements. The same part may appear in both lists where there is no alternative between the two. (soapbox) It's annoying when I get mime/multipart with HTML in the text/plain section. Is this clause going to allow for that same sort of misclassification? Due to the number of properties involved, the set of _Email_ properties is specified over the following three sub-sections. nit: are we at four sub-sections now? Section 4.1.1 The IMAP "\Recent" keyword is not exposed via JMAP. The IMAP "\Deleted" keyword is also not present: IMAP uses a delete+expunge model, which JMAP does not. Any message with the "\Deleted" keyword MUST NOT be visible via JMAP (including as part of any mailbox counts). Users may add arbitrary keywords to an email. IIRC, Trash gets special handling with respect to deletion in JMAP commands; does it also get special treatment w.r.t \Deleted translation from IMAP to JMAP? Section 4.1.2.2 This escape valve for "Any header not defined in [RFC5322] or [RFC2369]" (here, et seq) seems like it might benefit from some general guidance about implementations applying common sense, i.e., allowing servers the ability to deny requests for a given form for such new headers in order to prevent nonsense behavior. Section 4.1.4 o *partId*: "String|null" Identifies this part uniquely within the Email. This is scoped to the _emailId_ and has no meaning outside of the JMAP Email object representation. This is "null" if, and only if, the part is of type "multipart/*". The prose isn't the super-best indicator that the asterisk is intended to have wildcarding behavior. Section 4.4.1 Just to double-check: the different fencepost behavior for minSize/maxSize is intentional? o *text*: "String" Looks for the text in emails. The server SHOULD look up text in the _from_, _to_, _cc_, _bcc_, _subject_ header fields of the message, and inside any "text/*" or other body parts that may be converted to text by the server. The server MAY extend the search to any additional textual property. side note: as a mail user, I like to be able to use text search to conclusively determine that a given message/topic is *not* in a given mailbox. This weak "SHOULD" language does not provide me that guarantee, though I can see how it makes sense in the protocol design to leave the flexibility for implementors, here. o When searching inside a "text/html" body part, any text considered markup rather than content SHOULD be ignored, including HTML tags and most attributes, anything inside the "" tag, CSS and JavaScript. Attribute content intended for presentation to the user such as "alt" and "title" SHOULD be considered in the search. This would seem to leave no reliable way for a security researcher to (e.g.) search for snippets of attack javascript in received mails without downloading all of them. o Text SHOULD be matched in a case-insensitive manner. Is the server going to have a sense of the user's locale as needed for fully generic case-insensitive comparison? o Tokens MAY be matched on a whole-word basis using stemming (so for example a text search for "bus" would match "buses" but not "business"). I think this is supposed to not apply to the "phrase search" two bullets above, but greater clarity would be appreciated. o *hasKeyword* - This value MUST be considered "true" if the email has the keyword given as an additional _keyword_ property on the _Comparator_ object, or "false" otherwise. I strongly suggest an explicit listing of the "additional properties as reuqired for specific sort operations" of the _Comparator_ type when used for Emails. Section 4.6 When emptying the trash, clients SHOULD NOT destroy emails which are also in a mailbox other than trash. For those emails, they SHOULD just remove the Trash mailbox from the email. This last SHOULD seems to be duplicated in Section 2. For successfully created Email objects, the _created_ response contains the _id_, _blobId_, _threadId_ and _size_ properties of the object. For partial drafts, the behavior where a threadId always gets assigned on first touch is perhaps interesting, as subsequent edits might cause the effective threading to change, which would necessitate a new Id as well (IIUC). I'm not sure if there's anything weird there that a client would need to be prepared for, though. (Maybe not, given that it always is going to get back an _id_ from /set, and should be using that.) Section 4.8 If the blob referenced is not a valid [RFC5322] message, the server MAY modify the message to fix errors (such as removing NUL octets or fixing invalid headers). If it does this, the _blobId_ on the response MUST represent the new representation and therefore be different to the _blobId_ on the EmailImport object. Alternatively, the server MAY reject the import with an "invalidEmail" SetError. In general, having more options like this can increase the fragility of the ecosystem, as a client might be written to assume one behvaior and then be not as portable to a different server. I'm not sure that there's a clear way to mandate a single type of behavior here, but want to be sure that the topic was discussed. Section 6 o *email*: "String" (immutable) The "From" email address the client MUST use when creating a new message from this identity. The value MAY alternatively be of the form "*@example.com", in which case the client may use any valid email address ending in "@example.com". I mostly assume this is supposed to be for a generic domain and not special-casing example.com literally. Some extra text/formatting would help with that. Section 7.3 The associated identityId is not a queriable property? Section 7.5 o *onSuccessUpdateEmail*: "Id[Email]|null" A map of _EmailSubmission id_ to an object containing properties to update on the Email object referenced by the EmailSubmission if the create/update/ destroy succeeds. (For references to EmailSubmission creations, this is equivalent to a back-reference so the id will be the creation id prefixed with a "#".) I'm confused by the "Id[Email]" part -- we describe it as a map to "an object containing properties to update", but that's not exactly what an Email object is. Is this more of a PatchObject than an Email per se? nit: I'd also tweak the wording of the parenthetical a bit (here and below), to something like "when applying to EmailSubmissions created in the same "/set" invocation, ..." Section 8 By a literal reading, fromDate and toDate are in conflict with each other (when non-null). That is, the fromDate text does not admit the possibility of an end to the vacation response period, and vice versa. Section 9 I'd consider adding another sentence like "Additional considerations specific to the data types and functionality introduced by this document are described in the following subsections." Section 9.3 I know we don't want this to devolve into a generic discussion of the flaws of email, but perhaps the envelope-from/body-from distinction is worth repeating, with a note that JMAP has provisions for ACLs on submission that check both. |
2019-03-04
|
15 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-03-01
|
15 | Adam Roach | [Ballot comment] Thanks for addressing my discuss and comments! |
2019-03-01
|
15 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
2019-03-01
|
15 | Alexey Melnikov | Telechat date has been changed to 2019-03-07 from 2019-02-21 |
2019-02-28
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-02-28
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-02-28
|
15 | Neil Jenkins | New version available: draft-ietf-jmap-mail-15.txt |
2019-02-28
|
15 | (System) | New version approved |
2019-02-28
|
15 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2019-02-28
|
15 | Neil Jenkins | Uploaded new revision |
2019-02-21
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-02-21
|
14 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom. |
2019-02-21
|
14 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-02-21
|
14 | Adam Roach | [Ballot discuss] Thanks to everyone who worked on this document. I found it well-organized and easy to read. --------------------------------------------------------------------------- See my DISCUSS on draft-ietf-jmap-mail regarding … [Ballot discuss] Thanks to everyone who worked on this document. I found it well-organized and easy to read. --------------------------------------------------------------------------- See my DISCUSS on draft-ietf-jmap-mail regarding the issues that can arise from normatively referencing the WHATWG HTML document. Consider citing https://www.w3.org/TR/html52/ instead. |
2019-02-21
|
14 | Adam Roach | [Ballot comment] ID Nits Reports: -- The draft header indicates that this document updates RFC5788, but the abstract doesn't seem to … [Ballot comment] ID Nits Reports: -- The draft header indicates that this document updates RFC5788, but the abstract doesn't seem to mention this, which it should. --------------------------------------------------------------------------- §1.1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. Please use the boilerplate from RFC 8174. --------------------------------------------------------------------------- §2: > However, unlike in IMAP, a mailbox may only have a single role, > and no two mailboxes in the same account may have the same role. I get the impression that JMAP for mail is intended to be implementable as a façade on top of a normal IMAP server. It is very unclear how such an implementation is able to fulfill this requirement when the IMAP server has multiple mailboxes marked as, say, "Sent". Please add guidance. --------------------------------------------------------------------------- §2.3: > A Mailbox object matches the filter if and only if all of the given > conditions match. I believe this means to say that it matches the *FilterCondition* if and only if the conditions match (rather than saying it matches the *filter*). Looking at draft-ietf-jmap-core section 5.5, the *filter* consists of *FilterOperators* and *FilterConditions*; and one presumes that JMAP for mail is not intending to override the meaning of "*FilterOperators*" by making them all behave identical to "AND". This issue also arises in §7.3 --------------------------------------------------------------------------- §4.1.1: > o *keywords*: "String[Boolean]" (default: ) A set of keywords that The intended default is unclear to me. Is this meant to indicate "{}"? --------------------------------------------------------------------------- §4.1.2.1: > A server SHOULD replace any octet > or octet run with the high bit set that violates UTF-8 syntax with > the unicode replacement character (U+FFFD). This seems to preclude a client-side implementation of DKIM. That seems problematic. --------------------------------------------------------------------------- §4.1.2.3: > o *name*: "String|null" The _display-name_ of the [RFC5322] > _mailbox_, or "null" if none. Although its use is not technically correct, the use of comments in From header fields to include display names was, at one time, painfully common -- and one still comes across such usage in the field from time to time. For example, I received a message as recently as ten days ago with a From header field of the form: From: MAILER-DAEMON@ietfa.amsl.com (Mail Delivery System) (Yes. That was generated by an IETF-affiliated mail server. ¯\_(ツ)_/¯ ) It would probably be good for this specification to at least *allow* (and probably encourage) JMAP-for-mail servers to populate the name field with such comments when no properly-formatted name is available; this would allow JMAP-for-mail clients to easily operate on par with existing IMAP clients. --------------------------------------------------------------------------- §4.1.4: > the charset was unknown, or the content-trasfer-encoding was Nit: "...-transfer-..." --------------------------------------------------------------------------- §7.5.1: > "description": "Verzeihung, wegen verdaechtiger Aktivitaeten Ihres Benutzerkontos haben wir den Versand von Nachrichten gesperrt. Bitte wenden Sie sich fuer Hilfe an unser Support Team." This line is approximately 120 characters too long. Consider wrapping. |
2019-02-21
|
14 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2019-02-20
|
14 | Ben Campbell | [Ballot comment] Thanks for all the work on this. I have a few minor comments: - Title, Abstract, and Introduction: Please expand JMAP on first … [Ballot comment] Thanks for all the work on this. I have a few minor comments: - Title, Abstract, and Introduction: Please expand JMAP on first mention. §1.1: Is there a reason not to use the updated boilerplate from RFC 8174? §1.5: "Servers MUST support the standard JMAP push mechanisms to receive notifications when the state changes for any of the types defined in this specification." Which are the "standard" mechanisms? Does that mean both in-band notification and the use of external push notification systems> §1.6: "If a JMAP Mail server also provides an IMAP interface to the data and supports [RFC8474] IMAP Extension for Object Identifiers, the ids SHOULD be the same for mailbox, thread, and email objects in JMAP." What happens if they are not? (Why not MUST)? §2: "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," What happens if a mailbox is accessible via both IMAP and JMAP, and has multiple roles in IMAP? §7: "* "pending": It MAY be possible to cancel this submission." The MAY seems more a statement of fact than permission. |
2019-02-20
|
14 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2019-02-20
|
14 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-02-20
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-02-20
|
14 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-02-20
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-02-20
|
14 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-02-19
|
14 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-02-17
|
14 | Eric Rescorla | [Ballot discuss] 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 … [Ballot discuss] 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. |
2019-02-17
|
14 | Eric Rescorla | [Ballot comment] S 2. > A *Mailbox* object has the following properties: > > o *id*: "Id" (immutable; server-set) The id … [Ballot comment] 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 4.1.2.3. > > 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 "" can help You need a reference to this. |
2019-02-17
|
14 | Eric Rescorla | [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla |
2019-02-13
|
14 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-02-05
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Ron Bonica |
2019-02-05
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Ron Bonica |
2019-02-04
|
14 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-02-04
|
14 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-jmap-mail-14. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-jmap-mail-14. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. IANA also understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: ietf-jmap-core-14 First, in a registry to be created upon approval of a document upon which this draft has a dependency - ietf-jmap-core - three JMAP Capability registrations will be made in a future registry as follows: Capability Name: urn:ietf:params:jmap:mail Reference: [ RFC-to-be ] Intended Use: common Change Controller: IETF Security and Privacy Considerations: [ RFC-to-be, Section 9 ] Capability Name: urn:ietf:params:jmap:submission Reference: [ RFC-to-be ] Intended Use: common Change Controller: IETF Security and Privacy Considerations: [ RFC-to-be, Section 9 ] Capability Name: urn:ietf:params:jmap:vacationresponse Reference: [ RFC-to-be ] Intended Use: common Change Controller: IETF Security and Privacy Considerations: [ RFC-to-be, Section 9 ] Second, in the IMAP Keywords registry on the IMAP Keywords registry page, located at: https://www.iana.org/assignments/imap-keywords/ the name of the registry is changed to the "IMAP and JMAP keywords Registry". IANA Question --> Should the name of the registry page also be changed? Third, also in the IMAP Keywords registry on the IMAP Keywords registry page, located at: https://www.iana.org/assignments/imap-keywords/ a new column called "Scope" is added to the registry. "Scope" can be either "IMAP-only", "JMAP-only", "both". All keywords presently in the IMAP keyword registry will be marked with a scope of "both". Fourth, also in the IMAP Keywords registry on the IMAP Keywords registry page, located at: https://www.iana.org/assignments/imap-keywords/ there are the following, new registrations: Keyword: $draft Type: BOTH Usage: COMMON Scope: JMAP-only Comments: Reference: [ RFC-to-be ] Keyword: $seen Type: BOTH Usage: COMMON Scope: JMAP-only Comments: Reference: [ RFC-to-be ] Keyword: $flagged Type: BOTH Usage: COMMON Scope: JMAP-only Comments: Reference: [ RFC-to-be ] Keyword: $answered Type: BOTH Usage: COMMON Scope: JMAP-only Comments: Reference: [ RFC-to-be ] Keyword: $recent Type: Usage: Scope: Reserved Comments Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Fifth, in the IMAP Mailbox Name Attributes registry located at: https://www.iana.org/assignments/imap-mailbox-name-attributes/ a single registration is made as follows: Attribute Name: Inbox Description: New mail is delivered here by default. Reference: [ RFC-to-be; Section 10.5 ] Usage Notes: JMAP only Sixth, in a registry to be created upon approval of a document upon which this draft has a dependency - ietf-jmap-core - twelve JMAP Error Code registrations will be made in a future registry as follows: IANA Question --> In the ietf-jmap-core draft, each error code has a "Description" field, but the current document does not provide those descriptions. For the twelve registrations in this section, could the authors provide a description for each of the registrations? JMAP Error Code: mailboxHasChild Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 2.5 ] JMAP Error Code: mailboxHasEmail Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 2.5 ] JMAP Error Code: blobNotFound Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 4.6 ] JMAP Error Code: tooManyKeywords Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 4.6 ] JMAP Error Code: tooManyMailboxes Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 4.6 ] JMAP Error Code: invalidEmail Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 7.5 ] JMAP Error Code: tooManyRecipients Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 7.5 ] JMAP Error Code: noRecipients Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 7.5 ] JMAP Error Code: invalidRecipients Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 7.5 ] JMAP Error Code: forbiddenMailFrom Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 7.5 ] JMAP Error Code: forbiddenFrom Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Sections 6.3 and 7.5 ] JMAP Error Code: forbiddenToSend Intended Use: common Change Controller: IETF Description: Reference: [ RFC-to-be; Section 7.5 ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-02-04
|
14 | Amy Vezza | Placed on agenda for telechat - 2019-02-21 |
2019-02-04
|
14 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-02-04
|
14 | Alexey Melnikov | Ballot has been issued |
2019-02-04
|
14 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2019-02-04
|
14 | Alexey Melnikov | Created "Approve" ballot |
2019-02-04
|
14 | Alexey Melnikov | Ballot writeup was changed |
2019-02-04
|
14 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-01-31
|
14 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2019-01-24
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2019-01-24
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2019-01-24
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2019-01-24
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2019-01-21
|
14 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-01-21
|
14 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-02-04): From: The IESG To: IETF-Announce CC: brong@fastmailteam.com, draft-ietf-jmap-mail@ietf.org, jmap@ietf.org, alexey.melnikov@isode.com, Bron … The following Last Call announcement was sent out (ends 2019-02-04): From: The IESG To: IETF-Announce CC: brong@fastmailteam.com, draft-ietf-jmap-mail@ietf.org, jmap@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , jmap-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (JMAP for Mail) to Proposed Standard The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'JMAP for Mail' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a data model for synchronising email data with a server using JMAP. Clients can use this to efficiently search, access, organise and send messages, and get pushed notifications for fast resynchronisation when new messages are delivered or a change is made in another client. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-01-21
|
14 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-01-21
|
14 | Alexey Melnikov | I meant [XCLIENT] in my earlier comment and I just noticed that there was a change to move the reference. |
2019-01-21
|
14 | Alexey Melnikov | Last call was requested |
2019-01-21
|
14 | Alexey Melnikov | Last call announcement was generated |
2019-01-21
|
14 | Alexey Melnikov | Ballot approval text was generated |
2019-01-21
|
14 | Alexey Melnikov | Ballot writeup was generated |
2019-01-21
|
14 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-01-21
|
14 | Alexey Melnikov | I will hold the document for the resolution to XSUBMIT reference after IETF LC. |
2019-01-16
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-16
|
14 | Neil Jenkins | New version available: draft-ietf-jmap-mail-14.txt |
2019-01-16
|
14 | (System) | New version approved |
2019-01-16
|
14 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2019-01-16
|
14 | Neil Jenkins | Uploaded new revision |
2019-01-15
|
13 | Alexey Melnikov | Small change to move XClient from Normative to Informative is requested before starting IETF LC. |
2019-01-15
|
13 | Alexey Melnikov | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2019-01-14
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-14
|
13 | Neil Jenkins | New version available: draft-ietf-jmap-mail-13.txt |
2019-01-14
|
13 | (System) | New version approved |
2019-01-14
|
13 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2019-01-14
|
13 | Neil Jenkins | Uploaded new revision |
2019-01-09
|
12 | Alexey Melnikov | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-12-14
|
12 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2018-12-02
|
12 | Bron Gondwana | (1) The type of RFC requests is Proposed Standard. The title page currently says "Standards Track". (2) Document Announcement Writeup Technical Summary JMAP-Mail specifies … (1) The type of RFC requests is Proposed Standard. The title page currently says "Standards Track". (2) Document Announcement Writeup Technical Summary JMAP-Mail specifies a data model for synchronising email data with a server using the core protocol defined in draft-ietf-jmap-core. JMAP-Mail is the first user of the generic mechanism described in the core protocol. Working Group Summary The initial proposal for JMAP-Mail included a special "Outbox" folder for sending mail. This has been changed to use a new object called "EmailSubmission" instead - which has been tested and is in use at FastMail. The working group also rewroked the data model considerably. This data model includes a simplified set of views into the full MIME data structure to allow easier client development, while still giving the full power of the stucture where required. This work has been done concurrently with the EXTRA working group which is extending RFC3501 (IMAP4), with an eye to keeping both email access protocols compatible with each other. Document Quality The only known implementations of the latest protocol have been done by FastMail staff, but there exist multiple implementations of earlier drafts, and their authors have read the current drafts - they're just waiting until publication to update to the latest version. Both client and server implementations are available as open-source. The JMAP working group is small, but there have been multiple people who have read the document carefully - Chris Newman who is now listed as an author gave particularly detailed reviews. The authors of the various parts of the FastMail stack that are now implemented on this spec, and of the two test suites covering the spec, have also found multiple issues in the last 6 months which have fed back into the final document. Multiple email server vendors have indicated their intention to either add JMAP to their existing servers, or to build new services on top of the JMAP data model. Personnel The Document Shepherd is Bron Gondwana and the Responsible Area Director is Alexey Melnikov. (3) The document has had a complete read through of version 10 by the Document Shepherd, which led to a handful of clarification questions that made it into verison 11. I have also implemented most of it and reviewed code from others implementing other parts. (4) With a document of this size, there's always a possibility that we missed something important, but multiple reviewers with long-term experience in these kinds of protocols have been over the documents, including nit-picky test writers. I'm confident that it's implementable as specified. (5) The main review has come from the EXTRA working group, which has many members in common. There has also been review from security experts who suggested possible risks and mitigations. (6) The Area Director has been heavily involved in the working group, there are no specific concerns with the document that I'm aware of. (7) Yes, each author listed at any point on both the current and earlier drafts has been contacted and confirmed that they have no disclosures. (8) There have been no IPR disclosures filed. (9) The working group is small, but everyone has spoken. There's have been no objections to any of the recent changes, and there's full consensus of the group. (10) Nobody has threatened any appeals or objections. (11) IDnits found references to non-RFC2606-compliant FQDNs, which are inline references to URLs that currently exist, perhaps they should be moved to references, but I'm not sure the policy on that. It also doesn't directly mention the RFC5788 update in the abstract. The are also text misidentifications. (12) There are no formal review areas required. (13) All references within this document been identified as either normative or informative. (14) There is a normative reference to draft-ietf-jmap-core which will require publication before this document. (15) There are no downward normative references references. (16) Publication of this document will update RFC5788 by renaming the IANA registry created in that document, and also adding an extra column to the registry detailing the use for each entry. (17) The IANA considerations sections requests that the registry from RFC5788 be altered, and also specifies some new entries and the changes to be made for all existing entries. This document also extends the registry defined in draft-ietf-jmap-core with additional entries. (18) There are no changes required to expert review in this document. (19) The formal sections are JSON. One of the authors recently tested all the examples in the document to be parseable, and most have been copied directly from network dumps out of working systems using the protocol. |
2018-12-02
|
12 | Bron Gondwana | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2018-12-02
|
12 | Bron Gondwana | IESG state changed to Publication Requested from AD is watching |
2018-12-02
|
12 | Bron Gondwana | (1) The type of RFC requests is Proposed Standard. The title page currently says "Standards Track". (2) Document Announcement Writeup Technical Summary JMAP-Mail specifies … (1) The type of RFC requests is Proposed Standard. The title page currently says "Standards Track". (2) Document Announcement Writeup Technical Summary JMAP-Mail specifies a data model for synchronising email data with a server using the core protocol defined in draft-ietf-jmap-core. JMAP-Mail is the first user of the generic mechanism described in the core protocol. Working Group Summary The initial proposal for JMAP-Mail included a special "Outbox" folder for sending mail. This has been changed to use a new object called "EmailSubmission" instead - which has been tested and is in use at FastMail. The working group also rewroked the data model considerably. This data model includes a simplified set of views into the full MIME data structure to allow easier client development, while still giving the full power of the stucture where required. This work has been done concurrently with the EXTRA working group which is extending RFC3501 (IMAP4), with an eye to keeping both email access protocols compatible with each other. Document Quality The only known implementations of the latest protocol have been done by FastMail staff, but there exist multiple implementations of earlier drafts, and their authors have read the current drafts - they're just waiting until publication to update to the latest version. Both client and server implementations are available as open-source. The JMAP working group is small, but there have been multiple people who have read the document carefully - Chris Newman who is now listed as an author gave particularly detailed reviews. The authors of the various parts of the FastMail stack that are now implemented on this spec, and of the two test suites covering the spec, have also found multiple issues in the last 6 months which have fed back into the final document. Multiple email server vendors have indicated their intention to either add JMAP to their existing servers, or to build new services on top of the JMAP data model. Personnel The Document Shepherd is Bron Gondwana and the Responsible Area Director is Alexey Melnikov. (3) The document has had a complete read through of version 10 by the Document Shepherd, which led to a handful of clarification questions that made it into verison 11. I have also implemented most of it and reviewed code from others implementing other parts. (4) With a document of this size, there's always a possibility that we missed something important, but multiple reviewers with long-term experience in these kinds of protocols have been over the documents, including nit-picky test writers. I'm confident that it's implementable as specified. (5) The main review has come from the EXTRA working group, which has many members in common. There has also been review from security experts who suggested possible risks and mitigations. (6) The Area Director has been heavily involved in the working group, there are no specific concerns with the document that I'm aware of. (7) Yes, each author listed at any point on both the current and earlier drafts has been contacted and confirmed that they have no disclosures. (8) There have been no IPR disclosures filed. (9) The working group is small, but everyone has spoken. There's have been no objections to any of the recent changes, and there's full consensus of the group. (10) Nobody has threatened any appeals or objections. (11) IDnits found references to non-RFC2606-compliant FQDNs, which are inline references to URLs that currently exist, perhaps they should be moved to references, but I'm not sure the policy on that. It also doesn't directly mention the RFC5788 update in the abstract. The are also text misidentifications. (12) There are no formal review areas required. (13) All references within this document been identified as either normative or informative. (14) There is a normative reference to draft-ietf-jmap-core which will require publication before this document. (15) There are no downward normative references references. (16) Publication of this document will update RFC5788 by renaming the IANA registry created in that document, and also adding an extra column to the registry detailing the use for each entry. (17) The IANA considerations sections requests that the registry from RFC5788 be altered, and also specifies some new entries and the changes to be made for all existing entries. This document also extends the registry defined in draft-ietf-jmap-core with additional entries. (18) There are no changes required to expert review in this document. (19) The formal sections are JSON. One of the authors recently tested all the examples in the document to be parseable, and most have been copied directly from network dumps out of working systems using the protocol. |
2018-12-02
|
12 | Neil Jenkins | New version available: draft-ietf-jmap-mail-12.txt |
2018-12-02
|
12 | (System) | New version approved |
2018-12-02
|
12 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2018-12-02
|
12 | Neil Jenkins | Uploaded new revision |
2018-11-25
|
11 | Bron Gondwana | Notification list changed to Bron Gondwana <brong@fastmailteam.com> |
2018-11-25
|
11 | Bron Gondwana | Document shepherd changed to Bron Gondwana |
2018-11-25
|
11 | Neil Jenkins | New version available: draft-ietf-jmap-mail-11.txt |
2018-11-25
|
11 | (System) | New version approved |
2018-11-25
|
11 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2018-11-25
|
11 | Neil Jenkins | Uploaded new revision |
2018-11-16
|
10 | Alexey Melnikov | Responsible AD changed to Alexey Melnikov |
2018-11-16
|
10 | Alexey Melnikov | Intended Status changed to Proposed Standard |
2018-11-16
|
10 | Alexey Melnikov | IESG process started in state AD is watching |
2018-11-16
|
10 | (System) | Earlier history may be found in the Comment Log for /doc/draft-jenkins-jmapmail/ |
2018-11-16
|
10 | Alexey Melnikov | Changed consensus to Yes from Unknown |
2018-11-06
|
10 | Neil Jenkins | New version available: draft-ietf-jmap-mail-10.txt |
2018-11-06
|
10 | (System) | New version approved |
2018-11-06
|
10 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2018-11-06
|
10 | Neil Jenkins | Uploaded new revision |
2018-10-23
|
09 | Neil Jenkins | New version available: draft-ietf-jmap-mail-09.txt |
2018-10-23
|
09 | (System) | New version approved |
2018-10-23
|
09 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2018-10-23
|
09 | Neil Jenkins | Uploaded new revision |
2018-09-11
|
08 | Bron Gondwana | Long WGLC to give time for implementations to be completed. |
2018-09-11
|
08 | Bron Gondwana | IETF WG state changed to In WG Last Call from WG Document |
2018-09-10
|
08 | Neil Jenkins | New version available: draft-ietf-jmap-mail-08.txt |
2018-09-10
|
08 | (System) | New version approved |
2018-09-10
|
08 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman |
2018-09-10
|
08 | Neil Jenkins | Uploaded new revision |
2018-08-06
|
07 | Neil Jenkins | New version available: draft-ietf-jmap-mail-07.txt |
2018-08-06
|
07 | (System) | New version approved |
2018-08-06
|
07 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , jmap-chairs@ietf.org |
2018-08-06
|
07 | Neil Jenkins | Uploaded new revision |
2018-07-02
|
06 | Neil Jenkins | New version available: draft-ietf-jmap-mail-06.txt |
2018-07-02
|
06 | (System) | New version approved |
2018-07-02
|
06 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins |
2018-07-02
|
06 | Neil Jenkins | Uploaded new revision |
2018-05-08
|
05 | Neil Jenkins | New version available: draft-ietf-jmap-mail-05.txt |
2018-05-08
|
05 | (System) | New version approved |
2018-05-08
|
05 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins |
2018-05-08
|
05 | Neil Jenkins | Uploaded new revision |
2018-03-04
|
04 | Neil Jenkins | New version available: draft-ietf-jmap-mail-04.txt |
2018-03-04
|
04 | (System) | New version approved |
2018-03-04
|
04 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins |
2018-03-04
|
04 | Neil Jenkins | Uploaded new revision |
2017-11-28
|
03 | Neil Jenkins | New version available: draft-ietf-jmap-mail-03.txt |
2017-11-28
|
03 | (System) | New version approved |
2017-11-28
|
03 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins |
2017-11-28
|
03 | Neil Jenkins | Uploaded new revision |
2017-10-29
|
02 | Neil Jenkins | New version available: draft-ietf-jmap-mail-02.txt |
2017-10-29
|
02 | (System) | New version approved |
2017-10-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins , jmap-chairs@ietf.org |
2017-10-29
|
02 | Neil Jenkins | Uploaded new revision |
2017-07-16
|
01 | Neil Jenkins | New version available: draft-ietf-jmap-mail-01.txt |
2017-07-16
|
01 | (System) | New version approved |
2017-07-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: Neil Jenkins |
2017-07-16
|
01 | Neil Jenkins | Uploaded new revision |
2017-04-19
|
00 | Bron Gondwana | Added to session: IETF-98: jmap Thu-1520 |
2017-03-28
|
00 | Bron Gondwana | This document now replaces draft-jenkins-jmapmail instead of None |
2017-03-28
|
00 | Neil Jenkins | New version available: draft-ietf-jmap-mail-00.txt |
2017-03-28
|
00 | (System) | WG -00 approved |
2017-03-28
|
00 | Neil Jenkins | Set submitter to "Neil Jenkins ", replaces to draft-jenkins-jmapmail and sent approval email to group chairs: jmap-chairs@ietf.org |
2017-03-28
|
00 | Neil Jenkins | Uploaded new revision |