<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2047 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2047.xml">
  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
  <!ENTITY RFC2822 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml">
  <!ENTITY RFC5255 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5255.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-morg-sortdisplay-00" ipr="trust200811"
     updates="5256">
  <front>
    <title abbrev="IMAP4 Display-based Address Sorting">Display-based Address Sorting for the IMAP4 SORT Extension</title>
    <author fullname="Dan Karp" initials="D.K." surname="Karp">
      <organization abbrev="Zimbra">Zimbra, a Yahoo! Company</organization>
      <address>
        <postal>
          <street>701 First St.</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>
          <country>USA</country>
        </postal>
        <email>dkarp@zimbra.com</email>
        <uri>http://www.zimbra.com</uri>
      </address>
    </author>

    <date month="January" year="2009"/>

    <area>General</area>

    <workgroup>Message Organization Working Group</workgroup>

    <keyword>IMAP4</keyword>
    <keyword>sorting</keyword>

    <abstract>
      <t>This document describes an IMAP protocol extension enabling
         server-side message sorting based on the commonly-displayed
         portion of the From header.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="keywords" 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>
    </section>

    <section anchor="intro" title="Introduction">
      <t>The <xref target="SORT"/> extension to the <xref target="IMAP"/>
         protocol provides a means for server-based sorting of messages.
         It defines a set of sort criteria and the mechanism for
         determining the sort value of a message for each such
         ordering.</t>

      <t>The <xref target="SORT"/> extension's FROM ordering sorts messages
         lexically on the <xref target="IMAP"/> addr-part of the first
         address in the From header.  This document provides an alternate
         ordering, DISPLAYFROM, which sorts messages lexically based on the
         From address's <xref target="RFC2822"/> display-name, when
         present.</t>

      <t>A server that supports the DISPLAYFROM sort criterion indicates
         this by returning "SORT=DISPLAYFROM" in its CAPABILITY
         response.</t>
    </section>

    <section anchor="sortkey" title="The DISPLAYFROM Sort Key">
      <t>This document introduces a new <xref target="SORT"/> sort-key,
         DISPLAYFROM.</t>

      <t>A message's sort value under the DISPLAYFROM ordering MUST be
         derived from the first <xref target="RFC2822"/> mailbox in its
         From header as follows:

         <list style="symbols">
           <t>If the From header is absent or if the header contains no
              mailboxes, the message's sort value is the empty string.</t>

           <t>If the mailbox contains an <xref target="RFC2822"/>
              display-name, replace each instance of <xref
              target="RFC2822"/> CFWS in the display-name with a single
              space, trim all leading and trailing whitespace, and decode
              any <xref target="RFC2047"/> encoded-words.  If the resulting
              string is not the empty string, use it as the sort value for
              the message.</t>

           <t>Otherwise, completely remove all <xref target="RFC2822"/>
              CFWS from the mailbox's <xref target="RFC2822"/> addr-spec
              and use the resulting string as the message's sort value.</t>
         </list></t>
    </section>

    <section anchor="ABNF" title="Formal Syntax">
      <figure>
        <preamble>
          The following syntax specification uses the Augmented Backus-Naur
          Form (ABNF) notation as specified in <xref target="RFC4234"/>.
          <xref target="IMAP"/> defines the non-terminal "capability" and
          <xref target="SORT"/> defines "sort-key".
        </preamble>

        <artwork type="abnf" align="left-3em"><![CDATA[
capability    =/ "SORT=DISPLAYFROM"

sort-key      =/ "DISPLAYFROM"
        ]]></artwork>
      </figure>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document defines an additional IMAP4 capability.  As such, it
         does not change the underlying security considerations of <xref
         target="IMAP"/>.  The author believes that no new security issues
         are introduced with this additional IMAP4 capability.</t>
    </section>

    <section anchor="I18N" title="Internationalization Considerations">
      <t>DISPLAYFROM is a string-based sort criterion.  As stated in <xref
         target="SORT"/>, the collations mandated by I18NLEVEL=1 or
         I18NLEVEL=2 from <xref target="RFC5255"/> MUST be followed when
         sorting such strings.</t>

      <t>The DISPLAYFROM ordering sorts on the full decoded <xref
         target="RFC2822"/> display-name, when present.  It does not
         attempt to parse this string in a locale- or language-dependent
         manner in order to determine and sort on some semantically
         meaningful substring such as the surname.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t><xref target="IMAP"/> capabilities are registered by publishing a
         standards track or IESG-approved experimental RFC.  This document
         constitutes registration of the SORT=DISPLAYFROM capability in the
         <xref target="IMAP"/> capabilities registry.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2047;
      &RFC2119;
      &RFC2822;
      &RFC4234;
      &RFC5255;

      <reference anchor="IMAP">
        <front>
          <title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
          <author initials="M.C." surname="Crispin" fullname="Mark R. Crispin">
            <organization>University of Washington</organization>
          </author>
          <date month="March" year="2003"/>
        </front>
        <seriesInfo name="RFC" value="3501"/>
        <format type="TXT" target="http://www.ietf.org/rfc/rfc3501.txt"/>
      </reference>

      <reference anchor="SORT">
        <front>
          <title>Internet Message Access Protocol - SORT and THREAD Extensions</title>
          <author initials="M.C." surname="Crispin" fullname="Mark R. Crispin">
            <organization>University of Washington</organization>
          </author>
          <author initials="K.M." surname="Murchison" fullname="Kenneth Murchison">
            <organization>Carnegie Mellon University</organization>
          </author>
          <date month="June" year="2008"/>
        </front>
        <seriesInfo name="RFC" value="5256"/>
        <format type="TXT" target="http://www.ietf.org/rfc/rfc5256.txt"/>
      </reference>
    </references>
  </back>
</rfc>
