<?xml version="1.0" encoding="US-ASCII"?>
<!--xml2rfc v2 used-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc3501 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml'>
  <!ENTITY rfc6778 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6778.xml'>
  <!ENTITY rfc5257 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5257.xml'>
  <!ENTITY rfc5464 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5464.xml'>
  <!ENTITY rfc5256 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5256.xml'>
  <!ENTITY rfc6237 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6237.xml'>
  <!ENTITY rfc6203 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6203.xml'>
  <!ENTITY rfc4505 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4505.xml'>
  <!ENTITY rfc6532 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6532.xml'>
  <!ENTITY rfc6531 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6531.xml'>
  <!ENTITY rfc6855 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6855.xml'>
]>

<?rfc toc="yes" ?>
<?rfc rfcedstyle="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc symrefs="yes" ?>

<rfc number="7017" submissionType="IETF" ipr="trust200902" category="info" consensus="yes">

<front>

<title abbrev="IMAP Access to IETF Email List Archives">
IMAP Access to IETF Email List Archives
</title>

<author initials="R." surname="Sparks" fullname="Robert Sparks" >
 <organization>Oracle</organization>
 <address>
 <postal>
 <street>17210 Campbell Road</street>
 <street>Suite 250</street>
 <city>Dallas</city>
 <region>Texas</region>
 <code>75254-4203</code>
 <country>USA</country>
 </postal>
 <email>rjsparks@nostrum.com</email>
 </address>
</author>

<date month="August" year="2013" />



<abstract>
<t>
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. 
</t>
</abstract>

</front>

<middle>

<section anchor="intro" title="Introduction">
<t>
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 <xref target="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. 
</t>
</section>

<section title="Requirements for IMAP Access to Archived IETF Lists">
<t>Many participants would prefer to access the list archives using IMAP <xref target="RFC3501"/>. Providing this access while meeting the following requirements will likely require an IMAP server with specialized capabilities.</t>
<t><list style="hanging">
<t hangText="o">The system should expose the archive using an IMAP interface, with each list
represented as a mailbox.</t>
<t hangText="o">This interface must work with standard IMAP clients.</t>
<t hangText="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 <xref target="RFC5257"/> and METADATA <xref target="RFC5464"/>.</t>
<t hangText="o">It must be possible for administrators to set per-user storage quotas, limiting the space a user can consume with annotations.</t>
<t hangText="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.) </t>
<t hangText="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 <xref target="RFC6778"/>. The implementation should consider taking advantage of the extensions defined for IMAP SORT and THREAD <xref target="RFC5256"/>, multimailbox search <xref target="RFC6237"/>, and fuzzy search <xref target="RFC6203"/>.</t>
<t hangText="o">When the system requires credentials, it must use the datatracker's authentication system.

<list style="hanging">
<t hangText="-">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.</t>
<t hangText="-">
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 <xref target="RFC4505"/> or a LOGIN command with a special username (such as "anonymous") determined by the administrator.</t>
</list></t>

</list></t>
</section>

<section title="Internationalized Address Considerations">
<t>The implementation should anticipate internationalized email addresses as discussed in the following three documents:
<xref target="RFC6532"/>,
<xref target="RFC6531"/>, and
<xref target="RFC6855"/>.
 There is no firm requirement at this time.</t>
</section>

<section title="Security Considerations">
<t>
   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.
</t>
<t> 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.</t>
<t> 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.</t>
</section>

<section title="Acknowledgements">
<t>
This text was derived directly from an early version of the document that became <xref target="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.
</t>
</section>


</middle>
<back>

<!--
<references title="Normative References">
</references>
-->

<references title="Informative References">
&rfc3501;
&rfc6778;
&rfc5257;
&rfc5464;
&rfc5256;
&rfc6237;
&rfc6203;
&rfc4505;
&rfc6532;
&rfc6531;
&rfc6855;
</references>

</back>
	
</rfc>
