doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc5957.txt b/doc/rfc/rfc5957.txt
new file mode 100644
index 0000000..32adb49
--- /dev/null
+++ b/doc/rfc/rfc5957.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           D. Karp
+Request for Comments: 5957                                        Zimbra
+Updates: 5256                                                  July 2010
+Category: Standards Track
+ISSN: 2070-1721
+
+
+       Display-Based Address Sorting for the IMAP4 SORT Extension
+
+Abstract
+
+   This document describes an IMAP protocol extension enabling server-
+   side message sorting on the commonly displayed portion of the From
+   and To header fields.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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/rfc5957.
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+
+
+
+
+
+
+
+Karp               IMAP4 Display-Based Address Sorting          [Page 1]
+
+RFC 5957                                                       July 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................2
+   3. DISPLAY Sort Value for an Address ...............................2
+   4. The DISPLAYFROM and DISPLAYTO Sort Criteria .....................3
+   5. Formal Syntax ...................................................3
+   6. Security Considerations .........................................3
+   7. Internationalization Considerations .............................4
+   8. IANA Considerations .............................................4
+   9. Normative References ............................................4
+
+1.  Introduction
+
+   The [SORT] extension to the [IMAP] protocol provides a means for the
+   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.
+
+   The [SORT] FROM and TO orderings sort messages lexically on the
+   [IMAP] addr-mailbox of the first address in the message's From and To
+   headers, respectively.  This document provides two alternative
+   orderings, DISPLAYFROM and DISPLAYTO, which sort messages based on
+   the first From or To address's [IMAP] addr-name (generally the same
+   as its [RFC5322] display-name), when present.
+
+   A server that supports the full [SORT] extension as well as both the
+   DISPLAYFROM and DISPLAYTO sort criteria indicates this by returning
+   "SORT=DISPLAY" in its CAPABILITY response.
+
+2.  Conventions Used in This Document
+
+   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 [RFC2119].
+
+3.  DISPLAY Sort Value for an Address
+
+   For the purposes of the sort criteria defined in this document, the
+   sort value for an [IMAP] address structure is defined as follows:
+
+   o  If the address structure's [IMAP] addr-name is non-NIL, apply the
+      procedure from [RFC5255], Section 4.6.  (That is, decode any
+      [RFC2047] encoded-words and convert the resulting character string
+      into a charset valid for the currently active [RFC4790] collation,
+      with a default of UTF-8.)  If the resulting octet string is not
+      the empty string, use it as the sort value for the address.
+
+
+
+
+Karp               IMAP4 Display-Based Address Sorting          [Page 2]
+
+RFC 5957                                                       July 2010
+
+
+   o  Otherwise, if the address structure's [IMAP] addr-mailbox and
+      [IMAP] addr-host are both non-NIL, the sort value for the address
+      is addr-mailbox@addr-host.
+
+   o  Otherwise, if the address structure's [IMAP] addr-mailbox is non-
+      NIL, the sort value for the address is its addr-mailbox.
+
+   o  If none of the above conditions are met, the sort value for the
+      address is the empty string.
+
+4.  The DISPLAYFROM and DISPLAYTO Sort Criteria
+
+   This document introduces two new [SORT] sort criteria, DISPLAYFROM
+   and DISPLAYTO.  A message's sort value under these orderings MUST be
+   derived as follows:
+
+   A "derived-addr" value is created from the [IMAP] envelope structure
+   resulting from a FETCH ENVELOPE on the message.  For DISPLAYFROM, the
+   derived-addr value is the [IMAP] env-from value.  For DISPLAYTO, the
+   derived-addr value is the [IMAP] env-to value.
+
+   o  If the derived-addr value is NIL, the message's sort value is the
+      empty string.
+
+   o  Otherwise, the message's sort value is the DISPLAY sort value of
+      the first [IMAP] address in the derived-addr value.
+
+5.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [RFC5234].  [IMAP] defines the
+   non-terminal "capability", and [SORT] defines "sort-key".
+
+   capability    =/ "SORT=DISPLAY"
+
+   sort-key      =/ "DISPLAYFROM" / "DISPLAYTO"
+
+6.  Security Considerations
+
+   This document defines an additional IMAP4 capability.  As such, it
+   does not change the underlying security considerations of [IMAP].
+   The author believes that no new security issues are introduced with
+   this additional IMAP4 capability.
+
+
+
+
+
+
+
+
+Karp               IMAP4 Display-Based Address Sorting          [Page 3]
+
+RFC 5957                                                       July 2010
+
+
+7.  Internationalization Considerations
+
+   DISPLAYFROM and DISPLAYTO are string-based sort criteria.  As stated
+   in [SORT], the active [RFC4790] collation as per [RFC5255] MUST be
+   used when sorting such strings.
+
+   The DISPLAYFROM and DISPLAYTO orderings sort on the full decoded
+   [IMAP] addr-name, when present.  They do 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.
+
+8.  IANA Considerations
+
+   [IMAP] capabilities are registered by publishing a Standards Track or
+   IESG-approved Experimental RFC.  This document constitutes
+   registration of the SORT=DISPLAY capability in the [IMAP]
+   capabilities registry.
+
+9.  Normative References
+
+   [IMAP]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, March 2003.
+
+   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+              Part Three: Message Header Extensions for Non-ASCII Text",
+              RFC 2047, November 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
+              Application Protocol Collation Registry", RFC 4790, March
+              2007.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234, January
+              2008.
+
+   [RFC5255]  Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
+              Message Access Protocol Internationalization", RFC 5255,
+              June 2008.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+
+
+
+
+
+Karp               IMAP4 Display-Based Address Sorting          [Page 4]
+
+RFC 5957                                                       July 2010
+
+
+   [SORT]     Crispin, M. and K. Murchison, "Internet Message Access
+              Protocol - SORT and THREAD Extensions", RFC 5256, June
+              2008.
+
+Author's Address
+
+   Dan Karp
+   Zimbra
+   3401 Hillview Avenue
+   Palo Alto, CA  94304
+   USA
+
+   EMail: dkarp@zimbra.com
+   URI:   http://www.zimbra.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Karp               IMAP4 Display-Based Address Sorting          [Page 5]
+