idnits 2.17.1 draft-melnikov-lemonade-imap-events-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 232. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2006) is 6515 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'LISTEXT' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSGEVENTS' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Expires: December 19, 2006 June 17, 2006 6 Lemonade Inband Notifications 7 draft-melnikov-lemonade-imap-events-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document specifies how Internet Message Store Events can be 41 represented as IMAP (RFC 3501) untagged responses. 43 Table of Contents 45 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Mapping of Internet Message Store Events to IMAP responses . . 3 48 3.1. Message Addition and Deletion for the currently 49 selected mailbox . . . . . . . . . . . . . . . . . . . . . 3 50 3.2. Message Addition and Deletion for other mailboxes . . . . . 4 51 3.3. Message Flags events for the currently selected mailbox . . 4 52 3.4. Message Flags events for other mailboxes . . . . . . . . . 5 53 3.5. Access Accounting events . . . . . . . . . . . . . . . . . 5 54 3.6. Mailbox management events . . . . . . . . . . . . . . . . . 5 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . . . 8 63 1. Requirements notation 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 In examples, "C:" and "S:" indicate lines sent by the client and 70 server respectively. If a single "C:" or "S:" label applies to 71 multiple lines, then the line breaks between those lines are for 72 editorial clarity only and are not part of the actual protocol 73 exchange. 75 2. Introduction 77 IMAP [IDLE] extension defines how an IMAP [RFC3501] server can push 78 notifications to an IMAP client. This mechanism is suitable for 79 transporting of Internet Message Store events [MSGEVENTS] "inband". 80 However the [IDLE] extension doesn't provide any guidance on how 81 different Message Store events can be represented in IMAP. This 82 document is attempting to fill this gap. 84 3. Mapping of Internet Message Store Events to IMAP responses 86 [[anchor4: Note that some event types require that the server 87 supports certain IMAP extensions (e.g. QUOTA).]] 89 3.1. Message Addition and Deletion for the currently selected mailbox 91 An AppendMessage or NewMessage event related to one or more messages 92 in the currently selected mailbox (if any) MUST be reported as an 93 EXISTS response. The server MAY also send a RECENT response, if the 94 server would mark the message as \Recent. [[anchor6: This doesn't 95 provide UID of the new message.]] If the bodyStructure parameter is 96 included in the event, it MUST be returned in a FETCH response 97 containing the BODYSTRUCTURE FETCH item. If the FETCH response is 98 returned it MUST contain the UID FETCH item. 100 Note that a single EXISTS response can be returned for multiple 101 AppendMessage/NewMessage events. 103 Example: 105 S: * 161 EXISTS 106 S: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 107 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 108 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 109 "trip.txt") 110 "<960723163407.20117h@washington.example.com>" 111 "Your trip details" "BASE64" 4554 73) "MIXED")) 113 Example: 115 S: * 162 EXISTS 116 S: * 4 RECENT 118 An ExpireMessage or ExpungeMessage event related to a message in the 119 currently selected mailbox MUST be reported as an EXPUNGE response. 120 [[anchor7: Recommend the EXPUNGED response?]] 122 [[anchor8: OverQuota - Use OVERQUOTA response code defined in the 123 expired draft-cridland-imap-quota-xx.txt.]] 125 [[anchor9: UnderQuota - TBD]] 127 3.2. Message Addition and Deletion for other mailboxes 129 An AppendMessage/NewMessage/ExpireMessage/ExpungeMessage event 130 related to one or more messages in any mailbox rather then the 131 currently selected one MUST result in an untagged STATUS response, 132 containing MESSAGES status data item. Other status data items MAY be 133 included. [[anchor11: What about UIDVALIDITY status item?]] 135 Example: 137 S: * STATUS blurdybloop (MESSAGES 231 RECENT 8 138 UIDVALIDITY 765) 140 [[anchor12: OverQuota - TBD]] 142 [[anchor13: UnderQuota - TBD]] 144 3.3. Message Flags events for the currently selected mailbox 146 All message flag events related to one or more messages in the 147 currently selected mailbox (if any) MUST be reported as a FETCH 148 response containing FLAGS and UID fetch items. 150 3.4. Message Flags events for other mailboxes 152 [[anchor16: TBD]] 154 3.5. Access Accounting events 156 [[anchor18: TBD]] 158 3.6. Mailbox management events 160 [[anchor20: These events are not currently defined in MSGEVENTS.]] 162 Mailbox creation MUST be reported as a LIST response, containing 163 mailbox attributes which are usually returned in a LIST response. 165 Mailbox deletion MUST be reported as a LIST response, containing 166 \NonExistent mailbox attribute [LISTEXT]. 168 Mailbox rename - TBD. [[anchor21: This would require a new LIST 169 extended data item.]] 171 4. Security Considerations 173 [[anchor23: TBD]] 175 5. IANA Considerations 177 This document doesn't require any action from IANA. 179 6. References 181 6.1. Normative References 183 [LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command 184 Extensions", April 2006. 186 [MSGEVENTS] 187 Newman, C., "Internet Message Store Events", June 2006. 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, March 1997. 192 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 193 4rev1", RFC 3501, March 2003. 195 6.2. Informative References 197 [IDLE] Leiba, B., "IMAP4 IDLE Command", RFC 2177, June 1997. 199 Author's Address 201 Alexey Melnikov 202 Isode Ltd 203 5 Castle Business Village 204 36 Station Road 205 Hampton, Middlesex TW12 2BX 206 UK 208 Email: Alexey.Melnikov@isode.com 210 Intellectual Property Statement 212 The IETF takes no position regarding the validity or scope of any 213 Intellectual Property Rights or other rights that might be claimed to 214 pertain to the implementation or use of the technology described in 215 this document or the extent to which any license under such rights 216 might or might not be available; nor does it represent that it has 217 made any independent effort to identify any such rights. Information 218 on the procedures with respect to rights in RFC documents can be 219 found in BCP 78 and BCP 79. 221 Copies of IPR disclosures made to the IETF Secretariat and any 222 assurances of licenses to be made available, or the result of an 223 attempt made to obtain a general license or permission for the use of 224 such proprietary rights by implementers or users of this 225 specification can be obtained from the IETF on-line IPR repository at 226 http://www.ietf.org/ipr. 228 The IETF invites any interested party to bring to its attention any 229 copyrights, patents or patent applications, or other proprietary 230 rights that may cover technology that may be required to implement 231 this standard. Please address the information to the IETF at 232 ietf-ipr@ietf.org. 234 Disclaimer of Validity 236 This document and the information contained herein are provided on an 237 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 238 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 239 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 240 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 241 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 242 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 Copyright Statement 246 Copyright (C) The Internet Society (2006). This document is subject 247 to the rights, licenses and restrictions contained in BCP 78, and 248 except as set forth therein, the authors retain all their rights. 250 Acknowledgment 252 Funding for the RFC Editor function is currently provided by the 253 Internet Society.