Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-30
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-08-16
|
30 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-06-11
|
30 | (System) | RFC Editor state changed to AUTH48 |
2021-05-21
|
30 | (System) | RFC Editor state changed to RFC-EDITOR from TI |
2021-04-22
|
30 | (System) | RFC Editor state changed to TI from EDIT |
2021-03-10
|
30 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-03-10
|
30 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-03-10
|
30 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-03-10
|
30 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-03-10
|
30 | (System) | IANA Action state changed to In Progress from On Hold |
2021-03-09
|
30 | (System) | IANA Action state changed to On Hold from In Progress |
2021-03-09
|
30 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-03-08
|
30 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-03-08
|
30 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-03-01
|
30 | Bron Gondwana | Added to session: IETF-110: extra Fri-1530 |
2021-02-22
|
30 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-02-18
|
30 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'Overtaken by Events' |
2021-02-18
|
30 | Tero Kivinen | Assignment of request for Telechat review by SECDIR to Daniel Migault was marked no-response |
2021-02-17
|
30 | (System) | RFC Editor state changed to EDIT |
2021-02-17
|
30 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-02-17
|
30 | (System) | Announcement was received by RFC Editor |
2021-02-17
|
30 | (System) | IANA Action state changed to In Progress |
2021-02-17
|
30 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-02-17
|
30 | Amy Vezza | IESG has approved the document |
2021-02-17
|
30 | Amy Vezza | Closed "Approve" ballot |
2021-02-17
|
30 | Amy Vezza | Ballot approval text was generated |
2021-02-17
|
30 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2021-02-16
|
30 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-30.txt |
2021-02-16
|
30 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2021-02-16
|
30 | Alexey Melnikov | Uploaded new revision |
2021-02-13
|
29 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-29.txt |
2021-02-13
|
29 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2021-02-13
|
29 | Alexey Melnikov | Uploaded new revision |
2021-02-10
|
28 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-02-10
|
28 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-28.txt |
2021-02-10
|
28 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2021-02-10
|
28 | Alexey Melnikov | Uploaded new revision |
2021-02-04
|
27 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2021-02-04
|
27 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2021-02-04
|
27 | Benjamin Kaduk | [Ballot comment] There are several places where we see a: Note: Since this document is restricted to 7-bit ASCII text, it is not … [Ballot comment] There are several places where we see a: Note: Since this document is restricted to 7-bit ASCII text, it is not possible to show actual UTF-8 data. [...] But this document is *not* restricted to 7-bit ASCII text! (I guess the (not-quoted) bit about not being possible to show actual KOI8-R data is still true, though.) Showing actual non-ASCII text may not be as helpful as the current formulation, though, so I'd suggest just a modification to the disclaimer. Section 1.3 IMAP was originally developed for the older [RFC-822] standard, and as a consequence several fetch items in IMAP incorporate "RFC822" in their name. In all cases, "RFC822" should be interpreted as a reference to the updated [RFC-5322] standard. It looks like it's down to just one (not "several"), now -- RFC822.SIZE. Section 2.2.1 response, and reads another response from the server. In all cases, the client MUST send a complete command (including receiving all command continuation request responses and command continuations for the command) before initiating a new command. To check my understanding: the "command continuations for the command" are things that the client sends, right? Adding a word or two might help clarify. Section 2.3.1.1 A good UIDVALIDITY value to use is a 32-bit representation of the current date/time when the value is assigned: this ensures that the value is unique and always increases. Another possible alternative is a global counter that gets incremented every time a mailbox is created. In light of the discussion in draft-gont-numeric-ids-sec-considerations, I wonder if these are truly the most recommended options, as either option has potential to leak some information about rate or time of mailbox creation. Leaking the time of mailbox creation to the user who created it is, of course, not an issue, but not all IMAP mailboxes are single-user-access. A 32-bit PRP (e.g., block cipher) applied to either option would provide some level of obfuscation while preserving the uniqueness properties. Section 2.3.2 $Junk The user (or a delivery agent on behalf of the user) may choose to mark a message as definitely containing junk ($Junk; see also the related keyword $NotJunk). The $Junk keyword can be used to mark (and potentially move/delete messages later), group or hide undesirable messages. See [IMAP-KEYWORDS-REG] for more information. I'm not entirely sure what additional information I'm supposed to get from [IMAP-KEYWORDS-REG]; the registry page is fairly short on commentary. (Applies throughout.) Section 3.2 In the authenticated state, the client is authenticated and MUST select a mailbox to access before commands that affect messages will be permitted. This state is entered when a pre-authenticated connection starts, when acceptable authentication credentials have been provided, after an error in selecting a mailbox, or after a successful CLOSE command. I think after a successful UNSELECT as well, right? §6.4.2 says "returns the server to the authenticated state" about UNSELECT. Section 3.4 (6) CLOSE command, unsolicited CLOSED response code or failed SELECT or EXAMINE command [UNSELECT here as well, if above.] Section 5.1.2.2 Previous version of this protocol does not define a default server namespace. Two common namespace models have evolved: nit: maybe "the previous version of this protocol did not define" or "previous versions of this protocol did not define" Section 6.1.1 Other capability names refer to extensions, revisions, or amendments to this specification. See the documentation of the CAPABILITY response in Section 7.2.2 for additional information. No capabilities, beyond the base IMAP4rev2 set defined in this specification, are enabled without explicit client action to invoke the capability. Should we also note here that even the base IMAP4rev2 set can require explicit client action to enable (e.g., when IMAP4rev1 is also advertised)? Section 6.2 Server implementations MAY allow access to certain mailboxes without establishing authentication. This can be done by means of the ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. [...] To be clear, from the perspective of the state machine, this entails entering the "authenticated" state but without actually authenticating as a specific client identity? Section 6.2.1 Do we really want the example to show use of LOGIN (which per §6.2.3 is be considered a "last resort" and SHOULD NOT be used) even when AUTH=PLAIN is available? Section 6.2.2 As with any other client response, this initial response MUST be encoded as BASE64. It also MUST be transmitted outside of a quoted nit: it looks like we added another paragraph or two between the previous mention of "initial response" and here, so maybe s/this/the/ is in order. authentication. (Note that SASL framework allows creation of SASL mechanisms that support 2FA (2-factor authentication), however none are fully ready to be recommended by this document.) (side note) With sasl/gssapi/kerberos it's possible to know that the client used 2fa for its authentication exchange with the KDC even if it only has the one (ticket) factor to present to the IMAP server. But this is probably more detail than we need to get into here... C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q= S: A001 OK Success (tls protection) (nit) A01 is reusing the client tag, and doesn't seem to match the response ... typo? Section 6.2.3 Unless either the client is accessing IMAP service on Implicit TLS port [RFC8314], the STARTTLS command has been negotiated or some other mechanism that protects the session from password snooping has been provided, a server implementation MUST implement a configuration in which it advertises the LOGINDISABLED capability and does NOT permit the LOGIN command. [...] (editorial) Given that there are preconditions based on runtime behavior, it's a little strange to have it be "MUST implement" in this manner. If it's mandatory to use, that's an easy fix, but I suspect that the intent is only that the server must implement a configuration where it advertises LOGINDISABLED unless the preconditions are mit, which seems like a more complicated rewording. Section 6.3.1 In the following example, the client enables CONDSTORE: Should we reference RFC 7162 here? Section 6.3.2 fails is attempted, no mailbox is selected. When deselecting a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox is closed (see Paragraph 10). I'm not sure how to find Paragraph 10. Section 6.3.5 It kind of looks like the "examples" contains two similar examples stuck together (or some other client has (re)created some folders mid-session). I think in RFC 3501 the blank line separating examples also crossed a page boundary, so it got missed when converting to XML(?) for the new document. Section 6.3.6 If the server's hierarchy separator character appears in the name, the server SHOULD create any superior hierarchical names that are needed for the RENAME command to complete successfully. In other Is this specifically in the "new mailbox name"? the normalized new mailbox name (see Section 6.3.9.7). This would allow the client to correlate supplied name with the normalized name. nit: "the supplied name". Section 6.3.9.8 4: In this example, we see more mailboxes that reside on another server. This is similar to the command . C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST (\Remote) "/" "Bread" S: * LIST (\HasChildren \Remote) "/" "Meat" S: A04 OK done Why does "Bread" not give \HasChildren or \HasNoChildren? I thought §6.3.9.5 said that the server MUST return these attributes (and the example does show \HasChildren returned for another \Remote box). In example 10, "also" doesn't exist and "also/jazz" is remote. Can we say anything a priori about whether "also" is remote (the example, of course, shows that it is not remote)? Section 6.4.4 However all options specified above MUST result in a single ESEARCH response if used by themselves or in combination. This guaranty simplifies processing in IMAP4rev2 clients. Future SEARCH extensions nit: s/guaranty/guarantee/ MAY be supported. Clients SHOULD use UTF-8. Note that if "CHARSET" is not provided IMAP4rev2 server MUST assume UTF-8, so selecting nit: "an IMAP4rev2 server". Section 6.4.4.4 Example 4: C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994 NOT FROM "Smith" S: P282 OK SEARCH completed C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8} C: YYYYYYYY That snippet doesn't seem consistent with a synchronizing literal; should it be a non-synchronizing literal instead? Section 6.4.8 Because of the similarity of MOVE to COPY, extensions that affect COPY affect MOVE in the same way. Response codes listed in Section 7.1, as well as those defined by extensions, are sent as appropriate. Who decides what is "appropriate"? Will everyone come to the same conclusion? Section 6.5 Server implementations MUST NOT send any added (not specified in this specification) untagged responses, unless the client requested it by issuing the associated experimental command or the ENABLE command (Section 6.3.1). We don't really have much text remaining to describe what the "associated experimental command" would be, now that the "X Command" section is removed. Section 7.1 CAPABILITY Followed by a list of capabilities. This can appear in the initial OK or PREAUTH response to transmit an initial capabilities list. It can also appear in tagged responses to LOGIN or AUTHENTICATE commands. This makes it unnecessary for a client to send a separate CAPABILITY command if it recognizes this response. (and if the implicit capability list is sent in the same authentication/security-mechanism context as subsequent commands) COPYUID Followed by the UIDVALIDITY of the destination mailbox, a UID set containing the UIDs of the message(s) in the source mailbox that were copied to the destination mailbox and containing the UIDs assigned to the copied message(s) in the destination mailbox, indicates that the message(s) have been copied to the destination mailbox with the stated UID(s). (editorial) Is there one UID set in the response or two (one per source/destination)? The following paragraph suggests two, but this one seems to just say one. NOPERM The access control system (e.g., Access Control List (ACL), see [RFC4314] does not permit this user to carry out an operation, such as selecting or creating a mailbox. nit: missing close paren. Section 7.1.3 The example doesn't seem to show the tagged BAD usage, and I'm having trouble convincing myself whether "very long command line" should qualify for the tagged form or not. Section 7.2, 7.3 If the section headings are split into server and mailbox status, respectively, why does the initial intro paragraph still list both server and mailbox status data in both sections? Section 7.2.2 Other capability names indicate that the server supports an extension, revision, or amendment to the IMAP4rev2 protocol. Server responses MUST conform to this document until the client issues a command that uses the associated capability. (another instance) should we say anything about "MUST conform to this document" not applying when the server also advertises IMAP4rev1? A server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses, and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities. IIRC, the earlier mention of automatic capabilities said that an explicit CAPABILITY is still needed for the case when (e.g.) AUTHENTICATE enables a new security layer. Section 7.3.4 [[TBD: describe the most common search data pairs returned.]] Is this still current? Section 7.5.2 ENVELOPE [...] An address structure is a parenthesized list that describes an electronic mail address. The fields of an address structure are in the following order: personal name, [SMTP] at-domain- list (source route, obs-route), mailbox name, and host name. The "obs-route" was not in RFC 3501, is not listed in any published errata reports, and does not seem to be called out in the list of changes from RFC 3501 in Appendix E. This isn't the formal protocol description, so I guess it's not a breaking change, but I still don't understand why it's different (presumably just my ignorance...). If the server chooses to send unsolicited FETCH responses, they MUST include UID FETCH item. Note that this is a new requirement when compared to RFC 3501. Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) I guess this is intended to just be a generic FETCH example, but it's a bit jarring to not see the UID FETCH item in the example right after the text that mentions a requirement to send it, with no other commentary. Section 8 The following is a transcript of an IMAP4rev2 connection on a non TLS port. A long line in this sample is broken for editorial clarity. More than one line, now. C: A001 AUTHENTICATE SCRAM-SHA-256 biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8= S: + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5s RiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYNCg== C: Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG SWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3Ft bWl6N0FuZFZRPQ== S: + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQ== These correspond quite nicely to (base64'd copies of) the example in RFC 7677, with the exception of the first server line, that includes an additional CRLF in the decoded data. Section 9 body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ "QUOTED-PRINTABLE") DQUOTE) / string ; Content-Transfer-Encoding header field value. ; Defaults to "7BIT" (as per RFC 2045) ; if not present in the body part. Is this comment still accurate? capability = ("AUTH=" auth-type) / atom ; New capabilities MUST begin with "X" or be ; registered with IANA in ; a standards-track, an experimental ; or an informational RFC. Is this comment still accurate? capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev2" *(SP capability) ; Servers MUST implement the STARTTLS, AUTH=PLAIN, ; and LOGINDISABLED capabilities. ; Servers which offer RFC 1730 compatibility MUST ; list "IMAP4" as the first capability. ; Servers which offer RFC 3501 compatibility MUST ; list "IMAP4rev1" as one of capabilities. I don't remember us mentioning an "IMAP4" capability in the previous text, and I definitely remember an assertion that the order in which capabilities are listed does not have significance, which seems to conflict with the comment about "IMAP4" as the first capability. command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command ; Valid in all states Is x-command still valid? media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" / "FONT" / "MESSAGE" / "MODEL" / "VIDEO" ) DQUOTE) / string) SP media-subtype ; Defined in [MIME-IMT]. ; FONT defined in RFC 8081. Why does only FONT get a comment? I don't see "MODEL" in [MIME-IMT], either. When the namespace-command production is defined, it's spelled all in lowercase, but it is spelled "Namespace-Command" when it appears in the command-auth production. The "partial-range" production doesn't seem to be used anywhere. return-option = "SUBSCRIBED" / "CHILDREN" / status-option / option-extension (nit) This seems to only be used in list-return-opts, so maybe the generic name is not the best fit for it. Section 11 It might be worth putting in some bromide about how while md5 is used in the BODYSTRUCTURE response, the usage is not particularly security relevant and so there is not a vulnerability due to its use. There are also some forms of DoS attack that we don't say much about (slowloris, many parallel connections, etc.), and the mitigations are fairly well known. It might be worth expounding on these a little bit (though since in most cases both parties have authenticated in some manner, the situation is not as bad as it sometimes is). Section 11.3 as well as any response codes other than CAPABILITY. Client SHOULD ignore the ALERT response code until after TLS has been successfully negotiated (whether using STARTTLS or TLS negotiation on implicit TLS port). Unless explicitly allowed by an IMAP Up in §7.1 we said that this was "without TLS or SASL security layer confidentiality", not limited to TLS. (Also, nit: "Clients" plural.) Section 11.6 A server SHOULD report any authentication failure and analyze such authentication failure attempt with regard to a password brute force attack as well as a password spraying attack. Accounts that match password spraying attacks MUST be blocked and request to change their passwords and only password with significant strength SHOULD be accepted. I'm not 100% sure that "password spraying attack" is a well-known concept. It probably is, but it's hard to be sure. Also, I assume that "accounts that match password spraying attacks" means accounts where the password being tested succeeds at authenticating, which could be worth clarifying with a wording tweak. Section 13.1 It's not clear to me that [ANONYMOUS] is referenced in a manner that requires classification as normative; likewise for [SCRAM-SHA-256]. Similarly, if we use a modified form of [UTF-7] that we describe in whole ourselves, that does not seem to be normative. Section 13.2 If we refer to RFC 3503 for more details on how the mechanism is used, should that be a normative reference? Appendix E 29. Revised IANA registration procedure for IMAP extensions and removed "X" convention. Is that worth a BCP 178 reference? |
2021-02-04
|
27 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-02-04
|
27 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2021-02-04
|
27 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-02-03
|
27 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-02-02
|
27 | Warren Kumari | [Ballot comment] I have but nits to offer: O:IMAP was originally developed for the older [RFC-822] standard, and as a consequence several fetch items P: … [Ballot comment] I have but nits to offer: O:IMAP was originally developed for the older [RFC-822] standard, and as a consequence several fetch items P: IMAP was originally developed for the older [RFC-822] standard, and as a consequence, several fetch items C: missing comma O: Note: If instead, the server detected an error P: Note: If, instead, the server detected an error O: When the distinction between synchronizing and non-synchronizing literals is not important, this document just uses the term "literal". C: s/just// or s/just/only/ -- 'just' reads oddly. O: synchonizing P: synchronizing |
2021-02-02
|
27 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-02-02
|
27 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2021-02-02
|
27 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-02-02
|
27 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-27.txt |
2021-02-02
|
27 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2021-02-02
|
27 | Alexey Melnikov | Uploaded new revision |
2021-02-02
|
26 | Alvaro Retana | [Ballot comment] [Disclaimer: All I know about IMAP is that I use it to read my mail. :-)] It caught my attention that while this … [Ballot comment] [Disclaimer: All I know about IMAP is that I use it to read my mail. :-)] It caught my attention that while this document Obsoletes rfc3501, it takes no formal action on any of the RFCs that Updated IMAP4rev1, even if some of that functionality is "folded in". I would like to understand the status of the rfc350-updating RFCs as related to this document. This query is mostly for my own education. While I would really appreciate a response, I'm ok with a pointer, or even just the prospect of a conversation next time we're in the same place - I'll buy. ;-) |
2021-02-02
|
26 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-02-02
|
26 | Alissa Cooper | [Ballot comment] Thanks for taking this on. (1) Section 6.3.9 says: "The LIST command SHOULD return its data quickly, without undue delay. For example, … [Ballot comment] Thanks for taking this on. (1) Section 6.3.9 says: "The LIST command SHOULD return its data quickly, without undue delay. For example, it SHOULD NOT go to excess trouble to calculate the \Marked or \Unmarked status or perform other processing" The second sentence seems like it does not warrant normative language given that it is giving an example (and what does it mean for a command to measure whether trouble is excessive anyway?). (2) There are some recurring example names -- owatagusiam, blurdybloop, etc. -- that could probably be replaced with names that are a little more accessible/obvious to new readers. Also, there are a lot of examples with user names from the same cultural/linguistic context -- smith, fred, eric, etc. Neutralizing or diversifying those names would improve the document. |
2021-02-02
|
26 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2021-02-02
|
26 | Roman Danyliw | [Ballot comment] ** Section 1.3. What are the “unpublished IMAP2bis protocols”? Even if there were unpublished, is there any pointer/reference that can be provided, say … [Ballot comment] ** Section 1.3. What are the “unpublished IMAP2bis protocols”? Even if there were unpublished, is there any pointer/reference that can be provided, say like https://tools.ietf.org/html/draft-ietf-imap-imap2bis-02? ** Section 2.3.1.1. Step #4. Should “In particular, the internal date, [RFC-5322] size, envelope, body structure, and message texts (all BODY[...] fetch data items) must never change)”, use the normative “MUST never change”? ** Section 2.3.3. The text for $Forwarded notes that “Once set, the flag SHOULD NOT be cleared.” Should the same guidance apply to $MDNSent? ** Section 5.1.2. Editorial. s/manager to grant to their secretary access rights/manager to grant to their administrative support staff access rights/ ** Section 6.3.1. Per “However, servers cannot send those unsolicited responses (with the exception of response codes (see Section 7.1) included in tagged or untagged OK/NO/BAD responses, which can always be sent) until they know that the clients support such extensions and thus won't choke on the extension response data”, what is the more precise definition of “choke” here. Is it that the client doesn’t understand the extension or that it won’t be able to process it? ** Section 6.3.9.3. Step 3. Per “Attributes returned in the same LIST response must be treated additively”, should this be a normative “MUST”? ** Section 6.3.12 and Section 8. The examples here have a few “non example” domains (e.g., @Blurdybloop.com, @owatagu.siam.edu, @cac.washington.edu) ** Section 6.4.4.4. Editorial. In this section the inline annotation of the C: and S: examples are with a “//”. In Section 6.3.10, these annotations are made via “< … >”. I’d recommend consistency. ** Section 7.1. Other than a clear text connection, under what circumstances would PRIVACYREQUIRED be returned? I ask because the statement “The operation is not permitted due to a lack of privacy” seems rather generic and might benefit from tighter scoping of what “lack of privacy” means. ** Section 7.1.4. Per “For this reason PREAUTH response SHOULD only be returned by servers on connections that are protected by TLS (such as on implicit TLS port [RFC8314]) or protected through other means such as IPSec”, what is the corner case in mind that motives a SHOULD (instead of a MUST)? ** Section 11. There are both confidentiality and integrity issues with sending of IMAP in the clear. OLD IMAP4rev2 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated. NEW IMAP4rev2 protocol transactions, including electronic mail data, are sent in the clear over the network exposing them to possible eavesdropping and manipulation unless protections are negotiated. ** Section 11.1. Per “Other TLS cipher suites recommended in RFC 7525 are RECOMMENDED …”, seems as if RFC7525 needs to be an explicit reference. ** Section 11.2. Per “For this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and both IPv4 and IPv6) concurrently by default, unless overriden [sic] by either user configuration or DNS SRV records [RFC6186]”, is there any further guidance needed here to guide if say both 993 and 143 respond; or you get responses across address families? ** In the spirit of inclusive language, consider something like the following: -- Section 6.2.1. s/to protect against man-in-the-middle attackers which alter/to protect against an on-path attacker which could alter/ -- Section 11.1 OLD … as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. NEW … as presented in the server Certificate message, in order to prevent on-path attackers attempting to masquerade as the server. -- Section 11.3. s/(or a man-in-the-middle attacker)/ (or an on-path attacker)/ ** Typos: -- Section 11.2. s/overriden/overridden/ ** From idnits: -- The draft header indicates that this document obsoletes RFC3501, but the abstract doesn't seem to mention this, which it should. -- There are a number of reference warnings which should be confirmed as not being problematic (not mentioned in the shepherd write-up) |
2021-02-02
|
26 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-02-01
|
26 | Erik Kline | [Ballot comment] [[ nits ]] [ section 2.3.2 ] * "This so that" -> "This is so that", perhaps |
2021-02-01
|
26 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-02-01
|
26 | Robert Wilton | [Ballot comment] Thank you for your work on this important update to IMAP, hopefully putting it on a better footing for the future. I'm balloting … [Ballot comment] Thank you for your work on this important update to IMAP, hopefully putting it on a better footing for the future. I'm balloting 'No Obj' in the sense that I'm trusting the ADs (and authors and WG) and I doubt that my review of an update to a protocol that I don't know would bring anything new or helpful to the standardization process. I do have a meta-process question though: I suspect that there are other protocols/RFCs that could potentially benefit from a similar treatment (DNS springs to mind), where the old specs have many updates. With the benefit of hindsight, would the authors recommend doing this for other significant old RFCs? Or did this turn out to be significantly more effort than anticipated? Regards, Rob |
2021-02-01
|
26 | Robert Wilton | Ballot comment text updated for Robert Wilton |
2021-02-01
|
26 | Robert Wilton | [Ballot comment] Thank you for your work on this important update to IMAP, hopefully putting it on a better footing for the future. I'm balloting … [Ballot comment] Thank you for your work on this important update to IMAP, hopefully putting it on a better footing for the future. I'm balloting 'No Obj' in the sense that I'm trusting the ADs (and authors and WG) and I doubt that my review of a protocol that I don't know would bring anything new or helpful to the standardization process. I do have a meta-process question though: I suspect that there are other protocols that could potentially benefit from a similar treatment (DNS springs to mind), where the old specs have many updates. With the benefit of hindsight, would the authors recommend doing this for other significant old RFCs? Regards, Rob |
2021-02-01
|
26 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-02-01
|
26 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Collecting and aggregating all the previous updates is really useful. The numerous examples are … [Ballot comment] Thank you for the work put into this document. Collecting and aggregating all the previous updates is really useful. The numerous examples are really helpful. I must admit though that "unpublished IMAP2bis protocols" makes me wonder why it is mentioned if not public... Also, "network connection" is kind of weird for an Internet based on connectionless IP layer... ;-) Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2.3.2 -- Why two flags associated to "junk" but only one for "phishing" ? -- Section 8 -- This example uses LOGIN method that is not recommended on plain text connection (see 6.2.3). Perhaps worth saying that this example works over implicit TLS or better use a AUTH method? == NITS == -- Section 4.3 -- "synchonizing literal" ? -- Section 6.3.12 -- The example contains "Content-Type: TEXT/PLAIN; CHARSET=US-ASCII" while in most email headers that I have seen, the value is in lowercase... May I assume that case is *not* relevant (because not part of the email message but part of IMAP) ? If so, this value reads lie SHOUTING to me ;-) -- Section 6.4.4 -- The example dates are in 1994... perhaps worth updating ? ;-) Other examples are in 2006 |
2021-02-01
|
26 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-01-28
|
26 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-01-24
|
26 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Daniel Migault |
2021-01-24
|
26 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Daniel Migault |
2021-01-24
|
26 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-26.txt |
2021-01-24
|
26 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2021-01-24
|
26 | Alexey Melnikov | Uploaded new revision |
2021-01-22
|
25 | Martin Duke | [Ballot comment] Various non-blocking questions/comments: 2.3.1.1 what would happen if the UID approached 2^32 due to a lifetime of spam or something? The server can … [Ballot comment] Various non-blocking questions/comments: 2.3.1.1 what would happen if the UID approached 2^32 due to a lifetime of spam or something? The server can increment the validity value, but doesn’t that make earlier email unreferenceable except via sequence number? 2.3.2 In the $Phishing definition, do you mean the user agent SHOULD (in caps) display an additional warning message? 4.1.1 the last statement, “ the "*" value for a sequence number is not permitted.”, is oddly placed, enough that it almost reads like a typo where you meant UID. A clearer statement might be “The ‘*’ value is permitted for UIDs but not sequence numbers.” |
2021-01-22
|
25 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-01-20
|
25 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2021-01-20
|
25 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-25.txt |
2021-01-20
|
25 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2021-01-20
|
25 | Alexey Melnikov | Uploaded new revision |
2021-01-20
|
24 | Cindy Morgan | Placed on agenda for telechat - 2021-02-04 |
2021-01-20
|
24 | Barry Leiba | [Ballot comment] I am an author. But everyone else should ballot Yes. |
2021-01-20
|
24 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2021-01-20
|
24 | Barry Leiba | [Ballot comment] I am an author. |
2021-01-20
|
24 | Barry Leiba | [Ballot Position Update] New position, Recuse, has been recorded for Barry Leiba |
2021-01-20
|
24 | Murray Kucherawy | Ballot has been issued |
2021-01-20
|
24 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
2021-01-20
|
24 | Murray Kucherawy | Created "Approve" ballot |
2021-01-20
|
24 | Murray Kucherawy | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2021-01-20
|
24 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-01-19
|
24 | Murray Kucherawy | Ballot writeup was changed |
2021-01-19
|
24 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-01-19
|
24 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-extra-imap4rev2-24. 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-extra-imap4rev2-24. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete. IANA Question --> IANA understands that the intent of this document is to, if approved, obsolete RFC 3501. While IANA understands the four actions below, we also wonder if any of the other registries where RFC 3501 are affected should be modified to reflect the move from RFC 3501 to [ RFC-to-be ]? For instance, the following are examples of registries have registrations that reference RFC 3501: character-sets charset-reg/UTF-7-IMAP gssapi-service-names imap-capabilities imap-mailbox-name-attributes imap-response-codes service-names-port-numbers Are there changes to be made in those registries? First, in the Service Names and Transport Protocol Port Number registry located at: https://www.iana.org/assignments/service-names-port-numbers/ four modifications of existing port number registrations will be made: => The reference for TCP port 143 and the corresponding "imap" service name will be updated to both RFC 3501 and [ RFC-to-be ]. => The reference for TCP port 993 and the corresponding "imaps" service name will be updated to include RFC 3501, RFC 8314 and [ RFC-to-be ]. => UDP port 143 will be marked reserved. => UDP port 993 will be marked reserved. Second, in the Internet Message Access Protocol (IMAP) Capabilities Registry located at: https://www.iana.org/assignments/imap-capabilities/ the following three extensions will have their references changed to [ RFC-to-be ]: AUTH= STARTTLS LOGINDISABLED Third, in the Generic Security Service Application Program Interface (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL) Service Names registry located at: https://www.iana.org/assignments/gssapi-service-names/ the reference for the "imap" service name will be changed from RFC 3501 to [ RFC-to-be ]. Fourth, in the LIST-EXTENDED response registry on the Internet Message Access Protocol (IMAP) LIST EXTENDED Registry page located at: https://www.iana.org/assignments/imap-list-extended/ the existing registration for LIST-EXTENDED extended data item tag OLDNAME will have its reference modified to include both RFC5465 and [ RFC-to-be ]. 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 |
2021-01-19
|
24 | Daniel Migault | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Daniel Migault. Sent review to list. |
2021-01-15
|
24 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Migault |
2021-01-15
|
24 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Migault |
2021-01-14
|
24 | Robert Sparks | Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2021-01-08
|
24 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2021-01-08
|
24 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2021-01-07
|
24 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2021-01-07
|
24 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2021-01-06
|
24 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-01-06
|
24 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-01-20): From: The IESG To: IETF-Announce CC: brong@fastmailteam.com, draft-ietf-extra-imap4rev2@ietf.org, extra-chairs@ietf.org, extra@ietf.org, superuser@gmail.com … The following Last Call announcement was sent out (ends 2021-01-20): From: The IESG To: IETF-Announce CC: brong@fastmailteam.com, draft-ietf-extra-imap4rev2@ietf.org, extra-chairs@ietf.org, extra@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Internet Message Access Protocol (IMAP) - Version 4rev2) to Proposed Standard The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'Internet Message Access Protocol (IMAP) - Version 4rev2' 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 last-call@ietf.org mailing lists by 2021-01-20. 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 The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc2152: UTF-7 A Mail-Safe Transformation Format of Unicode (Informational - Legacy stream) rfc2180: IMAP4 Multi-Accessed Mailbox Practice (Informational - Legacy stream) rfc1733: Distributed Electronic Mail Models in IMAP4 (Informational - IETF stream) rfc4549: Synchronization Operations for Disconnected IMAP4 Clients (Informational - IETF stream) rfc3348: The Internet Message Action Protocol (IMAP4) Child Mailbox Extension (Informational - IETF stream) rfc2061: IMAP4 Compatibility with IMAP2bis (Informational - Legacy stream) rfc1732: IMAP4 Compatibility with IMAP2 and IMAP2bis (Informational - IETF stream) rfc2062: Internet Message Access Protocol - Obsolete Syntax (Informational - Legacy stream) rfc1176: Interactive Mail Access Protocol: Version 2 (Experimental - Legacy stream) |
2021-01-06
|
24 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-01-06
|
24 | Murray Kucherawy | Last call was requested |
2021-01-06
|
24 | Murray Kucherawy | Ballot approval text was generated |
2021-01-06
|
24 | Murray Kucherawy | Ballot writeup was generated |
2021-01-06
|
24 | Murray Kucherawy | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-01-06
|
24 | Murray Kucherawy | Last call announcement was generated |
2021-01-05
|
24 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-01-05
|
24 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-24.txt |
2021-01-05
|
24 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2021-01-05
|
24 | Alexey Melnikov | Uploaded new revision |
2021-01-04
|
23 | Murray Kucherawy | Additional edits are under discussion. |
2021-01-04
|
23 | Murray Kucherawy | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2021-01-04
|
23 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-01-04
|
23 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-23.txt |
2021-01-04
|
23 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2021-01-04
|
23 | Alexey Melnikov | Uploaded new revision |
2021-01-04
|
22 | Murray Kucherawy | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-12-31
|
22 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-22.txt |
2020-12-31
|
22 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-12-31
|
22 | Alexey Melnikov | Uploaded new revision |
2020-11-23
|
21 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-21.txt |
2020-11-23
|
21 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-11-23
|
21 | Alexey Melnikov | Uploaded new revision |
2020-11-19
|
20 | Murray Kucherawy | IESG state changed to AD Evaluation from Publication Requested |
2020-11-18
|
20 | Bron Gondwana | (1) Document Type: Proposed Standard. This is appropriate as it combines the work from other documents which are Proposed Standard. (2) Document Announcement Write-Up: Technical … (1) Document Type: Proposed Standard. This is appropriate as it combines the work from other documents which are Proposed Standard. (2) Document Announcement Write-Up: Technical Summary: This document is revision 2 of the IMAP4 protocol, of which revision 1 is defined in RFC3501. IMAP4 is widely used and widely extended - there are over 50 RFCs defining extensions to the IMAP protocol. This document merges in many of the widely-used and popular extensions to form a new baseline. It also removes a couple of the unused and poorly supported features that are no longer used. IMAP4rev2 is an opt-in extension which is designed to be implementable alongside IMAP4rev1. Working Group Summary: This document is very long and complex and there was a lot of discussion about specific points. The discussion involved developers from many of the largest IMAP4 servers, as well as client authors. While there are tradeoffs that had to be made, there's nobody in the working group who has expressed unhappiness or concerns about the content of this document. Document Quality: To a large extent this document covers existing practice in common servers. The document has been closely reviewed by many expert IMAP server implementers. Personnel: * Document Shepherd: Bron Gondwana * Area Director: Murray Kucherawy (3) I reviewed an earlier revision of this document in fine detail, over a couple of solid days sitting with a printout and a red pen checking each section against a pretty deep understanding of the data model as a developer of one of the IMAP4rev1 servers. Since then, I've read all the diffs and followed the mailing list discussion closely. (4) I don't have any concerns about the length and bredth of reviews. Multiple detailed reviews on the list have been done by the foremost world experts on this protocol suite, many of whom have implemented and managed IMAP servers for over a decade. (5) This document doesn't contain sections which need specific review from other areas, it doesn't add anything significantly new from the IMAP4rev1 extensions that it combines. (6) I don't have any specific concerns for the Area Director or IESG to be aware of. (7) Yes, I have confirmed that there is no IPR to be declared by either of the authors. (8) There have been no IPR disclosures. (9) There's a very solid working group consensus. (10) There are no appeal threats. (11) Nits: a couple of lines are too long, which are protocol examples (12) There are no formal reviews required. (13) Yes, all references have been identified. (14) There are no references to documents that are incomplete. (15) There are no downwards references. (16) This document won't change the status of other documents. (17) No new IANA registries are created, and this document specifies which IANA registries have entries that need to be updated to point to this document. (18) There are no new IANA registries. (19) I haven't tested the formal ABNF sections other than reading through them fairly carefully back when I reviewed this. (20) There's no YANG here. |
2020-11-18
|
20 | Bron Gondwana | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2020-11-18
|
20 | Bron Gondwana | IESG state changed to Publication Requested from AD is watching |
2020-11-18
|
20 | Bron Gondwana | (1) Document Type: Proposed Standard. This is appropriate as it combines the work from other documents which are Proposed Standard. (2) Document Announcement Write-Up: Technical … (1) Document Type: Proposed Standard. This is appropriate as it combines the work from other documents which are Proposed Standard. (2) Document Announcement Write-Up: Technical Summary: This document is revision 2 of the IMAP4 protocol, of which revision 1 is defined in RFC3501. IMAP4 is widely used and widely extended - there are over 50 RFCs defining extensions to the IMAP protocol. This document merges in many of the widely-used and popular extensions to form a new baseline. It also removes a couple of the unused and poorly supported features that are no longer used. IMAP4rev2 is an opt-in extension which is designed to be implementable alongside IMAP4rev1. Working Group Summary: This document is very long and complex and there was a lot of discussion about specific points. The discussion involved developers from many of the largest IMAP4 servers, as well as client authors. While there are tradeoffs that had to be made, there's nobody in the working group who has expressed unhappiness or concerns about the content of this document. Document Quality: To a large extent this document covers existing practice in common servers. The document has been closely reviewed by many expert IMAP server implementers. Personnel: * Document Shepherd: Bron Gondwana * Area Director: Murray Kucherawy (3) I reviewed an earlier revision of this document in fine detail, over a couple of solid days sitting with a printout and a red pen checking each section against a pretty deep understanding of the data model as a developer of one of the IMAP4rev1 servers. Since then, I've read all the diffs and followed the mailing list discussion closely. (4) I don't have any concerns about the length and bredth of reviews. Multiple detailed reviews on the list have been done by the foremost world experts on this protocol suite, many of whom have implemented and managed IMAP servers for over a decade. (5) This document doesn't contain sections which need specific review from other areas, it doesn't add anything significantly new from the IMAP4rev1 extensions that it combines. (6) I don't have any specific concerns for the Area Director or IESG to be aware of. (7) Yes, I have confirmed that there is no IPR to be declared by either of the authors. (8) There have been no IPR disclosures. (9) There's a very solid working group consensus. (10) There are no appeal threats. (11) Nits: a couple of lines are too long, which are protocol examples (12) There are no formal reviews required. (13) Yes, all references have been identified. (14) There are no references to documents that are incomplete. (15) There are no downwards references. (16) This document won't change the status of other documents. (17) No new IANA registries are created, and this document specifies which IANA registries have entries that need to be updated to point to this document. (18) There are no new IANA registries. (19) I haven't tested the formal ABNF sections other than reading through them fairly carefully back when I reviewed this. (20) There's no YANG here. |
2020-10-27
|
20 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-20.txt |
2020-10-27
|
20 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-10-27
|
20 | Alexey Melnikov | Uploaded new revision |
2020-10-27
|
19 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-19.txt |
2020-10-27
|
19 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-10-27
|
19 | Alexey Melnikov | Uploaded new revision |
2020-09-16
|
18 | Bron Gondwana | Tag Revised I-D Needed - Issue raised by WG cleared. |
2020-09-16
|
18 | Bron Gondwana | IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead |
2020-09-15
|
18 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-18.txt |
2020-09-15
|
18 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-09-15
|
18 | Alexey Melnikov | Uploaded new revision |
2020-07-29
|
17 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-17.txt |
2020-07-29
|
17 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-07-29
|
17 | Alexey Melnikov | Uploaded new revision |
2020-07-13
|
16 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-16.txt |
2020-07-13
|
16 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-07-13
|
16 | Alexey Melnikov | Uploaded new revision |
2020-06-17
|
15 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-15.txt |
2020-06-17
|
15 | (System) | New version approved |
2020-06-17
|
15 | (System) | Request for posting confirmation emailed to previous authors: Barry Leiba , Alexey Melnikov , extra-chairs@ietf.org |
2020-06-17
|
15 | Alexey Melnikov | Uploaded new revision |
2020-05-08
|
14 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-14.txt |
2020-05-08
|
14 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-05-08
|
14 | Alexey Melnikov | Uploaded new revision |
2020-04-03
|
13 | Bron Gondwana | Tag Revised I-D Needed - Issue raised by WG set. |
2020-04-03
|
13 | Bron Gondwana | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2020-04-03
|
13 | Murray Kucherawy | Note field has been cleared |
2020-03-26
|
13 | Murray Kucherawy | Note added 'Tinkering with my newfound powers.' |
2020-03-26
|
13 | Murray Kucherawy | Responsible AD changed to Murray Kucherawy |
2020-03-26
|
13 | Murray Kucherawy | IESG process started in state AD is watching |
2020-03-26
|
13 | (System) | Earlier history may be found in the Comment Log for /doc/draft-melnikov-imap4rev2/ |
2020-03-09
|
13 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-13.txt |
2020-03-09
|
13 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-03-09
|
13 | Alexey Melnikov | Uploaded new revision |
2020-02-12
|
12 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-12.txt |
2020-02-12
|
12 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2020-02-12
|
12 | Alexey Melnikov | Uploaded new revision |
2019-12-19
|
11 | Bron Gondwana | IETF WG state changed to In WG Last Call from WG Document |
2019-12-03
|
11 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-11.txt |
2019-12-03
|
11 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2019-12-03
|
11 | Alexey Melnikov | Uploaded new revision |
2019-11-26
|
10 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-10.txt |
2019-11-26
|
10 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2019-11-26
|
10 | Alexey Melnikov | Uploaded new revision |
2019-11-24
|
09 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-09.txt |
2019-11-24
|
09 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2019-11-24
|
09 | Alexey Melnikov | Uploaded new revision |
2019-11-21
|
08 | Bron Gondwana | Notification list changed to Bron Gondwana <brong@fastmailteam.com> |
2019-11-21
|
08 | Bron Gondwana | Document shepherd changed to Bron Gondwana |
2019-11-21
|
08 | Bron Gondwana | Changed consensus to Yes from Unknown |
2019-11-21
|
08 | Bron Gondwana | Intended Status changed to Proposed Standard from None |
2019-11-19
|
08 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-08.txt |
2019-11-19
|
08 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2019-11-19
|
08 | Alexey Melnikov | Uploaded new revision |
2019-11-04
|
07 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-07.txt |
2019-11-04
|
07 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2019-11-04
|
07 | Alexey Melnikov | Uploaded new revision |
2019-10-28
|
06 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-06.txt |
2019-10-28
|
06 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
2019-10-28
|
06 | Alexey Melnikov | Uploaded new revision |
2019-07-09
|
05 | Cindy Morgan | New version available: draft-ietf-extra-imap4rev2-05.txt |
2019-07-09
|
05 | (System) | Secretariat manually posting. Approvals already received |
2019-07-09
|
05 | Cindy Morgan | Uploaded new revision |
2019-03-09
|
04 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-04.txt |
2019-03-09
|
04 | (System) | New version approved |
2019-03-09
|
04 | (System) | Request for posting confirmation emailed to previous authors: Barry Leiba , Alexey Melnikov , extra-chairs@ietf.org |
2019-03-09
|
04 | Alexey Melnikov | Uploaded new revision |
2019-02-03
|
03 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-03.txt |
2019-02-03
|
03 | (System) | New version approved |
2019-02-03
|
03 | (System) | Request for posting confirmation emailed to previous authors: Barry Leiba , Alexey Melnikov , extra-chairs@ietf.org |
2019-02-03
|
03 | Alexey Melnikov | Uploaded new revision |
2018-10-19
|
02 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-02.txt |
2018-10-19
|
02 | (System) | New version approved |
2018-10-19
|
02 | (System) | Request for posting confirmation emailed to previous authors: Alexey Melnikov , extra-chairs@ietf.org |
2018-10-19
|
02 | Alexey Melnikov | Uploaded new revision |
2018-07-16
|
01 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-01.txt |
2018-07-16
|
01 | (System) | New version approved |
2018-07-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: Alexey Melnikov , extra-chairs@ietf.org |
2018-07-16
|
01 | Alexey Melnikov | Uploaded new revision |
2018-05-30
|
00 | Alexey Melnikov | Became a WG document. |
2018-05-30
|
00 | Alexey Melnikov | This document now replaces draft-melnikov-imap4rev2 instead of None |
2018-05-30
|
00 | Alexey Melnikov | New version available: draft-ietf-extra-imap4rev2-00.txt |
2018-05-30
|
00 | (System) | WG -00 approved |
2018-05-30
|
00 | Alexey Melnikov | Set submitter to "Alexey Melnikov ", replaces to (none) and sent approval email to group chairs: extra-chairs@ietf.org |
2018-05-30
|
00 | Alexey Melnikov | Uploaded new revision |