idnits 2.17.1 draft-sparks-genarea-imaparch-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2013) is 4004 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 6237 (Obsoleted by RFC 7377) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks 3 Internet-Draft Tekelec 4 Intended status: Informational May 7, 2013 5 Expires: November 06, 2013 7 IMAP Access to IETF Email List Archives 8 draft-sparks-genarea-imaparch-07 10 Abstract 12 The IETF makes heavy use of email lists to conduct its work. This 13 often involves accessing the archived history of those email lists. 14 Participants would like to have the ability to browse and search 15 those archives using standard IMAP clients. This memo captures the 16 requirements for providing a service that would allow such browsing 17 and searching, and it is intended as input to a later activity for 18 the design and development of such a service. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 06, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements for IMAP access to archived IETF lists . . . . . 2 55 3. Internationalized Address Considerations . . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 7.1. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 7.2. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.3. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 7.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 7.5. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 7.6. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 7.7. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.8. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Informative References . . . . . . . . . . . . . . . . . . . . 5 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 The IETF makes heavy use of email lists to conduct its work. This 74 often involves accessing the archived history of those email lists. 75 Requirements for improved web-based browsing and searching of these 76 archives are captured in [RFC6778]. Participants would like to have 77 the ability to browse and search those archives using standard IMAP 78 clients. This memo captures the requirements for providing a service 79 that would allow such browsing and searching, and it is intended as 80 input to a later activity for the design and development of such a 81 service. 83 Discussion of this memo should take place on the ietf@ietf.org 84 mailing list. 86 2. Requirements for IMAP access to archived IETF lists 88 Many participants would prefer to access the list archives using IMAP 89 [RFC3501]. Providing this access while meeting the following 90 requirements will likely require an IMAP server with specialized 91 capabilities. 93 o The system should expose the archive using an IMAP interface, with 94 each list represented as a mailbox. 96 o This interface must work with standard IMAP clients. 98 o The interface should allow users that have provided credentials to 99 each have their own read/unread marks for messages. Allowing 100 other annotation is desirable. The implementation should consider 101 taking advantage of the IMAP extensions for ANNOTATE [RFC5257] and 102 METADATA [RFC5464]. 104 o It must be possible for administrators, on a per-user basis, to 105 disable setting read/unread marks and other annotations and to 106 delete any such marks or annotations. 108 o The interface must not allow users to modify the underlying 109 message or metadata other than the read/unread marks and 110 annotations described above. Specifically, users must not be able 111 to delete or insert messages, or move them between mailboxes in 112 the archive. (Clients will, of course, be able to make local 113 copies of messages from the archive.) 115 o The interface must have server-side searching enabled, and should 116 scale to support multiple simultaneous extensive searches. The 117 server should provide the enhanced search capabilities described 118 in [RFC6778]. The implementation should consider taking advantage 119 of the extensions defined for IMAP SORT and THREAD [RFC5256], 120 multimailbox search [RFC6237], and fuzzy search [RFC6203]. 122 o When the system requires credentials, it must use the 123 datatracker's authentication system 125 - While the vast majority of archived lists have an open access 126 policy, some archived lists have restricted archives. The 127 system must make it possible to limit access to a restricted 128 archive based on login credentials. 130 - The system must not require credentials for accessing lists 131 with open archives. (However, it is acceptable for a user to 132 access such archives while providing credentials.) 133 Specifically, the system will allow anonymous access using the 134 SASL ANONYMOUS authentication mechanism [RFC4505] or a LOGIN 135 command with a special username (such as "anonymous") 136 determined by the administrator. 138 3. Internationalized Address Considerations 140 The implementation should anticipate internationalized email 141 addresses as discussed in the following three documents [RFC6532] 142 [RFC6531] [RFC6855]. There is no firm requirement at this time. 144 4. Security Considerations 146 Allowing IMAP as an interface for browsing and searching the archives 147 of IETF email lists does not affect the security of the Internet in 148 any significant fashion. 150 Searching can be I/O and CPU intensive. Clients that make local 151 copies of all messages in a mailbox can also present an I/O burden, 152 particularly when syncronizing for the first time. The implementors 153 of this interface should consider the potential for maliciously 154 crafted searches attempting to consume a damaging amount of 155 resources. The implementors should consider the potential for denial 156 of service attacks through making many connections to the interface. 157 The implementors should consider ways to rate limit I/O due to making 158 local copies of messages. 160 Storing read/unread marks and other annotations requires potentially 161 unbounded storage space. The implementors of this interface should 162 consider the potential for maliciously crafted annontations 163 attempting to consume a damaging amount of storage space. The 164 implementers should consider making it easy to alert the 165 administrator when a user begins consuming exceptional amounts of 166 space. 168 5. IANA Considerations 170 This document has no actions for IANA. 172 6. Acknowledgements 174 This text was derived directly from an early version of the Internet 175 Draft that became [RFC6778] which incorporated text suggestions from 176 Alexey Melnikov, Pete Resnick, and S. Moonesamy. Barry Leiba 177 suggested several references to IMAP extensions for an implementation 178 to consider. Reviews were provided by Martin Durst, Carl Wallace, 179 Wassim Haddad, and Juergen Schoenwaelder. 181 7. Changelog 183 7.1. 06 to 07 185 o Editorial tweaks and clarifications based on IETF LC reviews. 187 7.2. 05 to 06 189 o Added a requirement making it explicit that this interface won't 190 allow users to delete, insert, or move messages between archives. 192 o Clarified how the would allow access without credentials (at 193 Alexey's suggestion). 195 o Pointed to potential resource abuse issues in the security 196 considerations section. 198 7.3. 04 to 05 200 o Adapted text from RFC6778 to make it more clear that both 201 authenticated and unauthenticated access should be supported. 203 7.4. 03 to 04 205 o Incorporated suggestions from Pete Resnick and Barry Leiba. 207 7.5. 02 to 03 209 o None - expiry refresh 211 7.6. 01 to 02 212 o Minor editorial changes 214 7.7. 00 to 01 216 o Added requirements to enable controlled access to restricted 217 archives based on credentials 219 o Generalized the requirement to use the datatracker's credentials. 221 7.8. 00 223 o Split this set of requirements out from the mailarch doc so that 224 this project could be pursued separately 226 8. Informative References 228 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 229 4rev1", RFC 3501, March 2003. 231 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 232 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 234 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access 235 Protocol - SORT and THREAD Extensions", RFC 5256, June 236 2008. 238 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access 239 Protocol - ANNOTATE Extension", RFC 5257, June 2008. 241 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, 242 February 2009. 244 [RFC6203] Sirainen, T., "IMAP4 Extension for Fuzzy Search", RFC 245 6203, March 2011. 247 [RFC6237] Leiba, B. and A. Melnikov, "IMAP4 Multimailbox SEARCH 248 Extension", RFC 6237, May 2011. 250 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 251 Email", RFC 6531, February 2012. 253 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 254 Email Headers", RFC 6532, February 2012. 256 [RFC6778] Sparks, R., "Requirements for Archiving IETF Email Lists 257 and for Providing Web-Based Browsing and Searching", RFC 258 6778, October 2012. 260 [RFC6855] Resnick, P., Newman, C., and S. Shen, "IMAP Support for 261 UTF-8", RFC 6855, March 2013. 263 Author's Address 264 Robert Sparks 265 Tekelec 266 17210 Campbell Road 267 Suite 250 268 Dallas, Texas 75254-4203 269 USA 271 Email: rjsparks@nostrum.com