Network Working Group Arnt Gulbrandsen Internet-Draft Oryx Mail Systems GmbH Intended Status: Proposed Standard May 9, 2008 The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions draft-gulbrandsen-imap-inthread-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft expires in November 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The SEARCH=INTHREAD extension extends the IMAP SEARCH command to operate on threads as well as individual messages. Other commands which search are implicitly extended. The THREAD=REFS extension provides a threading algorithm using only the References header field for use with the IMAP THREAD command. Gulbrandsen Expires November 2008 [Page 1] Internet-draft May 2008 1. 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]. Formal syntax is defined by [RFC5234]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. The five characters [...] means that something has been elided. 2. Overview An IMAP server (see [RFC3501]) that supports this extension MUST announce SEARCH=INTHREAD as one of its capabilities. It MUST also support the THREAD extension. This extension adds no new commands and responses. It adds one new search-key, INTHREAD. 3. New Search Keys This document defines three new search keys which operate on threads: One to find all messages in a thread where at least one message matches another search key, one to find the roots of threads and one to find the leaves. It also defines a helper which matches a message given its message-id. 3.1. The INTHREAD Search Key INTHREAD takes two arguments, a threading algorithm (as defined in [SORT]) and another search key. The INTHREAD search-key matches a message if its subsidiary search- key matches at least one message in the same thread as the message. This command finds all messages in an entire thread concerning the meetings where fizzle was discussed: C: a UID SEARCH INTHREAD REFS (SUBJECT meeting BODY fizzle) This command threads all threads containing at least one message from fred@example.com: Gulbrandsen Expires November 2008 [Page 2] Internet-draft May 2008 C: a UID THREAD REFS utf-8 INTHREAD REFS FROM 3.2. The THREADROOT Search Key The THREADROOT search key matches a message if that message starts a thread. For each thread in the message, including single-message threads, there must be exactly one message which starts it. THREADROOT takes no arguments. Open issue: I am somewhat uncertain of the precise definition of this. 3.3. The THREADLEAF Search Key The THREADLEAF search key matches a message if the mailbox does not contain any replies to that message. It takes no arguments. Open issue: I am somewhat uncertain of the precise definition of this. 3.4. The MESSAGEID Search Key The MESSAGEID search key takes a sigle argument, and matches a message if that message's normalized nessage-id is exactly the same as the argument. 4. The THREAD=REFS Thread Algorithm The THREAD=REFS thread algorithm is defined as the part of THREAD=REFERENCES (see [SORT]) which concerns itself with the References and Message-ID header fields. THREAD=REFS ignores Date, In-Reply-To and Subject. This document defines THREAD=REFS because THREAD=REFERENCES is too inclusive for this purpose. For example, independent threads that happen to have use same subject field (such as "Agenda for Friday's meeting" or "Web site updated") are grouped into one thread by THREAD=REFERENCES. It is explicitly permitted for the server to persistently store threading information, even if this causes the server to return different information than it would otherwise. This can happen if Gulbrandsen Expires November 2008 [Page 3] Internet-draft May 2008 the first messages in a thread are deleted, for example. Open issue: Should THREAD=REFS use In-Reply-To if there is no References? 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability" and "search-key", [SORT] defines "thread-alg", and [RFC2822] defines "id-left" and "id-right". Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "SEARCH=INTHREAD" / "THREAD=REFS" search-key =/ "INTHREAD" SP thread-alg SP search-key / "MESSAGEID" SP "<" id-left "@" id-right ">" / "THREADROOT" / "THREADLEAF" 6. Security Considerations This document is believed not to have any security implications. 7. IANA Considerations The IANA is requested to add SEARCH=INTHREAD and THREAD=REFS to the list of IMAP extensions, http://www.iana.org/assignments/imap4-capabilities. 8. Acknowledgements The name THREAD=REFS was suggested by Cyrus Daboo. Dave Cridland helped with the search keys. Dave, Alexey Menikov and Timo Sirainen reviewed the document. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March Gulbrandsen Expires November 2008 [Page 4] Internet-draft May 2008 1997. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, Qualcomm Incorporated, April 2001. [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [SORT] Crispin, M., and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS", draft-ietf- imapext-sort-20.txt (work in progress) 10. Author's Address Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany Fax: +49 89 4502 9758 Email: arnt@oryx.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any Gulbrandsen Expires November 2008 [Page 5] Internet-draft May 2008 copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gulbrandsen Expires November 2008 [Page 6] Internet-draft May 2008 (RFC Editor: Please delete everything after this point) Open Issues None. Changes since -00 - The IANA asked me to specify the IANA registry exactly - Boilerplate updates - IETF Trust and so on. Changes since -01 - Added THREADROOT, THREADLEAF and MESSAGEID - Fixed the typo Gulbrandsen Expires November 2008 [Page 7]