< draft-tschofenig-sipping-spit-policy-01.txt		draft-tschofenig-sipping-spit-policy-02.txt >
	SIPPING H. Tschofenig		SIPPING H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Standards Track D. Wing		Intended status: Standards Track D. Wing
	Expires: January 9, 2008 Cisco		Expires: May 22, 2008 Cisco
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	T. Froment		T. Froment
	Alcatel-Lucent		Alcatel-Lucent
	G. Dawirs		G. Dawirs
	University of Namur		University of Namur
	July 8, 2007		November 19, 2007
	A Document Format for Expressing Authorization Policies to tackle Spam		A Document Format for Expressing Authorization Policies to tackle Spam
	and Unwanted Communication for Internet Telephony		and Unwanted Communication for Internet Telephony
	draft-tschofenig-sipping-spit-policy-01.txt		draft-tschofenig-sipping-spit-policy-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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."
	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.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-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 will expire on January 9, 2008.		This Internet-Draft will expire on May 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	SPAM, defined as sending unsolicited messages to someone in bulk,		SPAM, defined as sending unsolicited messages to someone in bulk,
	might be a problem on SIP open-wide deployed networks. The		might be a problem on SIP open-wide deployed networks. The
	responsibility for filtering or blocking calls can belong to		responsibility for filtering or blocking calls can belong to
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5		3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Structure of SPIT Authorization Documents . . . . . . . . 5		3.1. Structure of SPIT Authorization Documents . . . . . . . . 5
	3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5
	4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 6		4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1.1. Acceptable Forms of Authentication . . . . . . . . . . 6		4.1.1. Acceptable Forms of Authentication . . . . . . . . . . 6
	4.1.2. Computing a URI for the Sender . . . . . . . . . . . . 7		4.1.2. Computing a URI for the Sender . . . . . . . . . . . . 7
	4.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. SPIT Handling . . . . . . . . . . . . . . . . . . . . . . 9		4.3. SPIT Handling . . . . . . . . . . . . . . . . . . . . . . 9
	4.4. Media List . . . . . . . . . . . . . . . . . . . . . . . . 9		4.4. Presence Status . . . . . . . . . . . . . . . . . . . . . 9
	4.5. Method List . . . . . . . . . . . . . . . . . . . . . . . 10		4.5. Time Period Condition . . . . . . . . . . . . . . . . . . 9
	4.6. MIME List . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.7. Presence Status . . . . . . . . . . . . . . . . . . . . . 10		5.1. Execute Action . . . . . . . . . . . . . . . . . . . . . . 11
	4.8. Rule Deactivated . . . . . . . . . . . . . . . . . . . . . 10		5.2. Forward To . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.9. Time Period Condition . . . . . . . . . . . . . . . . . . 10		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		6.1. Identity and Time-Based Policy . . . . . . . . . . . . . . 12
	5.1. Execute Action . . . . . . . . . . . . . . . . . . . . . . 18		6.2. Extended Time-Based Policy . . . . . . . . . . . . . . . . 13
	5.2. Forward To . . . . . . . . . . . . . . . . . . . . . . . . 18		6.3. Policy for triggering Captcha and Hashcash Challenges . . 14
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20		8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 27		8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 19
	8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 27		8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 27		8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 20
	8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 27		8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 20
	8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 27		8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 20
	8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 27		8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 20
	8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 27		8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 20
	8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 28		8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 20
	8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 28		8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 20
	8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 28		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 21
	9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 28		9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 21
	9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 28		9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 21
	9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 29		10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 29		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30		13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 30		13.2. Informative References . . . . . . . . . . . . . . . . . . 24
	13.2. Informative References . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34		Intellectual Property and Copyright Statements . . . . . . . . . . 28
	Intellectual Property and Copyright Statements . . . . . . . . . . 36
	1. Introduction		1. Introduction
	The problem of SPAM for Internet Telephony (SPIT) is an imminent		The problem of SPAM for Internet Telephony (SPIT) is an imminent
	challenge and only the combination of several techniques can provide		challenge and only the combination of several techniques can provide
	a framework for dealing with unwanted communication, as stated in		a framework for dealing with unwanted communication, as stated in
	[I-D.jennings-sip-hashcash].		[I-D.jennings-sip-hashcash].
	One important building block is to have a mechanism that can instruct		One important building block is to have a mechanism that can instruct
	SIP intermediaries to react differently on incoming requests based on		SIP intermediaries to react differently on incoming requests based on
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 28 ¶
	element provides such a condition capability.		element provides such a condition capability.
	The <spit-handling> condition evaluates to TRUE if any of its child		The <spit-handling> condition evaluates to TRUE if any of its child
	elements evaluate to TRUE, i.e., the results of the individual child		elements evaluate to TRUE, i.e., the results of the individual child
	element are combined using a logical OR.		element are combined using a logical OR.
	The <spit-handling> element MAY contain zero or more <challenge>		The <spit-handling> element MAY contain zero or more <challenge>
	elements. The <challenge> elements has an attribute 'result' that		elements. The <challenge> elements has an attribute 'result' that
	either contains "SUCCESS" or "FAILURE".		either contains "SUCCESS" or "FAILURE".
	4.4. Media List		4.4. Presence Status
	The <media-list> condition evaluates to TRUE if any of its child
	elements evaluate to TRUE, i.e., the results of the individual child
	element are combined using a logical OR.
	The <media-list> element SHOULD include either
	o an <all-media-except> element or;
	o a list of one or more >media> elements selected from the list of
	possible media elements below.
	List of possible media elements:
	o The <message-session> media element indicating session based
	messaging as defined in [I-D.ietf-simple-message-sessions];
	o The <pager-mode-message> media element indicating pager mode
	message requests as defined in [RFC3428];
	o The <file-transfer> media element indicating file transfer as
	defined in [I-D.ietf-mmusic-file-transfer-mech];
	o The <audio> media element indicating a streaming media type as
	defined in [RFC3840];
	o The <video> media element indicating a streaming media type as
	defined in [RFC3840];
	o Any elements from any other namespaces defining a media element.
	The <all-media-except> element MAY include a list of one or more
	>media> elements selected from the list of possible >media> elements
	above.
	The <audio>, <video> and <message-session> elements:
	o MAY include the <full-duplex> element indicating that media can be
	exchanged in both directions simultaneously;
	o MAY include the <half-duplex> element indicating that media can be
	exchanged in only one direction at a time.
	4.5. Method List
	The <method-list> element contains one or more child elements
	<method> in order to provide matching capabilities of any SIP method
	invoked by the user can be used to filter incoming messages.
	The <method-list> condition element evaluates to TRUE if any of its
	child elements evaluate to TRUE, i.e., the results of the individual
	child element are combined using a logical OR.
	4.6. MIME List
	The <mime-list> element contains one or more child <mime> child
	elements
	The <mime-list> condition element evaluates to TRUE if any of its
	child elements evaluate to TRUE, i.e., the results of the individual
	child element are combined using a logical OR.
	4.7. Presence Status
	This condition evaluates to TRUE when the called user's current		This condition evaluates to TRUE when the called user's current
	presence activity status is equal to the value in the <presence-		presence activity status is equal to the value in the <presence-
	status> element. Otherwise the condition evaluates to FALSE.		status> element. Otherwise the condition evaluates to FALSE.
	4.8. Rule Deactivated		4.5. Time Period Condition
	The <rule-deactivated> condition always evaluates to FALSE. This can
	be used to deactivate a rule, without loosing information. By
	removing this condition the rule can be activated again.
	4.9. Time Period Condition
	The <time-period> element allows to make decisions based on the time,		The <time-period> element allows to make decisions based on the time,
	date and timezone. The <time> element may contain the following		date and timezone. It defines an extended version of the <validity>
	attributes:		element.
	tzid:
	RFC 2445 [RFC2445] Time Zone Identifier
	tzurl:
	RFC 2445 [RFC2445] Time Zone URL		The <time-period> element may contain the following attributes:
	dtstart:		dtstart:
	Start of interval (RFC 2445 [RFC2445] DATE-TIME)		Start of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute
			is MANDATORY.
	dtend:		dtend:
	End of interval (RFC 2445 [RFC2445] DATE-TIME)		End of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute is
			MANDATORY.
	duration:
	Length of interval (RFC 2445 [RFC2445] DURATION)
	freq:
	Frequency of recurrence ("secondly", "minutely", "hourly",
	"daily", "weekly", "monthly", or "yearly")
	interval:
	How often the recurrence repeats
	until:
	Bound of recurrence (RFC 2445 [RFC2445] DATE-TIME)
	count:
	Number of occurrences of recurrence
	bysecond:
	List of seconds within a minute
	byminute:
	List of minutes within an hour
	byhour:
	List of hours of the day
	byday: List of days of the week
	bymonthday:
	List of days of the month
	byyearday:
	List of days of the year
	byweekno:
	List of weeks of the year
	bymonth:
	List of months of the year
	wkstv:
	First day of the work week
	bysetpos:
	List of values within set of events specified
	The <time-period> is based on the description in CPL [RFC3880] and
	furthemore based closely on the specification of recurring intervals
	of time in the Internet Calendaring and Scheduling Core Object
	Specification (iCalendar COS), RFC 2445 [RFC2445].
	This allows policies to be generated automatically from calendar
	books. It also allows us to re-use the extensive existing work
	specifying time intervals.
	If future standards-track documents are published that update or
	obsolete RFC 2445 [RFC2445], any changes or clarifications those
	documents make to recurrence handling apply to CPL time-switches as
	well.
	An algorithm to determine whether an instant falls within a given
	recurrence is given in Appendix A of RFC 3880 [RFC3880].
	The <time-period> element takes two optional attributes, "tzid" and
	"tzurl", both of which are defined in Sections 4.8.3.1 and 4.8.3.5 of
	RFC 2445 [RFC2445]. The "tzid" is the identifying attribute by which
	a time zone definition is referenced. If it begins with a forward
	slash (solidus), it references a to-be-defined global time zone
	registry; otherwise it is locally-defined at the server. The "tzurl"
	attribute gives a network location from which an up-to-date VTIMEZONE
	definition for the timezone can be retrieved.
	While the content of the "tzid" attribute does not begin with a
	forward slash are locally defined, it is RECOMMENDED that servers
	support at least the naming scheme used by the Olson Time Zone
	database [OTZ]. Examples of timezone databases that use the Olson
	scheme are the zoneinfo files on most Unix-like systems, and the
	standard Java TimeZone class.
	Servers SHOULD resolve "tzid" and "tzurl" references to time zone		timestart:
	definitions at the time the policy is uploaded. They MAY
	periodically refresh these resolutions to obtain the most up-to-date
	definition of a time zone. If a "tzurl" becomes invalid, servers
	SHOULD remember the most recent valid data retrieved from the URL.
	If a script is uploaded with a "tzid" and "tzurl" which the CPL		Start of time interval in a particular day. It is of the TIME
	server does not recognize or cannot resolve, it SHOULD diagnose and		data type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445].
	reject this at script upload time. If neither "tzid" nor "tzurl" are		This attribute is OPTIONAL. The default value is 000000.
	present, all non-UTC times within this time switch should be
	interpreted as being "floating" times, i.e., that they are specified
	in the local timezone of the CPL server.
	Because of daylight-savings-time changes over the course of a		timeend:
	year, it is necessary to specify time switches in a given
	timezone. UTC offsets are not sufficient, or a time-of-day
	routing rule which held between 9 am and 5 pm in the eastern
	United States would start holding between 8 am and 4 pm at the end
	of October.
	The developers of tools used creating policy documents should be		End of time interval in a particular day. It is of the TIME data
	careful to handle correctly the intervals when local time is		type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445]. This
	discontinuous, at the beginning or end of daylight-savings time.		attribute is OPTIONAL. The default value is 235959.
	Note especially that some times may occur more than once when clocks
	are set back. The algorithm in Appendix A of RFC 3880 [RFC3880] is
	believed to handle this correctly.
	The <time> element specifies a list of periods. They have two		byweekday: List of days of the week. This attribute is OPTIONAL.
	required attributes a:
	o "dtstart", which specifies the beginning of the first period of
	the list,
	o and exactly one of "dtend" or "duration", which specify the ending		The <time-period> is based on the description in CPL [RFC3880] but
	time or the duration of the period, respectively.		with a reduced feature set.
	The "dtstart" and "dtend" attributes are formatted as iCalendar COS		The "dtstart" and "dtend" attributes are formatted as iCalendar COS
	DATE-TIME values, as specified in Section 4.3.5 of RFC 2445		DATE-TIME values, as specified in Section 4.3.5 of RFC 2445
	[RFC2445]. Only floating or UTC times can be used with time zones.		[RFC2445]. Only floating or UTC times can be used with time zones.
	The "duration" attribute is given as an iCalendar COS DURATION		The DATE-TIME is a subset of the corresponding syntaxes from ISO 8601
	parameter, as specified in section 4.3.6 of RFC 2445 [RFC2445]. Both		[ISO8601].
	the DATE-TIME and the DURATION syntaxes are subsets of the
	corresponding syntaxes from ISO 8601 [ISO8601].
	For a recurring interval, the "duration" attribute MUST be small
	enough such that subsequent intervals do not overlap. For non-
	recurring intervals, durations of any positive length are permitted.
	Zero-length and negative-length durations are not allowed.
	If no other parameters are specified, a <time> element indicates only
	a single period of time. More complicated sets of period intervals
	are constructed as recurrences. A recurrence is specified by
	including the "freq" attribute, which indicates the type of
	recurrence rule. Parameters other than "dtstart", "dtend", and
	"duration" SHOULD NOT be specified unless "freq" is present, though
	servers SHOULD accept rules with such parameters present, and ignore
	the other parameters.
	The "freq" parameter takes one of the following values: "secondly",
	to specify repeating periods based on an interval of a second or
	more, "minutely", to specify repeating periods based on an interval
	of a minute or more, "hourly", to specify repeating periods based on
	an interval of an hour or more, "daily", to specify repeating periods
	based on an interval of a day or more, "weekly", to specify repeating
	periods based on an interval of a week or more, "monthly", to specify
	repeating periods based on an interval of a month or more, and
	"yearly", to specify repeating periods based on an interval of a year
	or more. These values are not case-sensitive.
	The "interval" attribute contains a positive integer representing how
	often the recurrence rule repeats. The default value is "1", meaning
	every second for a "secondly" rule, every minute for a "minutely"
	rule, every hour for an "hourly" rule, every day for a "daily" rule,
	every week for a "weekly" rule, every month for a "monthly" rule, and
	every year for a "yearly" rule.
	The "until" attribute defines an iCalendar COS DATE or DATE-TIME
	value which bounds the recurrence rule in an inclusive manner. If
	the value specified by "until" is synchronized with the specified
	recurrence, this date or date-time becomes the last instance of the
	recurrence. If specified as a date-time value, then it MUST be
	specified in UTC time format. If not present, and the "count"
	parameter is not also present, the recurrence is considered to repeat
	forever.
	The "count" attribute defines the number of occurrences at which to
	range-bound the recurrence. The "dtstart" attribute counts as the
	first occurrence. The "until" and "count" attribute MUST NOT occur
	in the same <time> element.
	The "bysecond" attribute specifies a comma-separated list of seconds
	within a minute. Valid values are 0 to 59. The "byminute" attribute
	specifies a comma-separated list of minutes within an hour. Valid
	values are 0 to 59. The "byhour" attribute specifies a comma-
	separated list of hours of the day. Valid values are 0 to 23.
	The "byday" attribute specifies a comma-separated list of days of the
	week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" indicates
	Wednesday, "TH" indicates Thursday, "FR" indicates Friday, "SA"
	indicates Saturday, and "SU" indicates Sunday. These values are not
	case-sensitive.
	Each "byday" value can also be preceded by a positive (+n) or
	negative (-n) integer. If present, this indicates the nth occurrence
	of the specific day within the "monthly" or "yearly" recurrence. For
	example, within a "monthly" rule, +1MO (or simply 1MO) represents the
	first Monday within the month, whereas -1MO represents the last
	Monday of the month. If an integer modifier is not present, it means
	all days of this type within the specified frequency. For example,
	within a "monthly" rule, MO represents all Mondays within the month.
	The "bymonthday" attribute specifies a comma-separated list of days
	of the month. Valid values are 1 to 31 or -31 to -1. For example,
	-10 represents the tenth to the last day of the month.
	The "byyearday" attribute specifies a comma-separated list of days of
	the year. Valid values are 1 to 366 or -366 to -1. For example, -1
	represents the last day of the year (December 31st) and -306
	represents the 306th to the last day of the year (March 1st).
	The "byweekno" attribute specifies a comma-separated list of ordinals
	specifying weeks of the year. Valid values are 1 to 53 or -53 to -1.
	This corresponds to weeks according to week numbering as defined in
	ISO 8601 [ISO8601]. A week is defined as a seven day period,
	starting on the day of the week defined to be the week start (see
	"wkst"). Week number one of the calendar year is the first week
	which contains at least four (4) days in that calendar year. This
	parameter is only valid for "yearly" rules. For example, 3
	represents the third week of the year.
	Note: Assuming a Monday week start, week 53 can only occur when
	January 1 is a Thursday or, for leap years, if January 1 is a
	Wednesday.
	The "bymonth" attribute specifies a comma-separated list of months of
	the year. Valid values are 1 to 12.
	The "wkst" attribute specifies the day on which the work week starts.
	Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". This
	is significant when a "weekly" recurrence has an interval greater
	than 1, and a "byday" parameter is specified. This is also
	significant in a "yearly" recurrence when a "byweekno" parameter is
	specified. The default value is "MO", following ISO 8601 [ISO8601].
	The "bysetpos" attribute specifies a comma-separated list of values
	which corresponds to the nth occurrence within the set of events
	specified by the rule. Valid values are 1 to 366 or -366 to -1. It
	MUST only be used in conjunction with another byxxx attribute. For
	example, "the last work day of the month" could be represented as:
	<time dtstart="19970105T083000"
	freq="monthly"
	byday="MO,TU,WE,TH,FR"
	bysetpos="-1"
	/>
	Each "bysetpos" value can include a positive (+n) or negative (-n)
	integer. If present, this indicates the nth occurrence of the
	specific occurrence within the set of events specified by the rule.
	If byxxx attribute values are found which are beyond the available
	scope (i.e., bymonthday="30" in February), they are simply ignored.
	Byxxx attribute modify the recurrence in some manner. Byxxx rule		The "timestart" specifes a time value to indicate the beginning of
	parts for a period of time which is the same or greater than the		every day. The default value is 000000 representing the beginning of
	frequency generally reduce or limit the number of occurrences of the		the day.
	recurrence generated. For example, freq="daily" bymonth="1" reduces
	the number of recurrence instances from all days (if the "bymonth"
	attribute is not present) to all days in January. Byxxx attribute
	for a period of time less than the frequency generally increase or
	expand the number of occurrences of the recurrence. For example,
	freq="yearly" bymonth="1,2" increases the number of days within the
	yearly recurrence set from 1 (if "bymonth" parameter is not present)
	to 2.
	If multiple Byxxx attribute are specified, then after evaluating the		The "timeend" specifes a time value to indicate the end of every day.
	specified "freq" and "interval" attribute, the Byxxx attribute are		The default value is 235959 representing the end of the day.
	applied to the current set of evaluated occurrences in the following
	order: "bymonth", "byweekno", "byyearday", "bymonthday", "byday",
	"byhour", "byminute", "bysecond", and "bysetpos"; then "count" and
	"until" are evaluated.
	Here is an example of evaluating multiple Byxxx attribute.		The "byweekday" attribute specifies a comma-separated list of days of
			the week. "MO" indicates Monday, "TU" indicates Tuesday, "WE"
			indicates Wednesday, "TH" indicates Thursday, "FR" indicates Friday,
			"SA" indicates Saturday, and "SU" indicates Sunday. These values are
			not case-sensitive.
	<time dtstart="19970105T083000"		Here is an example of the time-period element.
	duration="10M"
	freq="yearly"
	interval="2"
	bymonth="1"
	byday="SU"
	byhour="8,9"
	byminute="30">
	/>
	First, the interval="2" would be applied to freq="yearly" to arrive		<time dtstart="20070112T083000"
	at "every other year." Then, bymonth="1" would be applied to arrive		timestart="0800"
	at "every January, every other year." Then, byday="SU" would be		timeend="1800"
	applied to arrive at "every Sunday in January, every other year."		byweekday="MO,TU,WE,TH,FR"
	Then, byhour="8,9" would be applied to arrive at "every Sunday in		dtend="20080101T183000"/>
	January at 8 AM and 9 AM, every other year." Then, byminute="30"
	would be applied to arrive at "every Sunday in January at 8:30 AM and
	9:30 AM, every other year." Then the second is derived from
	"dtstart" to end up in "every Sunday in January from 8:30:00 AM to
	8:40:00 AM, and from and 9:30:00 AM to 9:40:00 AM, every other year."
	Similarly, if the "byminute", "byhour", "byday", "bymonthday", or
	"bymonth" parameter were missing, the appropriate minute, hour, day,
	or month would have been retrieved from the "dtstart" parameter.
	The iCalendar COS RDATE, EXRULE, and EXDATE recurrence rules are not		The following aspects need to be considered:
	specifically mapped to components of the <time-period> element.
	Equivalent functionality to the exception rules can be attained by
	using the ordering of rules to exclude times using earlier rules.
	Section 4.4.1 of [RFC3880] provides some background of the		1) By default, if all the OPTIONAL parameters are missing, <time-
	differences to iCalendar and implementation issues.		period> element is valid for the whole duration from 'dtstart' to
			'dtend'.
			2) The 'byweekday' attribute comes into effect only if the period
			from 'dtstart' till 'dtstart' is long enough to accommodate the
			specified values, else they are just neglected.
			3) If the values of the 'byweekday' attribute values do not
			correspond to the expected domain, they are simply ignored.
			4) Only a single 'byweekday' attribute MUST be listed in a <time>
			element.
	5. Actions		5. Actions
	As stated in [RFC4474], conditions are the 'if'-part of rules,		As stated in [RFC4474], conditions are the 'if'-part of rules,
	whereas actions and transformations form their 'then'-part. The		whereas actions and transformations form their 'then'-part. The
	actions and transformations parts of a rule determine which		actions and transformations parts of a rule determine which
	operations the proxy server MUST execute on receiving a connection		operations the proxy server MUST execute on receiving a connection
	request attempt that matches all conditions of this rule. Actions		request attempt that matches all conditions of this rule. Actions
	and transformations permit certain operations to be executed.		and transformations permit certain operations to be executed.
	skipping to change at page 18, line 35 ¶		skipping to change at page 12, line 8 ¶
	etc. can be executed. Each mechanism needs to register a URI and the		etc. can be executed. Each mechanism needs to register a URI and the
	value of URI is placed in this field.		value of URI is placed in this field.
	[Editior's Note: For editorial purposes the schema currently lists a		[Editior's Note: For editorial purposes the schema currently lists a
	few examples but in a non-URI format. When solution documents define		few examples but in a non-URI format. When solution documents define
	these URIs then they can be used with this document.]		these URIs then they can be used with this document.]
	5.2. Forward To		5.2. Forward To
	The action supported in this section is forwarding of calls with the		The action supported in this section is forwarding of calls with the
	<forward-to> element that contains the following child elements:		<forward-to> element that contains the following child element
			<target> that specifies the address of the forwarding rule. It
	target:		should be a valid SIP URI (RFC 3261 [RFC3261]) or TEL URI (RFC 3966
			[RFC3966]).
	Specifies the address of the forwarding rule. It should be a
	valid SIP URI (RFC 3261 [RFC3261]) or TEL URI (RFC 3966
	[RFC3966]).
	6. Examples		6. Examples
	This section provides a few examples for policy rules defined in this		This section provides a few examples for policy rules defined in this
	document. The example policy shows three rules with the rule id r1 -		document.
			6.1. Identity and Time-Based Policy
			The following policy shows a white list with an identity condition
			and a simple time-based condition.
			<?xml version="1.0" encoding="UTF-8"?>
			<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
			xmlns:spit="urn:ietf:params:xml:ns:spit-policy"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<rule id="AA56i09">
			<conditions>
			<identity>
			<one id="sip:bob@example.com"/>
			<many>
			<except domain="example.com"/>
			<except domain="example.org"/>
			<except id="sip:alice@bad.example.net"/>
			<except id="sip:bob@good.example.net"/>
			<except id="tel:+1-212-555-1234" />
			<except id="sip:alice@example.com"/>
			</many>
			</identity>
			<sphere value="work"/>
			<validity>
			<from>2003-12-24T17:00:00+01:00</from>
			<until>2003-12-24T19:00:00+01:00</until>
			</validity>
			</conditions>
			<actions>
			<spit:handling>allow</spit:handling>
			</actions>
			<transformations/>
			</rule>
			</ruleset>
			6.2. Extended Time-Based Policy
			The following policy shows the usage of the <time-period> element to
			forward calls to an answering machine during the night.
			<?xml version="1.0" encoding="UTF-8"?>
			<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
			xmlns:spit="urn:ietf:params:xml:ns:spit-policy"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<rule id="AA56i10">
			<conditions>
			<spit:time-period>
			<time dtstart="19970105T083000"
			timestart="2200"
			timeend="0800"
			byweekday="MO,TU,WE,TH,FR"
			dtend="19991230T183000"/>
			</spit:time-period>
			</conditions>
			<actions>
			<spit:forward-to>
			<target>sip:answering-machine@home.foo-bar.com
			</target>
			</spit:forward-to>
			</actions>
			<transformations/>
			</rule>
			</ruleset>
			6.3. Policy for triggering Captcha and Hashcash Challenges
			The following example policy shows three rules with the rule id r1 -
	r4.		r4.
	Rule r1 matches for authenticated identities from the domain		Rule r1 matches for authenticated identities from the domain
	"example.com", "example.org" and the single identity		"example.com", "example.org" and the single identity
	"sip:bob@good.example.net". For these conditions SIP messages are		"sip:bob@good.example.net". For these conditions SIP messages are
	forwarded to the SIP UA as indicated with the <handling> element.		forwarded to the SIP UA as indicated with the <handling> element.
	Rule r2 indicates that for SIP messages where the identity has not		Rule r2 indicates that for SIP messages where the identity has not
	been verifiable the hash cash mechanism		been verifiable the hash cash mechanism
	[I-D.jennings-sip-hashcash] and CAPTCHAs		[I-D.jennings-sip-hashcash] and CAPTCHAs
	skipping to change at page 21, line 20 ¶		skipping to change at page 17, line 4 ¶
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<!-- This import brings in the XML language attribute xml:lang-->		<!-- This import brings in the XML language attribute xml:lang-->
	<xs:import namespace="http://www.w3.org/XML/1998/namespace"		<xs:import namespace="http://www.w3.org/XML/1998/namespace"
	schemaLocation="http://www.w3.org/2001/xml.xsd"/>		schemaLocation="http://www.w3.org/2001/xml.xsd"/>
	<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>		<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
	<!-- Conditions -->		<!-- Conditions -->
	<xs:element name="method-list">
	<xs:complexType>
	<xs:complexContent>
	<xs:restriction base="xs:anyType">
	<xs:sequence>
	<xs:element name="method" type="spit:method-type"
	minOccurs="0" maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:restriction>
	</xs:complexContent>
	</xs:complexType>
	</xs:element>
	<xs:element name="spit-handling">		<xs:element name="spit-handling">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="challenge" type="spit:challenge-type"		<xs:element name="challenge" type="spit:challenge-type"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="result" use="required">		<xs:attribute name="result" use="required">
	<xs:simpleType>		<xs:simpleType>
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:enumeration value="SUCCESS"/>		<xs:enumeration value="SUCCESS"/>
	<xs:enumeration value="FAILURE"/>		<xs:enumeration value="FAILURE"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
			</xs:attribute>
	</xs:attribute>
	</xs:complexType>
	</xs:element>
	<xs:element name="mime-list">
	<xs:complexType>
	<xs:complexContent>
	<xs:restriction base="xs:anyType">
	<xs:sequence>
	<xs:element name="mime" type="spit:mime-type"
	minOccurs="0" maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:restriction>
	</xs:complexContent>
	</xs:complexType>
	</xs:element>
	<xs:element name="media-list">
	<xs:complexType>
	<xs:complexContent>
	<xs:restriction base="xs:anyType">
	<xs:sequence>
	<xs:element name="media" type="spit:media-type"
	minOccurs="0" maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:restriction>
	</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="rule-deactivated"
	type="spit:empty-element-type"/>
	<xs:complexType name="empty-element-type"/>
	<xs:element name="presence-status"		<xs:element name="presence-status"
	type="spit:presence-status-activity-type"/>		type="spit:presence-status-activity-type"/>
	<xs:simpleType name="presence-status-activity-type">		<xs:simpleType name="presence-status-activity-type">
	<xs:restriction base="xs:string"/>		<xs:restriction base="xs:string"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="media-type">
	<xs:restriction base="xs:string"/>
	</xs:simpleType>
	<xs:simpleType name="challenge-type">		<xs:simpleType name="challenge-type">
	<xs:restriction base="xs:string"/>		<xs:restriction base="xs:string"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="mime-type">
	<xs:restriction base="xs:string"/>
	</xs:simpleType>
	<xs:simpleType name="method-type">
	<xs:restriction base="xs:string"/>
	</xs:simpleType>
	<xs:element name="time-period" type="spit:TimeSwitchType"/>		<xs:element name="time-period" type="spit:TimeSwitchType"/>
	<xs:simpleType name="YearDayType">
	<xs:union>
	<xs:simpleType>
	<xs:restriction base="xs:integer">
	<xs:minInclusive value="-366"/>
	<xs:maxInclusive value="-1"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType>
	<xs:restriction base="xs:integer">
	<xs:minInclusive value="1"/>
	<xs:maxExclusive value="366"/>
	</xs:restriction>
	</xs:simpleType>
	</xs:union>
	</xs:simpleType>
	<xs:simpleType name="DayType">
	<xs:restriction base="xs:NMTOKEN">
	<xs:pattern value="[m|M][o|O]"/>
	<xs:pattern value="[t|T][u|U]"/>
	<xs:pattern value="[w|W][e|E]"/>
	<xs:pattern value="[t|T][h|H]"/>
	<xs:pattern value="[f|F][r|R]"/>
	<xs:pattern value="[s|S][a|A]"/>
	<xs:pattern value="[s|S][u|U]"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="TimeType">		<xs:complexType name="TimeType">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>Exactly one of the two attributes		<xs:documentation>Exactly one of the two attributes
	"dtend" and "duration" must occur. None of		"dtend" and "duration" must occur. None of
	the attributes following freq are meaningful		the attributes following freq are meaningful
	unless freq appears. </xs:documentation>		unless freq appears. </xs:documentation>
	</xs:annotation>		</xs:annotation>
	<xs:attribute name="dtstart" type="xs:string" use="required">		<xs:attribute name="dtstart" type="xs:string" use="required">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>		<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
	</xs:annotation>		</xs:annotation>
	</xs:attribute>		</xs:attribute>
	<xs:attribute name="dtend" type="xs:string" use="optional">
	<xs:annotation>		<xs:attribute name="dtend" type="xs:string" use="required">
	<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="duration" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation>RFC 2445 DURATION</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="freq" type="spit:FreqType" use="optional"/>
	<xs:attribute name="interval"
	type="xs:positiveInteger" default="1"/>
	<xs:attribute name="until" type="xs:string" use="optional">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>		<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
	</xs:annotation>		</xs:annotation>
	</xs:attribute>		</xs:attribute>
	<xs:attribute name="count"
	type="xs:positiveInteger" use="optional"/>		<xs:attribute name="timestart" type="xs:string" use="optional"
	<xs:attribute name="bysecond"		default="000000">
	type="xs:string" use="optional">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>Comma-separated list of		<xs:documentation>RFC 2445 TIME. It represents time in hours,
	seconds within a minute. Valid values are 0 to		minutes and seconds and denotes the beginning of the day
	59.</xs:documentation>		time. The default value is 000000, denoting the
			beginning of the day. </xs:documentation>
	</xs:annotation>		</xs:annotation>
	</xs:attribute>		</xs:attribute>
	<xs:attribute name="byminute"
	type="xs:string" use="optional">		<xs:attribute name="timeend" type="xs:string" use="optional"
			default="235959">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>Comma-separated list of		<xs:documentation>RFC 2445 TIME. It represents time in
	minutes within an hour. Valid values are 0 to		hours, minutes and seconds and denotes the
	59.</xs:documentation>		end of the day time. The default value is 235959,
			denoting the end of the day. </xs:documentation>
	</xs:annotation>		</xs:annotation>
	</xs:attribute>		</xs:attribute>
	<xs:attribute name="byhour" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation>Comma-separated list of
	hours of the day. Valid values are 0 to
	23.</xs:documentation>		<xs:attribute name="byweekday" type="xs:string" use="optional">
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="byday" type="xs:string" use="optional">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>Comma-separated list of days of the week.		<xs:documentation>Comma-separated list of days of the week.
	Valid values are "MO", "TU",		Valid values are "MO", "TU",
	"WE", "TH", "FR", "SA" and "SU". These values are		"WE", "TH", "FR", "SA" and "SU". These values are
	not case-sensitive. Each can be preceded		not case-sensitive. Each can be preceded
	by a positive (+n) or negative (-n) integer.		by a positive (+n) or negative (-n) integer.
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
	</xs:attribute>		</xs:attribute>
	<xs:attribute name="bymonthday" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation>Comma-separated list of days of the month.
	Valid values are 1 to 31 or -31
	to -1.</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="byyearday" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation>Comma-separated list of days of the year.
	Valid values are 1 to 366 or
	-366 to -1.</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="byweekno" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation>Comma-separated list of ordinals
	specifying weeks of the year. Valid
	values are 1 to 53 or -53 to -1.</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="bymonth" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation>Comma-separated list of months of the year.
	Valid values are 1 to
	12.</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="wkst" type="spit:DayType" default="MO"/>
	<xs:attribute name="bysetpos" type="spit:YearDayType"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>		<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="TZIDType">
	<xs:restriction base="xs:string"/>
	</xs:simpleType>
	<xs:simpleType name="TZURLType">
	<xs:restriction base="xs:anyURI"/>
	</xs:simpleType>
	<xs:complexType name="TimeSwitchType">		<xs:complexType name="TimeSwitchType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="time" type="spit:TimeType"		<xs:element name="time" type="spit:TimeType"
	minOccurs="1" maxOccurs="unbounded"/>		minOccurs="1" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="tzid" type="spit:TZIDType"/>
	<xs:attribute name="tzurl" type="spit:TZURLType"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="FreqType">
	<xs:restriction base="xs:NMTOKEN">
	<xs:pattern value="[s|S][e|E][c|C][o|O][n|N][d|D][l|L][y|Y]"/>
	<xs:pattern value="[m|M][i|I][n|N][u|U][t|T][e|E][l|L][y|Y]"/>
	<xs:pattern value="[h|H][o|O][u|U][r|R][l|L][y|Y]"/>
	<xs:pattern value="[d|D][a|A][i|I][l|L][y|Y]"/>
	<xs:pattern value="[w|W][e|E][e|E][k|K][l|L][y|Y]"/>
	<xs:pattern value="[m|M][o|N][n|N][t|T][h|H][l|L][y|Y]"/>
	<xs:pattern value="[y|Y][e|E][a|A][r|R][l|L][y|Y]"/>
	</xs:restriction>
	</xs:simpleType>
	<!-- Action -->		<!-- Action -->
	<xs:element name="execute">		<xs:element name="execute">
	<xs:simpleType>		<xs:simpleType>
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	</xs:element>		</xs:element>
	<xs:element name="forward-to" type="spit:forward-to-type"/>		<xs:element name="forward-to" type="spit:forward-to-type"/>
	<xs:complexType name="forward-to-type">		<xs:complexType name="forward-to-type">
	<xs:sequence>		<xs:sequence>
	<xs:element name="target" type="spit:target-type"/>		<xs:element name="target" type="spit:target-type"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	skipping to change at page 28, line 33 ¶		skipping to change at page 21, line 8 ¶
	of such policies is outside the scope of this document.		of such policies is outside the scope of this document.
	9. IANA Considerations		9. IANA Considerations
	There are several IANA considerations associated with this		There are several IANA considerations associated with this
	specification.		specification.
	9.1. Anti-SPIT Policy XML Schema Registration		9.1. Anti-SPIT Policy XML Schema Registration
	URI: urn:ietf:params:xml:schema:spit-policy		URI: urn:ietf:params:xml:schema:spit-policy
	Registrant Contact: Hannes Tschofenig		Registrant Contact: Hannes Tschofenig (hannes.tschofenig@nsn.com).
	(hannes.tschofenig@siemens.com).
	XML: The XML schema to be registered is contained in Section 7. Its		XML: The XML schema to be registered is contained in Section 7. Its
	first line is		first line is
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	and its last line is		and its last line is
	</xs:schema>		</xs:schema>
	9.2. Anti-SPIT Policy Namespace Registration		9.2. Anti-SPIT Policy Namespace Registration
	URI: urn:ietf:params:xml:ns:spit-policy		URI: urn:ietf:params:xml:ns:spit-policy
	Registrant Contact: Hannes Tschofenig		Registrant Contact: Hannes Tschofenig (hannes.tschofenig@nsn.com).
	(hannes.tschofenig@siemens.com).
	XML:		XML:
	9.3. XCAP Application Usage ID		9.3. XCAP Application Usage ID
	This section registers an XCAP Application Usage ID (AUID) according		This section registers an XCAP Application Usage ID (AUID) according
	to the IANA procedures defined in [RFC4825].		to the IANA procedures defined in [RFC4825].
	Name of the AUID: spit-policy		Name of the AUID: spit-policy
	Description: The rules defined in this documents describe ways to		Description: The rules defined in this documents describe ways to
	skipping to change at page 30, line 4 ¶		skipping to change at page 22, line 18 ¶
	We would like to thank Mayutan Arumaithurai		We would like to thank Mayutan Arumaithurai
	(mayutan.arumaithurai@gmail.com) for his work on this document.		(mayutan.arumaithurai@gmail.com) for his work on this document.
	12. Acknowledgments		12. Acknowledgments
	We would like to thank		We would like to thank
	o Jonathan Rosenberg, David Schwartz and Dan York for sharing their		o Jonathan Rosenberg, David Schwartz and Dan York for sharing their
	thoughts with us before the first version of this document was		thoughts with us before the first version of this document was
	written.		written.
	o Miguel Garcia and Remi Denis-Courmont for their review comments to		o Miguel Garcia and Remi Denis-Courmont for their review comments to
	the -00 version.		the -00 version.
	o Mayutan Arumaithurai for his editing help with the -00 version.		o Mayutan Arumaithurai for his editing help with the -00 version.
	o Poikselka Miikka, Isomaki Markus, Jari Mutikainen, Jean-Marie		o Poikselka Miikka, Isomaki Markus, Jari Mutikainen, Jean-Marie
	Stupka, and Antti Laurila for their comments and for pointing us		Stupka, and Antti Laurila for their comments and for pointing us
	to specifications outside the IETF.		to specifications outside the IETF.
	This document intentionally re-uses concept from existing documents.		This document intentionally re-uses concept from existing documents.
	In particular, we reused		In particular, we reused
	o ideas from SIEVE [RFC3028], a mail filtering language.		o ideas from SIEVE [RFC3028], a mail filtering language.
	o the text in Section 4.9 from the Call Processing Language (CPL)		o the text in Section 4.5 is based on the description in the Call
	[RFC3880]. The difference between CPL and this document is that		Processing Language (CPL) [RFC3880]. In general, the difference
	CPL has a more procedural approach, while this proposal is		between CPL and this document is that CPL has a more procedural
	matching-based.		approach, while this proposal is matching-based. It is obviously
			possible to enhance CPL as well to provide the functionality
			offered in this document.
	o text in Section 4.1 from [I-D.ietf-simple-presence-rules].		o text in Section 4.1 from [I-D.ietf-simple-presence-rules].
	o content of Section 5.2, Section 4.8 and Section 4.7 is reused from		o content of Section 5.2, and Section 4.4 is reused from
	[ETSI-TS-183-004].		[ETSI-TS-183-004].
	o text of Section 4.4 from [OMA-TS-XDM_Shared_Policy]
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		Requirement Levels", March 1997.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	skipping to change at page 31, line 51 ¶		skipping to change at page 24, line 19 ¶
	13.2. Informative References		13.2. Informative References
	[ETSI-TS-183-004]		[ETSI-TS-183-004]
	ETSI, "TS 183 004, Telecommunications and Internet		ETSI, "TS 183 004, Telecommunications and Internet
	converged Services and Protocols for Advanced Networking		converged Services and Protocols for Advanced Networking
	(TISPAN); PSTN/ISDN simulation services: Communication		(TISPAN); PSTN/ISDN simulation services: Communication
	Diversion (CDIV); Protocol specification", 2007.		Diversion (CDIV); Protocol specification", 2007.
	[I-D.froment-sipping-spit-requirements]		[I-D.froment-sipping-spit-requirements]
	Froment, T., "Requirements for Authorization Policies to		Froment, T., "Requirements for Authorization Policies to
	tackle Spam for Internet Telephony and Unwanted Traffic",		tackle Spam and Unwanted Communication for Internet
	draft-froment-sipping-spit-requirements-00 (work in		Telephony", draft-froment-sipping-spit-requirements-01
	progress), June 2007.		(work in progress), July 2007.
	[I-D.ietf-ecrit-service-urn]		[I-D.ietf-ecrit-service-urn]
	Schulzrinne, H., "A Uniform Resource Name (URN) for		Schulzrinne, H., "A Uniform Resource Name (URN) for
	Services", draft-ietf-ecrit-service-urn-06 (work in		Emergency and Other Well-Known Services",
	progress), March 2007.		draft-ietf-ecrit-service-urn-07 (work in progress),
			August 2007.
	[I-D.ietf-mmusic-file-transfer-mech]		[I-D.ietf-mmusic-file-transfer-mech]
	Garcia-Martin, M., "A Session Description Protocol (SDP)		Garcia-Martin, M., Isomaki, M., Camarillo, G., and S.
	Offer/Answer Mechanism to Enable File Transfer",		Loreto, "A Session Description Protocol (SDP) Offer/Answer
	draft-ietf-mmusic-file-transfer-mech-03 (work in		Mechanism to Enable File Transfer",
	progress), June 2007.		draft-ietf-mmusic-file-transfer-mech-04 (work in
			progress), October 2007.
	[I-D.ietf-simple-message-sessions]		[I-D.ietf-simple-message-sessions]
	Campbell, B., "The Message Session Relay Protocol",		Campbell, B., "The Message Session Relay Protocol",
	draft-ietf-simple-message-sessions-19 (work in progress),		draft-ietf-simple-message-sessions-19 (work in progress),
	February 2007.		February 2007.
	[I-D.ietf-simple-presence-rules]		[I-D.ietf-simple-presence-rules]
	Rosenberg, J., "Presence Authorization Rules",		Rosenberg, J., "Presence Authorization Rules",
	draft-ietf-simple-presence-rules-09 (work in progress),		draft-ietf-simple-presence-rules-10 (work in progress),
	March 2007.		July 2007.
	[I-D.ietf-sip-consent-framework]		[I-D.ietf-sip-consent-framework]
	Rosenberg, J., "A Framework for Consent-Based		Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
	Communications in the Session Initiation Protocol (SIP)",		for Consent-based Communications in the Session Initiation
	draft-ietf-sip-consent-framework-02 (work in progress),		Protocol (SIP)", draft-ietf-sip-consent-framework-03 (work
	July 2007.		in progress), November 2007.
	[I-D.ietf-sipping-spam]		[I-D.ietf-sipping-spam]
	Jennings, C. and J. Rosenberg, "The Session Initiation		Rosenberg, J. and C. Jennings, "The Session Initiation
	Protocol (SIP) and Spam", draft-ietf-sipping-spam-04 (work		Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work
	in progress), February 2007.		in progress), July 2007.
	[I-D.jennings-sip-hashcash]		[I-D.jennings-sip-hashcash]
	Jennings, C., "Computational Puzzles for SPAM Reduction in		Jennings, C., "Computational Puzzles for SPAM Reduction in
	SIP", draft-jennings-sip-hashcash-05 (work in progress),		SIP", draft-jennings-sip-hashcash-06 (work in progress),
	June 2007.		July 2007.
	[I-D.mahy-iptel-cpc]		[I-D.mahy-iptel-cpc]
	Mahy, R., "The Calling Party's Category tel URI		Mahy, R., "The Calling Party's Category tel URI
	Parameter", draft-mahy-iptel-cpc-06 (work in progress),		Parameter", draft-mahy-iptel-cpc-06 (work in progress),
	March 2007.		March 2007.
	[I-D.rosenberg-sipping-service-identification]		[I-D.rosenberg-sipping-service-identification]
	Rosenberg, J., "Identification of Communications Services		Rosenberg, J., "Identification of Communications Services
	in the Session Initiation Protocol (SIP)",		in the Session Initiation Protocol (SIP)",
	draft-rosenberg-sipping-service-identification-02 (work in		draft-rosenberg-sipping-service-identification-03 (work in
	progress), May 2007.		progress), July 2007.
	[I-D.schubert-sipping-saml-cpc]		[I-D.schubert-sipping-saml-cpc]
	Schubert, S., "Conveying CPC using the SAML",		Schubert, S., "Conveying CPC using the SAML",
	draft-schubert-sipping-saml-cpc-02 (work in progress),		draft-schubert-sipping-saml-cpc-02 (work in progress),
	July 2006.		July 2006.
	[I-D.schwartz-sipping-spit-saml]		[I-D.schwartz-sipping-spit-saml]
	Schwartz, D., "SPAM for Internet Telephony (SPIT)		Schwartz, D., "SPAM for Internet Telephony (SPIT)
	Prevention using the Security Assertion Markup Language		Prevention using the Security Assertion Markup Language
	(SAML)", draft-schwartz-sipping-spit-saml-01 (work in		(SAML)", draft-schwartz-sipping-spit-saml-01 (work in
	skipping to change at page 33, line 26 ¶		skipping to change at page 25, line 46 ¶
	[I-D.tschofenig-sipping-captcha]		[I-D.tschofenig-sipping-captcha]
	Tschofenig, H. and E. Leppanen, "Completely Automated		Tschofenig, H. and E. Leppanen, "Completely Automated
	Public Turing Test to Tell Computers and Humans Apart		Public Turing Test to Tell Computers and Humans Apart
	(CAPTCHA) based Robot Challenges for the Session		(CAPTCHA) based Robot Challenges for the Session
	Initiation Protocol (SIP)",		Initiation Protocol (SIP)",
	draft-tschofenig-sipping-captcha-00 (work in progress),		draft-tschofenig-sipping-captcha-00 (work in progress),
	July 2007.		July 2007.
	[I-D.tschofenig-sipping-framework-spit-reduction]		[I-D.tschofenig-sipping-framework-spit-reduction]
	Tschofenig, H., "A Framework for Reducing Spam for		Tschofenig, H., "A Framework to tackle Spam and Unwanted
	Internet Telephony",		Communication for Internet Telephony",
	draft-tschofenig-sipping-framework-spit-reduction-00 (work		draft-tschofenig-sipping-framework-spit-reduction-01 (work
	in progress), June 2007.		in progress), July 2007.
	[ISO8601] ISO (International Organization for Standardization),		[ISO8601] ISO (International Organization for Standardization),
	""Data elements and interchange formats -- Information		""Data elements and interchange formats -- Information
	interchange -- Representation of dates and times", ISO		interchange -- Representation of dates and times", ISO
	Standard ISO 8601:2000(E), International Organization for		Standard ISO 8601:2000(E), International Organization for
	Standardization, Geneva, Switzerland,", December 2000.		Standardization, Geneva, Switzerland,", December 2000.
	[OMA-TS-XDM_Shared_Policy]		[OMA-TS-XDM_Shared_Policy]
	Open Mobile Alliance, "Shared Policy XDM Specification",		Open Mobile Alliance, "Shared Policy XDM Specification",
	2007.		2007.
End of changes. 62 change blocks.
	644 lines changed or deleted		237 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/