<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" category="std" updates="3501"
     docName="draft-melnikov-imap-capabilities-00">
  <front>
    <title abbrev="IMAP CAPABILITY clarification">
      Clarification on IMAP CAPABILITY command behaviour
    </title>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization>Isode Ltd</organization>
      <address>
	      <postal>
	        <street>14 Castle Mews</street>
	        <city>Hampton</city>
	        <region>Middlesex</region>
	        <code>TW12 2NP</code>
	        <country>UK</country>
	      </postal>
	      <email>Alexey.Melnikov@isode.com</email>
      </address>
    </author>
    
    <date year="2015" />
    
    <keyword>IMAP</keyword>
    <keyword>CAPABILITY</keyword>

    <abstract>
      <t>
        This document clarifies how IMAP (RFC 3501) server implementations should handle CAPABILITY command.
      </t>
    </abstract>
    
  </front>
  <middle>
      
    <section title="Introduction">

      <t>This document clarifies how <xref target="RFC3501">IMAP</xref> server implementations should respond
      to CAPABILITY command or what they should return in CAPABILITY response code at different points in IMAP connection.
      This document updates RFC 3501.
      </t>
      
      <t>A CAPABILITY response or CAPABILITY response codes return a listing of capabilities that
      the server supports. RFC 3501 didn't specify whether advertised capabilities can change over time
      and, if they can, at which points in IMAP connection. This document clarifies that.
      </t>

    </section>
    
    <section title="Conventions Used in This Document">

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	    this document are to be interpreted as described in
	    <xref target="RFC2119"/>.</t>

      <t>The term "IMAP connection" or just "connection" is as specified in <xref target="RFC3501"/>.</t>
      
    </section>
      
    <section title="Clarification on CAPABILITY response/response code">

      <t>Two successive CAPABILITY commands (with no commands in between them) MUST return the same list of capabilities.</t>

      <t>The list of capabilities is generally static, but it can change at 2 points in IMAP connection ("security state change points"): after a successful STARTTLS command
      and after a successful LOGIN or AUTHENTICATE command. (<cref>UNAUTHENTICATE extension would add a third point.</cref>) The list of capabilities MUST NOT change at any other points.</t>

      <t>With a small number of exceptions, capabilities can't be removed, they can only be added or their parameters might change.
      Once a capability is announced, it can't be taken away in a subsequent CAPABILITY response, except for a few very limited cases.
      For example, after STARTTLS command is successful, the STARTTLS capability doesn't need to be advertised (but it is not an error if it is).
      <!--////Is LOGINDISABLED also special after STARTTLS?-->
      </t>

      <t>Capabilities that include parameter(s) can change their parameters at security state change points.
      The later parameter(s) replace any previously announced parameters.</t>

      <!--////CAPABILITY response code and CAPABILITY command can differ, explain how-->
      <t>A CAPABILITY response code can contain the same information as a CAPABILITY response. Some implementations only return capabilities that apply in non-authenticated state
      before authentication and only capabilities that apply in authenticated/selected state after authentication.</t>

    </section>

    <section title="Examples">

      <t>TBD. One example: after STARTTLS, AUTH=PLAIN and/or AUTH=EXTERNAL can be advertised.</t>

      <t>Second example: Show changing APPENDLIMIT parameter after authentication.</t>
      
    </section>

    <section title="IANA Considerations">
	
      <t>This document doesn't require any action from IANA.</t>
	
    </section>
    
    <section title="Security Considerations" anchor="seccons">

	    <t>TBD</t>

    </section>
    
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?> <!-- Keywords -->
      <?rfc include="reference.RFC.3501"?> <!-- IMAP -->

    </references>

    <section title="Acknowledgements">
	
      <!--
      <t>
      Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ Housley, Alessandro Vesely, Harald Alvestrand and John Levine for comments on this document.
      </t>
      -->

      <t>TBD.</t>
	
    </section>

  </back>
</rfc>
