< draft-ietf-sieve-external-lists-09.txt		draft-ietf-sieve-external-lists-10.txt >
	Sieve Working Group A. Melnikov		Sieve Working Group A. Melnikov
	Internet-Draft Isode Limited		Internet-Draft Isode Limited
	Intended status: Standards Track B. Leiba		Intended status: Standards Track B. Leiba
	Expires: November 19, 2011 Huawei Technologies		Expires: December 11, 2011 Huawei Technologies
	May 18, 2011		June 9, 2011
	Sieve Extension: Externally Stored Lists		Sieve Extension: Externally Stored Lists
	draft-ietf-sieve-external-lists-09		draft-ietf-sieve-external-lists-10
	Abstract		Abstract
	The Sieve scripting language can be used to implement whitelisting,		The Sieve email filtering language can be used to implement email
	blacklisting, personal distribution lists, and other sorts of list		whitelisting, blacklisting, personal distribution lists, and other
	matching. Currently, this requires that all members of such lists be		sorts of list matching. Currently, this requires that all members of
	hardcoded in the script itself. Whenever a member of a list is added		such lists be hardcoded in the script itself. Whenever a member of a
	or deleted, the script needs to be updated and possibly uploaded to a		list is added or deleted, the script needs to be updated and possibly
	mail server.		uploaded to a mail server.
	This document defines a Sieve extension for accessing externally		This document defines a Sieve extension for accessing externally
	stored lists -- lists whose members are stored externally to the		stored lists -- lists whose members are stored externally to the
	script, such as using LDAP (RFC 4510), ACAP (RFC 2244), CardDAV (work		script, such as using LDAP (RFC 4510), ACAP (RFC 2244), CardDAV (work
	in progress), or relational databases.		in progress), or relational databases.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 19, 2011.		This Internet-Draft will expire on December 11, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	2.9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 10		2.9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 10
	2.9.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 11		2.9.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.9.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 11		2.9.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 11
	3. Security Considerations . . . . . . . . . . . . . . . . . 12		3. Security Considerations . . . . . . . . . . . . . . . . . 12
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . 14		4. IANA Considerations . . . . . . . . . . . . . . . . . . . 14
	4.1. Registration of Sieve Extension . . . . . . . . . . . . . 14		4.1. Registration of Sieve Extension . . . . . . . . . . . . . 14
	4.2. Registration of ManageSieve Capability . . . . . . . . . . 14		4.2. Registration of ManageSieve Capability . . . . . . . . . . 14
	4.3. Creation of Sieve URN Parameters registry . . . . . . . . 15		4.3. Creation of Sieve URN Parameters registry . . . . . . . . 15
	4.4. Registration of the "addrbook" URN parameter . . . . . . . 15		4.4. Registration of the "addrbook" URN parameter . . . . . . . 16
	4.5. Registration of "sieve" URN sub-namespace . . . . . . . . 16		4.5. Registration of "sieve" URN sub-namespace . . . . . . . . 16
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16
	6. References . . . . . . . . . . . . . . . . . . . . . . . . 16		6. References . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 16		6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	6.2. Informative References . . . . . . . . . . . . . . . . . . 17		6.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	list whose members are stored externally to the Sieve script, such as		list whose members are stored externally to the Sieve script, such as
	using LDAP [RFC4510], ACAP [RFC2244], CardDAV		using LDAP [RFC4510], ACAP [RFC2244], CardDAV
	[I-D.ietf-vcarddav-carddav], or relational databases.		[I-D.ietf-vcarddav-carddav], or relational databases.
	This extension adds a new match type to apply to supported tests, and		This extension adds a new match type to apply to supported tests, and
	a new tagged argument to the "redirect" action.		a new tagged argument to the "redirect" action.
	1.1. Conventions Used In This Document		1.1. Conventions Used In This Document
	Conventions for notations are as in [RFC5228] section 1.1, including		Conventions for notations are as in [RFC5228] section 1.1, including
	the use of [RFC5234].		the use of ABNF [RFC5234].
	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].
	2. Extlists Extension		2. Extlists Extension
	2.1. Capability Identifier		2.1. Capability Identifier
	The capability string associated with the extension defined in this		The capability string associated with the extension defined in this
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	Queries done through list-specific mechanisms might have the effect		Queries done through list-specific mechanisms might have the effect
	of built-in comparators; for example, queries to certain lists might		of built-in comparators; for example, queries to certain lists might
	be case-sensitive, while queries to other lists might be done without		be case-sensitive, while queries to other lists might be done without
	regard to case.		regard to case.
	Implementations MUST support the use of ":list" in "address",		Implementations MUST support the use of ":list" in "address",
	"envelope" and "header" tests. Implementations that include the		"envelope" and "header" tests. Implementations that include the
	Variables extension [RFC5229] MUST also support its use in "string"		Variables extension [RFC5229] MUST also support its use in "string"
	tests.		tests.
	Implementations MAY support other tests but MUST raise an error		Implementations MAY support other tests than the ones in this
	(which SHOULD be a compile-time error, but MAY be a runtime error)		document. Implementations MUST report an error when a script uses
	when a script uses ":list" with a test for which it is not supported.		":list" with a test that does not support ":list". This error SHOULD
	To maintain interoperability, other tests that can be used with		be reported at compile-time, but MAY be reported at run-time. To
	":list" SHOULD be documented in a specification that defines a		maintain interoperability, other tests that can be used with ":list"
	capability string that can be tested (in a "require" statement, or		SHOULD be documented in a specification that defines a capability
	using ihave [RFC5463]).		string that can be tested (in a "require" statement or using ihave
			[RFC5463]).
	For example, testing 'header ["to", "cc"]' against a list would cause		For example, testing 'header ["to", "cc"]' against a list would cause
	each "to" and "cc" value, ignoring leading and trailing whitespace,		each "to" and "cc" value, ignoring leading and trailing whitespace,
	to be queried. If any value is found to belong to the list, the test		to be queried. If any value is found to belong to the list, the test
	returns "true". If no value belongs to the list, the test returns		returns "true". If no value belongs to the list, the test returns
	"false". Once a value is found in the list, there is no need for the		"false". Once a value is found in the list, there is no need for the
	query mechanism to look further.		query mechanism to look further.
	For some lists, the Sieve engine might directly retrieve the list and		For some lists, the Sieve engine might directly retrieve the list and
	make its own comparison. Other lists might not work that way -- they		make its own comparison. Other lists might not work that way -- they
	skipping to change at page 15, line 16 ¶		skipping to change at page 15, line 16 ¶
	Author/Change controller: IESG		Author/Change controller: IESG
	4.3. Creation of Sieve URN Parameters registry		4.3. Creation of Sieve URN Parameters registry
	The following requests IANA to create a new registry under "Sieve		The following requests IANA to create a new registry under "Sieve
	Extensions" for Sieve URN Parameters. Registration into this		Extensions" for Sieve URN Parameters. Registration into this
	registry is according to the "Specification Required" policy		registry is according to the "Specification Required" policy
	[RFC5226].		[RFC5226].
			The registry will contain the following two items:
	URN parameter name: The name of the URN parameter. If the name is		URN parameter name: The name of the URN parameter. If the name is
	"paramname", the resulting top-level URN will be		"paramname", the resulting top-level URN will be
	"urn:ietf:params:sieve:paramname".		"urn:ietf:params:sieve:paramname".
	Reference: The document and section where the definition of the		Reference: The document and section where the definition of the
	parameter can be found. The documentation MUST include the		parameter can be found. Be sure to include the section number as
	following information (see Section 2.6 for an example):		well as the document reference, so the documentation is easy to
			find.
	URN parameter name: The name of the URN parameter.		The documentation -- which will be in the referenced document and
			section, and will not be included in the registry -- MUST include the
			following information (see Section 2.6 for an example):
	URN parameter syntax: The syntax of the parameter and any sub-		URN parameter name: The name of the URN parameter.
	parameters, which SHOULD be specified using ABNF [RFC5234].
	Intended usage: A detailed description of how the parameter and		URN parameter syntax: The syntax of the parameter and any sub-
	any sub-parameters are expected to be used. This is the		parameters, which SHOULD be specified using ABNF [RFC5234].
	place to define static sub-parameters, registries for sub-
	parameters, options, registries for options, and so on.
	Interoperability considerations: Any notes specific to		Intended usage: A detailed description of how the parameter and
	interoperability issues. This is where to put mandatory-to-		any sub-parameters are expected to be used. This is the place
	implement sub-parameters and the like.		to define static sub-parameters, registries for sub-
			parameters, options, registries for options, and so on.
	Security considerations: Any notes specific to security and		Interoperability considerations: Any notes specific to
	privacy issues.		interoperability issues. This is where to put mandatory-to-
			implement sub-parameters and the like.
	Contact: Contact information, in case there are questions.		Security considerations: Any notes specific to security and
			privacy issues.
			Contact: Contact information, in case there are questions.
	4.4. Registration of the "addrbook" URN parameter		4.4. Registration of the "addrbook" URN parameter
	The following requests IANA to register a new Sieve URN parameter in		The following requests IANA to register a new Sieve URN parameter in
	the registry defined in Section 4.3.		the registry defined in Section 4.3.
	URN parameter name: addrbook		URN parameter name: addrbook
	Reference: [[this RFC]], Section 2.6		Reference: [[this RFC]], Section 2.6
End of changes. 15 change blocks.
	34 lines changed or deleted		42 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/