< draft-ietf-morg-inthread-00.txt		draft-ietf-morg-inthread-01.txt >
	Network Working Group Arnt Gulbrandsen		Network Working Group Arnt Gulbrandsen
	Internet-Draft Oryx Mail Systems GmbH		Internet-Draft July 8, 2010
	Intended Status: Proposed Standard January 28, 2009		Intended Status: Proposed Standard
	The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions		The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions
	draft-ietf-morg-inthread-00.txt		draft-ietf-morg-inthread-01.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This Internet-Draft is submitted to IETF in full conformance with
	the provisions of BCP 78 and BCP 79.		the provisions of BCP 78 and BCP 79.
	Copyright (c) 2009 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.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-		http://www.ietf.org/ietf/1id-abstracts.txt.
	Draft Shadow Directories can be accessed at
			The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft expires in July 2009.		This Internet-Draft expires in January 2011.
			Copyright Notice
	Internet-draft January 2009		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.
	Abstract		Abstract
	The SEARCH=INTHREAD extension extends the IMAP SEARCH command to		The SEARCH=INTHREAD extension extends the IMAP SEARCH command to
	operate on threads as well as individual messages. Other commands		operate on threads as well as individual messages. Other commands
	which search are implicitly extended.		which search are implicitly extended. This allows clients to perform
			searches such as "find all threads that mention schemata", rather
			than just "find all single messages that mention schemata".
	The THREAD=REFS extension provides a threading algorithm using		The THREAD=REFS extension provides a threading algorithm using
	(almost) only the References header field for use with the IMAP		(almost) only the References header field for use with the IMAP
	THREAD command.		THREAD command.
	1. Conventions Used in This Document		1. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	2. Overview		2. Overview
	This document defines two related extensions.		This document defines two related extensions.
	The THREAD=REFS extension defined a fairly pure References-based		The THREAD=REFS extension defined a fairly pure References-based
	(see [RFC5322] section 3.6.4) threading algorithm for use with the		(see [RFC5322] section 3.6.4) threading algorithm for use with the
	THREAD command (see [RFC5256]) and with SEARCH=INTHREAD.		THREAD command (see [RFC5256]) and with SEARCH=INTHREAD.
	An IMAP server (see [RFC3501]) that supports the THREAD=REFS		An IMAP server (see [RFC3501]) that supports the THREAD=REFS
	extension MUST announce THREAD=REFS as capabilities. This extension		extension MUST announce THREAD=REFS as capabilities. The THREAD=REFS
	adds no new commands and responses, only a new thread algorithm.		extension adds no new commands and responses, only a new thread
			algorithm.
	The SEARCH=INTHREAD extension extends the IMAP SEARCH command to		The SEARCH=INTHREAD extension extends the IMAP SEARCH command to
	operate on threads as well as individual messages. Other commands		operate on threads as well as individual messages. Other commands
	which search are implicitly extended. SEARCH=INTHREAD requires that		which search are implicitly extended. SEARCH=INTHREAD requires that
	servers implement THREAD=REFS too.		servers implement THREAD=REFS too.
	An IMAP server that supports SEARCH=INTHREAD MUST announce both		An IMAP server that supports SEARCH=INTHREAD announces both
	SEARCH=INTHREAD and THREAD=REFS as capabilities. This extension adds		SEARCH=INTHREAD and THREAD=REFS as capabilities. The SEARCH=INTHRAD
	no new commands and responses, but adds four new search-keys,		extension adds no new commands and responses, but adds two new
	INTHREAD, THREADROOT, THREADLEAF and MESSAGEID, and one search		search-keys, INTHREAD and MESSAGEID, and one search return option,
	return option, THREAD=REFS.		THREAD=REFS.
	Internet-draft January 2009
	3. New Search Keys		3. New Search Keys etc.
	This document defines three new search keys which operate on		This document defines a new search key which finds all messages in a
	threads: One to find all messages in a thread where at least one		thread where at least one message matches another (specified) search
	message matches another search key, one to find the roots of threads		key, and a helper which matches a message given its message-id.
	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		3.1. The INTHREAD Search Key
	INTHREAD takes one argument, which is another search key.		INTHREAD takes one argument, which is another search key.
	The INTHREAD search-key matches a message if its subsidiary search-		If the argument matches a message, then INTHREAD matches all the
	key matches at least one message in the same thread as the message.		message in the same thread as that message.
	This command finds all messages in an entire thread concerning the		This command finds all messages in an entire thread concerning the
	meetings where fizzle was discussed:		meetings where fizzle was discussed:
	C: a UID SEARCH INTHREAD (SUBJECT meeting BODY fizzle)		C: a UID SEARCH INTHREAD (SUBJECT meeting BODY fizzle)
	This command threads all threads containing at least one message		This command threads all threads containing at least one message
	from fred@example.com:		from fred@example.com:
	C: a UID THREAD REFS utf-8 INTHREAD FROM <fred@example.com>		C: a UID THREAD REFS utf-8 INTHREAD FROM <fred@example.com>
	3.2. The THREADROOT Search Key		3.2. The MESSAGEID Search Key
	The THREADROOT search key matches a message if that message does not
	have any extant parent according to the active threading algorithm
	(see section 3.5).
	This command finds the roots of all threads containing unread
	messages:
	C: a UID SEARCH THREADROOT INTHREAD UNSEEN
	3.3. The THREADLEAF Search Key
	The THREADLEAF search key matches a message if that message has no
	extant children in the same mailbox, according to the active
	threading algorithm.
	Note that THEADLEAF interacts badly with THREAD=ORDEREDSUBJECT.		The MESSAGEID search key takes a sigle argument, and matches a
	THREAD=ORDEREDSUBJECT is defined such that every message is either a		message if that message's message-id is the same as the argument.
	root or a leaf, there are no intermediate nodes.
	Internet-draft January 2009		This command finds all in the same thread as
			<432.123.321@example.com>:
	This command finds all messages that were (also) sent to me, and to		C: a UID SEARCH INTHREAD MESSAGEID
	which noone has answered:		"<4321.1234.321@example.com>"
	C: a UID SEARCH THREADLEAF OR TO <me@example.com> CC		Note that in the past, some message-ids contained needless quoting.
	<me@example.com>		Up to around 2001, a message might have the following Message-ID:
	3.4. The MESSAGEID Search Key		Message-ID: <"432.123.321"@example.com>
	The MESSAGEID search key takes a sigle argument, and matches a		A reply might remove the unnecessary quotes:
	message if that message's normalized nessage-id is the same as the
	argument.
	This command finds all in the same thread as		References: <432.123.321@example.com>
	<4321.1234321@example.com>:
	C: a UID SEARCH INTHREAD MESSAGEID <4321.1234321@example.com>		Although such message-id quoting ist still permitted, the author of
			this document has not found evidence of such quoting since 2001.
			This document does not make any recommendation about how to handle
			quoted left-hand-sides.
	3.5. The THREAD=* Search Return Option(s)		3.3. The THREAD=* Search Return Option(s)
	The THREAD=* search return options enables the client to select		The THREAD=* search return options enables the client to select
	which threading algorithm the server uses when processing INTHREAD,		which threading algorithm the server uses when processing INTHREAD
	THREADROOT and THREADLEAF as part of a SEARCH command. If THREAD=*		as part of a SEARCH command. If THREAD=* isn't specified, then the
	isn't specified, then the default for the SEARCH command is		default for the SEARCH command is THREAD=REFS.
	THREAD=REFS.
	When the server processes a THREAD command, it uses the algorithm		When the server processes a THREAD command, it uses the algorithm
	specified by the client.		specified by the client.
	This command sorts the messages by subject and returns the first		I can't think of a good example (or use case) for a non-default use
	message with each subject, disregarding "fwd", "re" and other		of this.
	paraphernalia:
	C: a UID SEARCH RETURN (THREAD=ORDEREDSUBJECT) THREADROOT
	4. The THREAD=REFS Thread Algorithm		4. The THREAD=REFS Thread Algorithm
	The THREAD=REFS thread algorithm is defined as the part of		The THREAD=REFS thread algorithm is defined as the part of
	THREAD=REFERENCES (see [RFC5256]) which concerns itself with the		THREAD=REFERENCES (see [RFC5256]) which concerns itself with the
	References, In-Reply-To and Message-ID fields. THREAD=REFS ignores		References, In-Reply-To and Message-ID fields. THREAD=REFS ignores
	Subject.		Subject.
	THREAD=REFS sorts threads by the most recent INTERNALDATE in each		THREAD=REFS sorts threads by the most recent INTERNALDATE in each
	thread, replacing THREAD=REFERENCES step (4). This means that when a		thread, replacing THREAD=REFERENCES step (4). This means that when a
	new message arrives, its thread becomes the latest thread. (Note		new message arrives, its thread becomes the latest thread. (Note
	that while threads are sorted by arrival date, messages within a		that while threads are sorted by arrival date, messages within a
	Internet-draft January 2009
	thread are sorted by sent date, just as for THREAD=REFERENCES.)		thread are sorted by sent date, just as for THREAD=REFERENCES.)
	This document defines THREAD=REFS because THREAD=REFERENCES is too		This document defines THREAD=REFS because THREAD=REFERENCES is too
	inclusive for the INTHREAD search key. For example, independent		inclusive for the INTHREAD search key. For example, independent
	threads that happen to have the same subject field (such as "Agenda		threads that happen to have the same subject field (such as "Agenda
	for Friday's meeting", "Web site updated" or "Message delivery		for Friday's meeting", "Web site updated" or "Message delivery
	failed") are grouped into one thread by THREAD=REFERENCES.		failed") are grouped into one thread by THREAD=REFERENCES.
	It is explicitly permitted for the server to persistently store		It is explicitly permitted for the server to persistently store
	threading information, even if this causes the server to return		threading information, even if this causes the server to return
	different information than it would otherwise. This can happen if		different information than it would otherwise. This can happen if
	the first messages in a thread are deleted, for example.		the first messages in a thread are deleted, for example.
	5. Formal Syntax		5. Formal Syntax
	The following syntax specification uses the Augmented Backus-Naur		The following syntax specification uses the Augmented Backus-Naur
	Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines		Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines
	the non-terminals "capability" and "search-key", [RFC4466] defines		the non-terminals "capability", "search-key" and "string", [RFC4466]
	"search-return-opt", [RFC5256] defines "thread-alg", and [RFC5322]		defines "search-return-opt", [RFC5256] defines "thread-alg".
	defines "id-left" and "id-right".
	Except as noted otherwise, all alphabetic characters are case-		Except as noted otherwise, all alphabetic characters are case-
	insensitive. The use of upper or lower case characters to define		insensitive. The use of upper or lower case characters to define
	token strings is for editorial clarity only. Implementations MUST		token strings is for editorial clarity only. Implementations MUST
	accept these strings in a case-insensitive fashion.		accept these strings in a case-insensitive fashion.
	capability =/ "SEARCH=INTHREAD" / "THREAD=REFS"		capability =/ "SEARCH=INTHREAD" / "THREAD=REFS"
	search-key =/ "INTHREAD" SP search-key / "MESSAGEID" SP "<"		search-key =/ "INTHREAD" SP search-key / "MESSAGEID" SP string
	id-left "@" id-right ">" / "THREADROOT" /
	"THREADLEAF"
	thread-alg =/ "REFS"		thread-alg =/ "REFS"
	search-return-opt =/ "THREAD=" thread-alg		search-return-opt =/ "THREAD=" thread-alg
	6. Security Considerations		6. Security Considerations
	This document is believed not to have any security implications.		This document is believed not to have any security implications.
	7. IANA Considerations		7. IANA Considerations
	The IANA is requested to add SEARCH=INTHREAD and THREAD=REFS to the		The IANA is requested to add SEARCH=INTHREAD and THREAD=REFS to the
	list of IMAP extensions,		list of IMAP extensions,
	http://www.iana.org/assignments/imap4-capabilities.		http://www.iana.org/assignments/imap4-capabilities.
	Internet-draft January 2009
	8. Acknowledgements		8. Acknowledgements
	The name THREAD=REFS was suggested by Cyrus Daboo. Dave Cridland,		The name THREAD=REFS was suggested by Cyrus Daboo. Dave Cridland,
	Alexey Menikov and particularly Timo Sirainen have helped with the		Alexey Menikov and particularly Timo Sirainen have helped with the
	document.		document.
	9. Normative References		9. Normative References
	[RFC2119] Bradner, "Key words for use in RFCs to Indicate		[RFC2119] Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, Harvard University, March		Requirement Levels", RFC 2119, Harvard University, March
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 18 ¶
	[RFC5256] Crispin, Murchison, "INTERNET MESSAGE ACCESS PROTOCOL -		[RFC5256] Crispin, Murchison, "INTERNET MESSAGE ACCESS PROTOCOL -
	SORT AND THREAD EXTENSIONS", RFC 5256, Panda Programming,		SORT AND THREAD EXTENSIONS", RFC 5256, Panda Programming,
	June 2008.		June 2008.
	[RFC5322] Resnick, "Internet Message Format", RFC 5322, Qualcomm,		[RFC5322] Resnick, "Internet Message Format", RFC 5322, Qualcomm,
	October 2008.		October 2008.
	10. Author's Address		10. Author's Address
	Arnt Gulbrandsen		Arnt Gulbrandsen
	Oryx Mail Systems GmbH
	Schweppermannstr. 8		Schweppermannstr. 8
	D-81671 Muenchen		D-81671 Muenchen
	Germany		Germany
	Fax: +49 89 4502 9758		Email: arnt@gulbrandsen.priv.no
			(RFC Editor: Please delete everything after this point)
	Email: arnt@oryx.com
	Internet-draft January 2009		11. Open Issues
	(RFC Editor: Please delete everything after this point)		I removed THREADROOT and THREADLEAF. Put them back in? I didn't
			actually implement them (it's now 14 months since I implemented
			INTHREAD), so I dropped them from the draft now, on the theory that
			the're insufficiently justified.
	Open Issues		I left the THREAD= search return option, but I haven't implemented
			it either. I don't see any use cases for anything other than the
			default. (At the moment there isn't an example, which is really
			another way of saying "no use cases".) I want to drop it.
	None.		It's not clear to me that the MESSAGEID search-key is worth the
			bother. HEADER Message-Id "<foo@bar>" searches for a substring and
			MESSAGEID "<foo@bar>" for a complete message-id. In a sample of a
			half-million recent messages, none of the message-ids contained
			embededded greater-than or less-than signs, so it's hard to imagine
			any practical effects of treating the two searches identically.
	Changes since -00		12. Changes since -00
	- The IANA asked me to specify the IANA registry exactly		- The IANA asked me to specify the IANA registry exactly
	- Boilerplate updates - IETF Trust and so on.		- Boilerplate updates - IETF Trust and so on.
	Changes since -01		Changes since -01
	- Added THREADROOT, THREADLEAF and MESSAGEID		- Added THREADROOT, THREADLEAF and MESSAGEID
	- Fixed the typo		- Fixed the typo
	skipping to change at page 8, line 5 ¶		skipping to change at page 9, line 14 ¶
	Changes since -03		Changes since -03
	- Boilerplate updates for 5377 and blah		- Boilerplate updates for 5377 and blah
	Changes since -03		Changes since -03
	- Sort threads by the most recent date in each thread, so that new		- Sort threads by the most recent date in each thread, so that new
	messages arriving makes a thread new again.		messages arriving makes a thread new again.
	Internet-draft January 2009
	Changes since d-g-i-i-04		Changes since d-g-i-i-04
	- Define "most recent thread" by arrival date, not sender date.		- Define "most recent thread" by arrival date, not sender date.
	Suits typical client use better. When reading a thread, you want		Suits typical client use better. When reading a thread, you want
	to read messages as ordered by the senders, but the most recent		to read messages as ordered by the senders, but the most recent
	thread should be the one which arrived in your mailbox most		thread should be the one which arrived in your mailbox most
	recently.		recently.
	- Rename to be a WG draft.		- Rename to be a WG draft.
			Changes since -00
			- I had a bit of an SCM disaster with my laptop, desktop and git. I
			hope I resolved it well. My apologies if dropped something.
			- Better wording for the INTHREAD search key
			- Message-id turned into an IMAP string.
			- Elaborated a little on message-id equality. The text leaves it up
			to the server whether it will normalize. (The last program to
			generate quotes in message-ids was, AFAICT, procmail/formail, and
			it quit around 2001. The changelog does not say why. I asked
			Philip and he can't remember either. Up to 2001 some respondents
			normalized procmail's message-ids and some (most?) didn't.)
			- Remove THREADROOT and THREADLEAF. Note my desire to remove THREAD=
			and perhaps MESSAGEID.
End of changes. 37 change blocks.
	98 lines changed or deleted		80 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/