rfc5957.IMAP4_SORT_extension.txt 8.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283
  1. Internet Engineering Task Force (IETF) D. Karp
  2. Request for Comments: 5957 Zimbra
  3. Updates: 5256 July 2010
  4. Category: Standards Track
  5. ISSN: 2070-1721
  6. Display-Based Address Sorting for the IMAP4 SORT Extension
  7. Abstract
  8. This document describes an IMAP protocol extension enabling server-
  9. side message sorting on the commonly displayed portion of the From
  10. and To header fields.
  11. Status of This Memo
  12. This is an Internet Standards Track document.
  13. This document is a product of the Internet Engineering Task Force
  14. (IETF). It represents the consensus of the IETF community. It has
  15. received public review and has been approved for publication by the
  16. Internet Engineering Steering Group (IESG). Further information on
  17. Internet Standards is available in Section 2 of RFC 5741.
  18. Information about the current status of this document, any errata,
  19. and how to provide feedback on it may be obtained at
  20. http://www.rfc-editor.org/info/rfc5957.
  21. Copyright Notice
  22. Copyright (c) 2010 IETF Trust and the persons identified as the
  23. document authors. All rights reserved.
  24. This document is subject to BCP 78 and the IETF Trust's Legal
  25. Provisions Relating to IETF Documents
  26. (http://trustee.ietf.org/license-info) in effect on the date of
  27. publication of this document. Please review these documents
  28. carefully, as they describe your rights and restrictions with respect
  29. to this document. Code Components extracted from this document must
  30. include Simplified BSD License text as described in Section 4.e of
  31. the Trust Legal Provisions and are provided without warranty as
  32. described in the Simplified BSD License.
  33. Karp IMAP4 Display-Based Address Sorting [Page 1]
  34. RFC 5957 July 2010
  35. Table of Contents
  36. 1. Introduction ....................................................2
  37. 2. Conventions Used in This Document ...............................2
  38. 3. DISPLAY Sort Value for an Address ...............................2
  39. 4. The DISPLAYFROM and DISPLAYTO Sort Criteria .....................3
  40. 5. Formal Syntax ...................................................3
  41. 6. Security Considerations .........................................3
  42. 7. Internationalization Considerations .............................4
  43. 8. IANA Considerations .............................................4
  44. 9. Normative References ............................................4
  45. 1. Introduction
  46. The [SORT] extension to the [IMAP] protocol provides a means for the
  47. server-based sorting of messages. It defines a set of sort criteria
  48. and the mechanism for determining the sort value of a message for
  49. each such ordering.
  50. The [SORT] FROM and TO orderings sort messages lexically on the
  51. [IMAP] addr-mailbox of the first address in the message's From and To
  52. headers, respectively. This document provides two alternative
  53. orderings, DISPLAYFROM and DISPLAYTO, which sort messages based on
  54. the first From or To address's [IMAP] addr-name (generally the same
  55. as its [RFC5322] display-name), when present.
  56. A server that supports the full [SORT] extension as well as both the
  57. DISPLAYFROM and DISPLAYTO sort criteria indicates this by returning
  58. "SORT=DISPLAY" in its CAPABILITY response.
  59. 2. Conventions Used in This Document
  60. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  61. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  62. document are to be interpreted as described in [RFC2119].
  63. 3. DISPLAY Sort Value for an Address
  64. For the purposes of the sort criteria defined in this document, the
  65. sort value for an [IMAP] address structure is defined as follows:
  66. o If the address structure's [IMAP] addr-name is non-NIL, apply the
  67. procedure from [RFC5255], Section 4.6. (That is, decode any
  68. [RFC2047] encoded-words and convert the resulting character string
  69. into a charset valid for the currently active [RFC4790] collation,
  70. with a default of UTF-8.) If the resulting octet string is not
  71. the empty string, use it as the sort value for the address.
  72. Karp IMAP4 Display-Based Address Sorting [Page 2]
  73. RFC 5957 July 2010
  74. o Otherwise, if the address structure's [IMAP] addr-mailbox and
  75. [IMAP] addr-host are both non-NIL, the sort value for the address
  76. is addr-mailbox@addr-host.
  77. o Otherwise, if the address structure's [IMAP] addr-mailbox is non-
  78. NIL, the sort value for the address is its addr-mailbox.
  79. o If none of the above conditions are met, the sort value for the
  80. address is the empty string.
  81. 4. The DISPLAYFROM and DISPLAYTO Sort Criteria
  82. This document introduces two new [SORT] sort criteria, DISPLAYFROM
  83. and DISPLAYTO. A message's sort value under these orderings MUST be
  84. derived as follows:
  85. A "derived-addr" value is created from the [IMAP] envelope structure
  86. resulting from a FETCH ENVELOPE on the message. For DISPLAYFROM, the
  87. derived-addr value is the [IMAP] env-from value. For DISPLAYTO, the
  88. derived-addr value is the [IMAP] env-to value.
  89. o If the derived-addr value is NIL, the message's sort value is the
  90. empty string.
  91. o Otherwise, the message's sort value is the DISPLAY sort value of
  92. the first [IMAP] address in the derived-addr value.
  93. 5. Formal Syntax
  94. The following syntax specification uses the Augmented Backus-Naur
  95. Form (ABNF) notation as specified in [RFC5234]. [IMAP] defines the
  96. non-terminal "capability", and [SORT] defines "sort-key".
  97. capability =/ "SORT=DISPLAY"
  98. sort-key =/ "DISPLAYFROM" / "DISPLAYTO"
  99. 6. Security Considerations
  100. This document defines an additional IMAP4 capability. As such, it
  101. does not change the underlying security considerations of [IMAP].
  102. The author believes that no new security issues are introduced with
  103. this additional IMAP4 capability.
  104. Karp IMAP4 Display-Based Address Sorting [Page 3]
  105. RFC 5957 July 2010
  106. 7. Internationalization Considerations
  107. DISPLAYFROM and DISPLAYTO are string-based sort criteria. As stated
  108. in [SORT], the active [RFC4790] collation as per [RFC5255] MUST be
  109. used when sorting such strings.
  110. The DISPLAYFROM and DISPLAYTO orderings sort on the full decoded
  111. [IMAP] addr-name, when present. They do not attempt to parse this
  112. string in a locale- or language-dependent manner in order to
  113. determine and sort on some semantically meaningful substring such as
  114. the surname.
  115. 8. IANA Considerations
  116. [IMAP] capabilities are registered by publishing a Standards Track or
  117. IESG-approved Experimental RFC. This document constitutes
  118. registration of the SORT=DISPLAY capability in the [IMAP]
  119. capabilities registry.
  120. 9. Normative References
  121. [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
  122. 4rev1", RFC 3501, March 2003.
  123. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
  124. Part Three: Message Header Extensions for Non-ASCII Text",
  125. RFC 2047, November 1996.
  126. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  127. Requirement Levels", BCP 14, RFC 2119, March 1997.
  128. [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
  129. Application Protocol Collation Registry", RFC 4790, March
  130. 2007.
  131. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
  132. Syntax Specifications: ABNF", STD 68, RFC 5234, January
  133. 2008.
  134. [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
  135. Message Access Protocol Internationalization", RFC 5255,
  136. June 2008.
  137. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
  138. October 2008.
  139. Karp IMAP4 Display-Based Address Sorting [Page 4]
  140. RFC 5957 July 2010
  141. [SORT] Crispin, M. and K. Murchison, "Internet Message Access
  142. Protocol - SORT and THREAD Extensions", RFC 5256, June
  143. 2008.
  144. Author's Address
  145. Dan Karp
  146. Zimbra
  147. 3401 Hillview Avenue
  148. Palo Alto, CA 94304
  149. USA
  150. EMail: dkarp@zimbra.com
  151. URI: http://www.zimbra.com
  152. Karp IMAP4 Display-Based Address Sorting [Page 5]