<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc tocindent="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>

<rfc
  category="std"
  ipr="trust200902"
  docName="draft-leiba-extra-specialuse-important-00">

  <front>
    <title abbrev='IMAP "Important" Keyword and Attribute'>
      IMAP $Important Keyword and \Important Special-Use Attribute
    </title>

    <author initials='B.' surname='Leiba' fullname='Barry Leiba' role='editor'>
      <organization>Huawei Technologies</organization>
      <address>
        <phone>+1 646 827 0648</phone>
        <email>barryleiba@computer.org</email>
        <uri>http://internetmessagingtechnology.org/</uri>
      </address>
    </author>

    <date/>
    <area>Applications</area>
    <keyword>IMAP attributes</keyword>

    <abstract><t>
      RFC 6154 created an IMAP Special-Use LIST extension and defined an initial set of attributes.  This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, registering the attributes defined in RFCs 3348, 3501, and 6154.
      This document also defines a new IMAP keyword, "$Important", and registers it in the registry
      defined in RFC 5788.
    </t></abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        The Internet Message Access Protocol (IMAP) specification <xref target="RFC3501"/> defines the use of message keywords, and an IMAP Keywords registry is created in <xref target="RFC5788"/>.  <xref target="RFC6154"/> defines an extension to the IMAP LIST command for special-use mailboxes.  The extension allows servers to provide extra information (attributes) about the purpose of a mailbox and defines an initial set of special-use attributes.
      </t>
      <t>
        This document does the following:
        <list style="symbols">
          <t>
            Defines a new message keyword, "$Important", to apply to messages that are considered important for the user, by some externally defined criteria.
          </t>
          <t>
            Registers the "$Important" keyword in the IMAP Keywords registry.
          </t>
          <t>
            Defines a new special-use attribute, "\Important", to designate a mailbox that will hold messages that are considered important for the user, by some externally defined criteria.
          </t>
          <t>
            Creates a registry for IMAP mailbox attributes and registers the new attribute and those defined in <xref target="RFC3348"/>, <xref target="RFC3501"/>, and <xref target="RFC6154"/>.
          </t>
        </list>
      </t>

      <section title="Conventions used in this document">
        <t>
          In examples, "C:" indicates lines sent by a client that is connected
          to a server.  "S:" indicates lines sent by the server to the client.
        </t>
      </section>
    </section>

    <section anchor="ImpKwd" title="Definition of the '$Important' Message Keyword">
      <t>
        The "$Important" keyword is a signal that a message is likely important to the user.
        The keyword can be set by the user, or automatically by the system based on available signals (such as who the message is from, who else the message is addressed to, evaluation of the subject or content, or other heuristics).
      </t>
      <t>
        This is distinct from the "\Flagged" system flag in two ways:
        <list style="numbers">
          <t>
            "$Important" carries a specific meaning of importance, as opposed to urgency.  It is meant to be used for a form of triage, with "\Flagged" remaining as a designation of special attention or particular urgency.
          </t>
          <t>
            The setting of "$Important" is expected to be based at least partly on heuristics, whereas "\Flagged" is intended to be set by the user.
          </t>
        </list>
      </t>
    </section>

    <section title="Definition of the 'Important' Mailbox Attribute">
      <t>
        The "\Important" mailbox attribute is a signal that the mailbox contains messages that are likely important to the user.  In an implementation that also supports the "$Important" keyword, this special use is likely to represent a virtual mailbox collecting messages (from other mailboxes) that are marked with the "$Important" keyword.  In other implementations, the system might automatically put messages there based on the same sorts of heuristics that are noted for the "$Important" keyword (see <xref target="ImpKwd"/>).  The distinction between "\Important" and "\Flagged" for mailboxes is similar to those between "$Important" and "\Flagged" for messages.
      </t>
      <section title="Formal Syntax">
        <t>
          The following syntax specification adds to the one in <xref target="RFC6154"/>, Section 6, using Augmented Backus-Naur Form (ABNF) as described in <xref target="RFC5234" />.
          <figure><artwork>
    use-attr      =/  "\Important"
          </artwork></figure>
        </t>
      </section>
      <section title="Example">
        <t>
          In the following example, the mailbox called "Important Messages" is the one designated with the "\Important" attribute.
          <figure><artwork>
    C: t1 list "" "Imp*"
    S: * LIST (\HasNoChildren \Important) "/" "Important Messages"
    S: * LIST (\HasNoChildren) "/" "Imported Wine"
    S: t1 OK Success
          </artwork></figure>
        </t>
      </section>
    </section>

    <section anchor="sec" title="Security Considerations">
      <t>
        The security considerations in <xref target="RFC6154"/>, Section 7, apply equally to this extension.  In particular, "Conveying special-use information to a client exposes a small bit of extra information that could be of value to an attacker."  Moreover, identifying "important" messages or a place where important messages are kept could give an attacker a strategic starting point.  If the algorithm by which messages are determined to be important is well known, still more information is exposed -- perhaps, for example, there is an implication that the senders of these messages are particularly significant to the mailbox owner, and perhaps that is information that should not be made public.
      </t>
      <t>
        As noted in RFC 6154, it is wise to protect the IMAP channel from passive eavesdropping, and to defend against unauthorized discernment of the identity of a user's "\Important" mailbox or of a user's "$Important" messages.
      </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>
        This document contains 3 actions for IANA, specified in the sections below:
        <list style="numbers">
          <t>
            Registration of the "$Important" keyword.
          </t>
          <t>
            Creation of a new "IMAP Mailbox Name Attributes" registry.
          </t>
          <t>
            Registration of initial entries in the "IMAP Mailbox Name Attributes" registry.
          </t>
        </list>
      </t>

      <section title="Registration of the $Important keyword">
        <t>
          IANA is asked to register the $Important keyword in the "IMAP Keywords" registry, as follows, using the template in <xref target="RFC5788"/>.
          <list style="hanging" hangIndent="6">
            <t hangText="IMAP keyword name:">
              $Important
            </t>
            <t hangText="Purpose (description):">
              The "$Important" keyword is a signal that a message is likely important to the user.
            </t>
            <t hangText="Private or Shared on a server:">
              PRIVATE
            </t>
            <t hangText="Is it an advisory keyword or may it cause an automatic action:">
              Advisory (but see the reference for details).
            </t>
            <t hangText="When/by whom the keyword is set/cleared:">
              The keyword can be set by the user, or automatically by the system based on available signals (such as who the message is from, who else the message is addressed to, evaluation of the subject or content, or other heuristics).
            </t>
            <t hangText="Related keywords:">
              None (but see the reference for the related mailbox name attribute).
            </t>
            <t hangText="Related IMAP capabilities:">
              None.
            </t>
            <t hangText="Security considerations:">
              See [[THIS RFC]], <xref target="sec"/>
            </t>
            <t hangText="Published specification:">
              [[THIS RFC]]
            </t>
            <t hangText="Person &amp; email address to contact for further information:">
              IETF Applications Area &lt;apps-discuss@ietf.org&gt;
            </t>
            <t hangText="Intended usage:">
              COMMON
            </t>
            <t hangText="Owner/Change controller:">
              IESG
            </t>
            <t hangText="Note:">
              None.
            </t>
          </list>
        </t>
      </section>

      <section title="Creation of the IMAP Mailbox Name Attributes Registry">
        <t>
          IANA is asked to create a new registry in the group "Internet Message Access Protocol (IMAP)".  The new registry will be called "IMAP Mailbox Name Attributes", and will have two references: "RFC 3501, Section 7.2.2", and "[[THIS RFC]], <xref target="iana"/>".
        </t>
        <t>
          The registry entries will contain three fields:
        </t>
        <t>
          <list style="numbers">
            <t>Attribute Name</t>
            <t>Description</t>
            <t>Reference</t>
          </list>
        </t>
        <t>
          IANA will keep this list in alphabetical order by Attribute Name, which is registered without the initial backslash ("\").
        </t>
        <t>
          The registration policy for the new registry will be listed as "IETF Review or Expert Review" <xref target="RFC8126"/>, and new registrations will be accepted in one of two ways:
          <list style="numbers">
            <t>
              For registrations requested in an IETF consensus document, the registration policy will be IETF Review, and the request will be made in the IANA Considerations section of the document, giving the requested values for each of the three fields.
            </t>
            <t>
              For other registrations, the policy will be Expert Review policy (see <xref target="DEinst"/>), and the request will be made by sending email to IANA asking for a new IMAP Mailbox Name Attribute and giving the requested values for each of the three fields.
            </t>
          </list>
        </t>
        <section anchor="DEinst" title="Instructions to the Designated Expert">
          <t>
            The expert reviewer, who will be designated by the IESG, is expected to provide only a general review of the requested registration, checking that the reference and description are adequate for understanding the intent of the registered attribute.  Efforts should also be made to generalize the intent of an attribute so that multiple implementations with the same requirements may reuse existing attributes.  Except for this check, this is intended to be very close to a first come first served policy, and the expert should not block serious registration requests with a reasonable reference.  The reference may be to any form of documentation, including a web page, but consideration should be given to providing one that is expected to be long-lived and stable.
          </t>
        </section>
      </section>

      <section title="Initial Entries for the IMAP Mailbox Name Attributes Registry">
        <t>The registry will initially contain these entries:
        <figure><artwork>
+===============+===================================+===========+
| Attribute     | Description                       | Reference |
| Name          |                                   |           |
+===============+===================================+===========+
| All           | All messages                      | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Archive       | Archived messages                 | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Drafts        | Messages that are working drafts  | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Flagged       | Messages with the \Flagged flag   | [RFC6154] |
+---------------+-----------------------------------+-----------+
| HasChildren   | Has accessible child mailboxes    | [RFC3348] |
+---------------+-----------------------------------+-----------+
| HasNoChildren | Has no accessible child mailboxes | [RFC3348] |
+---------------+-----------------------------------+-----------+
| Important     | Messages deemed important to user | THIS RFC  |
+---------------+-----------------------------------+-----------+
| Junk          | Messages identified as Spam/Junk  | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Marked        | Server has marked the mailbox as  | [RFC3501] |
|               | "interesting"                     |           |
+---------------+-----------------------------------+-----------+
| NoInferiors   | No hierarchy under this name      | [RFC3501] |
+---------------+-----------------------------------+-----------+
| Noselect      | The mailbox is not selectable     | [RFC3501] |
+---------------+-----------------------------------+-----------+
| Sent          | Sent mail                         | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Trash         | Messages the user has discarded   | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Unmarked      | No new messages since last select | [RFC3501] |
+===============+===================================+===========+
        </artwork></figure>
        </t>
      </section>
    </section>

    <section title="Changes During Document Development">
      <t><cref>RFC Editor: Please remove this section prior to publication.</cref></t>
      <t>Changes in -02
        <list style="symbols">
        <t>
          Added the definition and registration of $Important.
        </t>
        <t>
          Noted that \Important might be implemented as a virtual collection of $Important messages.
        </t>
        </list>
      </t>
      <t>Changes in -01
        <list style="symbols">
        <t>
          Expanded the new registry to all mailbox name attributes, and added the attributes from 3501 and 3348 (suggested by Alexey).  This also adds those two documents to the "updates" list.
        </t>
        <t>
          Recorded Cyrus's suggestion to define $Important.
        </t>
        </list>
      </t>
    </section>

    <section title="Contributors">
      <t>
        The following author was an original contributor to this document in addition to the editor.
          <vspace blankLines="1"/>
          Eric "Iceman"
          <vspace blankLines="0"/>
          Google
          <vspace blankLines="0"/>
          iceman@google.com
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.3501" ?>
      <?rfc include="reference.RFC.5234" ?>
      <?rfc include="reference.RFC.6154" ?>
      <?rfc include="reference.RFC.8126" ?>
    </references>
    <references title="Informative References">
      <?rfc include="reference.RFC.3348" ?>
      <?rfc include="reference.RFC.5788" ?>
    </references>
  </back>
</rfc>
