1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc7017.txt b/doc/rfc/rfc7017.txt
new file mode 100644
index 0000000..6144df2
--- /dev/null
+++ b/doc/rfc/rfc7017.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         R. Sparks
+Request for Comments: 7017                                        Oracle
+Category: Informational                                      August 2013
+ISSN: 2070-1721
+
+
+                IMAP Access to IETF Email List Archives
+
+Abstract
+
+   The IETF makes heavy use of email lists to conduct its work.  This
+   often involves accessing the archived history of those email lists.
+   Participants would like to have the ability to browse and search
+   those archives using standard IMAP clients.  This memo captures the
+   requirements for providing a service that would allow such browsing
+   and searching, and it is intended as input to a later activity for
+   the design and development of such a service.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7017.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Sparks                        Informational                     [Page 1]
+
+RFC 7017         IMAP Access to IETF Email List Archives     August 2013
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Requirements for IMAP Access to Archived IETF Lists . . . . .   2
+   3.  Internationalized Address Considerations  . . . . . . . . . .   3
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
+   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
+   6.  Informative References  . . . . . . . . . . . . . . . . . . .   4
+
+1.  Introduction
+
+   The IETF makes heavy use of email lists to conduct its work.  This
+   often involves accessing the archived history of those email lists.
+   Requirements for improved web-based browsing and searching of these
+   archives are captured in [RFC6778].  Participants would like to have
+   the ability to browse and search those archives using standard IMAP
+   clients.  This memo captures the requirements for providing a service
+   that would allow such browsing and searching, and it is intended as
+   input to a later activity for the design and development of such a
+   service.
+
+2.  Requirements for IMAP Access to Archived IETF Lists
+
+   Many participants would prefer to access the list archives using IMAP
+   [RFC3501].  Providing this access while meeting the following
+   requirements will likely require an IMAP server with specialized
+   capabilities.
+
+   o  The system should expose the archive using an IMAP interface, with
+      each list represented as a mailbox.
+
+   o  This interface must work with standard IMAP clients.
+
+   o  The interface should allow users that have provided credentials to
+      each have their own read/unread marks for messages.  Allowing
+      other annotation is desirable.  The implementation should consider
+      taking advantage of the IMAP extensions for ANNOTATE [RFC5257] and
+      METADATA [RFC5464].
+
+   o  It must be possible for administrators to set per-user storage
+      quotas, limiting the space a user can consume with annotations.
+
+   o  The interface must not allow users to modify the underlying
+      message or metadata other than the read/unread marks and
+      annotations described above.  Specifically, users must not be able
+      to delete or insert messages, or move them between mailboxes in
+      the archive.  (Clients will, of course, be able to make local
+      copies of messages from the archive.)
+
+
+
+Sparks                        Informational                     [Page 2]
+
+RFC 7017         IMAP Access to IETF Email List Archives     August 2013
+
+
+   o  The interface must have server-side searching enabled and should
+      scale to support multiple simultaneous extensive searches.  The
+      server should provide the enhanced search capabilities described
+      in [RFC6778].  The implementation should consider taking advantage
+      of the extensions defined for IMAP SORT and THREAD [RFC5256],
+      multimailbox search [RFC6237], and fuzzy search [RFC6203].
+
+   o  When the system requires credentials, it must use the
+      datatracker's authentication system.
+
+      -     While the vast majority of archived lists have an open
+            access policy, some archived lists have restricted archives.
+            The system must make it possible to limit access to a
+            restricted archive based on login credentials.
+
+      -     The system must allow access to open archives with or
+            without providing credentials.  Specifically, the system
+            will allow anonymous access using the Simple Authentication
+            and Security Layer (SASL) ANONYMOUS mechanism [RFC4505] or a
+            LOGIN command with a special username (such as "anonymous")
+            determined by the administrator.
+
+3.  Internationalized Address Considerations
+
+   The implementation should anticipate internationalized email
+   addresses as discussed in the following three documents: [RFC6532],
+   [RFC6531], and [RFC6855].  There is no firm requirement at this time.
+
+4.  Security Considerations
+
+   Allowing IMAP as an interface for browsing and searching the archives
+   of IETF email lists does not affect the security of the Internet in
+   any significant fashion.
+
+   Searching can be input/output (I/O) and CPU intensive.  Clients that
+   make local copies of all messages in a mailbox can also present an
+   I/O burden, particularly when synchronizing for the first time.  The
+   implementors of this interface should consider the potential for
+   maliciously crafted searches attempting to consume a damaging amount
+   of resources.  The implementors should consider the potential for
+   denial-of-service attacks through making many connections to the
+   interface.  The implementors should consider ways to rate limit I/O
+   due to making local copies of messages.
+
+
+
+
+
+
+
+
+Sparks                        Informational                     [Page 3]
+
+RFC 7017         IMAP Access to IETF Email List Archives     August 2013
+
+
+   Storing read/unread marks and other annotations requires potentially
+   unbounded storage space.  The implementors of this interface should
+   consider the potential for maliciously crafted annotations attempting
+   to consume a damaging amount of storage space.  The implementors
+   should consider making it easy to alert the administrator when a user
+   begins consuming exceptional amounts of space.
+
+5.  Acknowledgements
+
+   This text was derived directly from an early version of the document
+   that became [RFC6778], which incorporated text suggestions from
+   Alexey Melnikov, Pete Resnick, and S. Moonesamy.  Barry Leiba
+   suggested several references to IMAP extensions for an implementation
+   to consider.  Reviews were provided by Martin Duerst, Carl Wallace,
+   Wassim Haddad, and Juergen Schoenwaelder.
+
+6.  Informative References
+
+   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, March 2003.
+
+   [RFC4505]  Zeilenga, K., "Anonymous Simple Authentication and
+              Security Layer (SASL) Mechanism", RFC 4505, June 2006.
+
+   [RFC5256]  Crispin, M. and K. Murchison, "Internet Message Access
+              Protocol - SORT and THREAD Extensions", RFC 5256, June
+              2008.
+
+   [RFC5257]  Daboo, C. and R. Gellens, "Internet Message Access
+              Protocol - ANNOTATE Extension", RFC 5257, June 2008.
+
+   [RFC5464]  Daboo, C., "The IMAP METADATA Extension", RFC 5464,
+              February 2009.
+
+   [RFC6203]  Sirainen, T., "IMAP4 Extension for Fuzzy Search", RFC
+              6203, March 2011.
+
+   [RFC6237]  Leiba, B. and A. Melnikov, "IMAP4 Multimailbox SEARCH
+              Extension", RFC 6237, May 2011.
+
+   [RFC6531]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
+              Email", RFC 6531, February 2012.
+
+   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
+              Email Headers", RFC 6532, February 2012.
+
+
+
+
+
+
+Sparks                        Informational                     [Page 4]
+
+RFC 7017         IMAP Access to IETF Email List Archives     August 2013
+
+
+   [RFC6778]  Sparks, R., "Requirements for Archiving IETF Email Lists
+              and for Providing Web-Based Browsing and Searching", RFC
+              6778, October 2012.
+
+   [RFC6855]  Resnick, P., Newman, C., and S. Shen, "IMAP Support for
+              UTF-8", RFC 6855, March 2013.
+
+Author's Address
+
+   Robert Sparks
+   Oracle
+   17210 Campbell Road
+   Suite 250
+   Dallas, Texas  75254-4203
+   USA
+
+   EMail: rjsparks@nostrum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks                        Informational                     [Page 5]
+