< draft-ietf-simple-prescaps-ext-00.txt		draft-ietf-simple-prescaps-ext-01.txt >
	SIMPLE WG M. Lonnfors		SIMPLE WG M. Lonnfors
	Internet-Draft Nokia Research Center		Internet-Draft K. Kiss
	Expires: August 7, 2004 K. Kiss		Expires: November 5, 2004 Nokia
	Nokia		May 7, 2004
	February 7, 2004
	User agent capability presence status extension		User Agent Capability Extension to Presence Information Data Format
	draft-ietf-simple-prescaps-ext-00		(PIDF)
			draft-ietf-simple-prescaps-ext-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as
			Internet-Drafts.
	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."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at
	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 August 7, 2004.		This Internet-Draft will expire on November 5, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	Interoperation of Instant Messaging and Presence systems has been		Interoperation of Instant Messaging and Presence systems has been
	defined in IMPP working group. IMPP WG has come up with baseline		defined in the IMPP working group. The IMPP WG has come up with
	interoperable operations and formats for presence and instant		baseline interoperable operations and formats for presence and
	messaging systems. However, these base formats might need		instant messaging systems. However, these base formats might need
	standardized extensions in order to enable building rational		standardized extensions in order to enable building rational
	applications using presence and instant messaging. This memo proposes		applications using presence and instant messaging. This memo
	an extension to PIDF presence document format to represent		proposes an extension to represent "Indicating User Agent
	"Indicating User Agent Capabilities in the Session Initiation		Capabilities in the Session Initiation Protocol (SIP)" capabilities
	Protocol (SIP)" capabilities to be used in SIMPLE based presence		in the Presence Information Document Format (PIDF) compliant presence
	systems but may also be applied to other protocols as well.		documents.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Extension for "Indicating User Agent Capabilities in		3. Extension for "Indicating User Agent Capabilities in the
	the Session Initiation Protocol (SIP)" in PIDF documents . 5		Session Initiation Protocol (SIP)" in PIDF documents . . . . 5
	3.1 Extension overview . . . . . . . . . . . . . . . . . . . . 5		3.1 Extension overview . . . . . . . . . . . . . . . . . . . . 5
	3.2 <prescaps> element . . . . . . . . . . . . . . . . . . . . 6		3.2 <prescaps> element . . . . . . . . . . . . . . . . . . . . 6
	3.3 <audio> element . . . . . . . . . . . . . . . . . . . . . 6		3.3 <audio> element . . . . . . . . . . . . . . . . . . . . . 6
	3.4 <application> element . . . . . . . . . . . . . . . . . . 6		3.4 <application> element . . . . . . . . . . . . . . . . . . 6
	3.5 <data> element . . . . . . . . . . . . . . . . . . . . . . 7		3.5 <data> element . . . . . . . . . . . . . . . . . . . . . . 6
	3.6 <control> element . . . . . . . . . . . . . . . . . . . . 7		3.6 <control> element . . . . . . . . . . . . . . . . . . . . 7
	3.7 <video> element . . . . . . . . . . . . . . . . . . . . . 7		3.7 <video> element . . . . . . . . . . . . . . . . . . . . . 7
	3.8 <text> element . . . . . . . . . . . . . . . . . . . . . . 8		3.8 <text> element . . . . . . . . . . . . . . . . . . . . . . 7
	3.9 <type> element . . . . . . . . . . . . . . . . . . . . . . 8		3.9 <type> element . . . . . . . . . . . . . . . . . . . . . . 7
	3.10 <automata> element . . . . . . . . . . . . . . . . . . . . 9		3.10 <automata> element . . . . . . . . . . . . . . . . . . . 7
	3.11 <class> element . . . . . . . . . . . . . . . . . . . . . 9		3.11 <class> element . . . . . . . . . . . . . . . . . . . . 8
	3.12 <duplex> element . . . . . . . . . . . . . . . . . . . . . 9		3.12 <duplex> element . . . . . . . . . . . . . . . . . . . . 8
	3.13 <mobility> element . . . . . . . . . . . . . . . . . . . . 9		3.13 <mobility> element . . . . . . . . . . . . . . . . . . . 8
	3.14 <description> element . . . . . . . . . . . . . . . . . . 9		3.14 <description> element . . . . . . . . . . . . . . . . . 8
	3.15 <event-packages> element . . . . . . . . . . . . . . . . . 10		3.15 <event-packages> element . . . . . . . . . . . . . . . . 8
	3.15.1 <event-package> . . . . . . . . . . . . . . . . . . . . . 10		3.15.1 <event-package> . . . . . . . . . . . . . . . . . . 9
	3.16 <priority> element . . . . . . . . . . . . . . . . . . . . 10		3.16 <priority> element . . . . . . . . . . . . . . . . . . . 9
	3.17 <methods> element . . . . . . . . . . . . . . . . . . . . 10		3.17 <methods> element . . . . . . . . . . . . . . . . . . . 9
	3.17.1 <method> . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.17.1 <method> . . . . . . . . . . . . . . . . . . . . . . 9
	3.18 <extensions> element . . . . . . . . . . . . . . . . . . . 11		3.18 <extensions> element . . . . . . . . . . . . . . . . . . 10
	3.18.1 <extension> . . . . . . . . . . . . . . . . . . . . . . . 11		3.18.1 <extension> . . . . . . . . . . . . . . . . . . . . 10
	3.19 <schemes> element . . . . . . . . . . . . . . . . . . . . 11		3.19 <schemes> element . . . . . . . . . . . . . . . . . . . 10
	3.19.1 <scheme> . . . . . . . . . . . . . . . . . . . . . . . . . 11		3.19.1 <scheme> . . . . . . . . . . . . . . . . . . . . . . 10
	3.20 <actor> element . . . . . . . . . . . . . . . . . . . . . 11		3.20 <actor> element . . . . . . . . . . . . . . . . . . . . 10
	3.21 <is-focus> element . . . . . . . . . . . . . . . . . . . . 12		3.21 <is-focus> element . . . . . . . . . . . . . . . . . . . 11
	3.22 <languages> element . . . . . . . . . . . . . . . . . . . 12		3.22 <languages> element . . . . . . . . . . . . . . . . . . 11
	3.22.1 <language> . . . . . . . . . . . . . . . . . . . . . . . . 12		3.22.1 <language> . . . . . . . . . . . . . . . . . . . . . 11
	3.23 Extension elements . . . . . . . . . . . . . . . . . . . . 13		4. Publishing and using 'prescaps' elements . . . . . . . . . . 11
	3.23.1 <string> element . . . . . . . . . . . . . . . . . . . . . 13		5. Using extension with PIDF document format . . . . . . . . . 12
	3.23.2 <token> element . . . . . . . . . . . . . . . . . . . . . 13		5.1 Contact URI . . . . . . . . . . . . . . . . . . . . . . . 12
	3.23.3 <boolean> element . . . . . . . . . . . . . . . . . . . . 13		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.23.4 <numeric> element . . . . . . . . . . . . . . . . . . . . 13		6.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4. Publishing and using 'prescaps' elements . . . . . . . . . 14		7. XML schema definitions . . . . . . . . . . . . . . . . . . . 13
	5. Generating SIP request based on 'prescaps' extension . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
	6. Using extension with PIDF document format . . . . . . . . 14		8.1 URN sub-namespace registration for
	6.1 Contact URI . . . . . . . . . . . . . . . . . . . . . . . 15		'urn:ietf:params:xml:ns:simple-prescaps-ext' . . . . . . . 18
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. Security Considerations . . . . . . . . . . . . . . . . . . 18
	7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19
	8. XML schema definitions . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . 22		11.1 Normative references . . . . . . . . . . . . . . . . . . . 19
	9.1 URN sub-namespace registration for		11.2 Informative references . . . . . . . . . . . . . . . . . . 20
	'urn:ietf:params:xml:ns:simple-prescaps-ext' . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
	10. Security Considerations . . . . . . . . . . . . . . . . . 23		Intellectual Property and Copyright Statements . . . . . . . 22
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 24
	Normative references . . . . . . . . . . . . . . . . . . . 24
	Informative references . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 25
	Intellectual Property and Copyright Statements . . . . . . 27
	1. Introduction		1. Introduction
	Interoperation of instant messaging and presence systems has been		Interoperation of instant messaging and presence systems has been
	defined in IMPP working group. Working group has defined "A model for		defined in IMPP working group. Working group has defined "A model
	Presence and Instant Messaging" [2] and also requirements for		for Presence and Instant Messaging" RFC2778 [2] and also requirements
	protocols implementing such a system [3]. Common presence and instant		for protocols implementing such a system in RFC 2779 [3]. Common
	messaging (CPP/CPIM) defines common operations and formats which all		presence (CPP) [5] and instant messaging (CPIM) [11] define common
	Presence and Instant Messaging services must agree upon so that basic		operations and formats which all Presence and Instant Messaging
	interoperability would be possible [5], [10]. The actual base format		services must agree upon so that basic interoperability would be
	for presence is being defined in PIDF [4]. The PIDF document format		possible. The actual base format for the presence is defined in the
	has been designed to reduce the need for gatewaying and to allow		Presence Information Document Format (PIDF) [4]. The PIDF document
	end-to-end security of presence data. It has taken very minimalistic		format has been designed to reduce the need for gatewaying and to
	approach to support such operations. In order to make the PIDF format		allow end-to-end security of presence data. It has taken very
	usable by different presence applications, these applications usually		minimalistic approach to support such operations. In order to make
	must extend the basic PIDF format by standard XML mechanism as		the PIDF format usable by different presence applications, these
	defined in [4].		applications usually must extend the basic PIDF format by standard
			XML mechanism as defined in the PIDF [4].
	The aim of this memo is to introduce SIP/SIMPLE specific extension		The aim of this memo is to introduce SIP/SIMPLE specific extension
	mechanism for the PIDF document. With this extension SIMPLE based		mechanism for the PIDF document. With this extension SIMPLE based
	applications can have richer and more usable formats compared to the		applications can have richer and more usable formats compared to the
	baseline PIDF data format. Aim of this document is to introduce		baseline PIDF data format. Aim of this document is to introduce
	extension for "Indicating User Agent Capabilities in the Session		extension for "Indicating User Agent Capabilities in the Session
	Initiation Protocol (SIP)" [6].		Initiation Protocol (SIP)" [6].
	1.1 Motivation		1.1 Motivation
	The PIDF document format [4] defines a <contact> element which may		The PIDF document format [4] defines a <contact> element which may
	appear once inside every <tuple> element. The content of the		appear once inside every <tuple> element. The content of the
	<contact> element encodes the CONTACT ADDRESS and CONTACT MEANS as		<contact> element encodes the CONTACT ADDRESS and CONTACT MEANS as
	defined in [2]. The <contact> element is defined to be an URI. This		defined in RFC2778 [2]. The <contact> element is defined to be an
	URI can be of any URI type. In some implementations this URI can		URI. This URI can be of any URI type. In some implementations this
	uniquely identify the application the tuple intends to describe (e.g.		URI can uniquely identify the application the tuple intends to
	im: URIs). However, this may not be the case in all implementations.		describe (e.g. im: URIs usually represent Instant Messaging
			service). However, this may not be the case in all implementations.
	For example in SIP, a SIP URI can represent different kinds of		For example in SIP, a SIP URI can represent different kinds of
	applications. A SIP URI can be used to contact voice applications,		applications. A SIP URI can be used to contact voice applications,
	video applications, or messaging applications. If it is not known by		video applications, or messaging applications. If it is not known by
	other means, it might be hard for applications processing the		other means, it might be hard for applications processing the
	presence document containing only SIP URI contact addresses to know		presence document containing only SIP URI contact addresses to know
	what particular application the tuple intends to describe. Also		what particular application the tuple intends to describe. Also
	watchers receiving presence information would probably benefit for		watchers receiving presence information would probably benefit for
	getting more descriptive information about what particular		getting more descriptive information about what particular
	communication means or applications are supported by the presentity.		communication means or applications are supported by the presentity.
	"Indicating User Agent Capabilities in the Session Initiation		"Indicating User Agent Capabilities in the Session Initiation
	Protocol (SIP)" document [6] defines a set of extensions which allow		Protocol (SIP)" document [6] defines a set of extensions which allow
	callees to express preferences about request handling in SIP servers.		callees to express preferences about request handling in SIP servers.
	The same information could provide value also to presence watchers so
	that they could make more rational decisions on how presentity should		The same information can provide value also to presence watchers so
			that they can make more rational decisions on how presentity should
	be contacted if presence document would contain similar information		be contacted if presence document would contain similar information
	as defined in "Indicating User Agent Capabilities in the Session		as defined in "Indicating User Agent Capabilities in the Session
	Initiation Protocol (SIP)" extension.		Initiation Protocol (SIP)" extension.
	1.2 Scope		1.2 Scope
	This document defines extension to the PIDF document format which		This document defines extension to the PIDF document format which
	enables presence implementations based on SIP protocol to utilize		enables presence implementations based on SIP protocol to utilize
	similar capabilities in presence document as what "Indicating User		similar capabilities in presence document as what "Indicating User
	Agent Capabilities in the Session Initiation Protocol (SIP)" document		Agent Capabilities in the Session Initiation Protocol (SIP)" document
	[6] defines.		[6] defines.
	This extension does not replace media negotiation mechanisms defined		This extension does not replace media negotiation mechanisms defined
	for SIP (e.g. SDP [14]), therefore media negotiation (e.g. choose of		for SIP (e.g. SDP [15]). This extension is only aimed to give the
	voice and video codecs) MUST be performed according to [11]. This		watchers hints about the presentity's preferences, willingness and
	extension is only aimed to give the watchers hints about the		capabilities to communicate before watchers would initiate
	presentity's preferences, willingness and capabilities to communicate		communication with the presentity.
	before watchers would initiate SIP based communication with the
	presentity.
	2. Conventions		2. Conventions
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and		and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
	indicate requirement levels for compliant implementations.		indicate requirement levels for compliant implementations.
	This memo makes use of the vocabulary defined in RFC2778 [2], and in		This memo makes use of the vocabulary defined in RFC2778 [2], and in
	PIDF [4].		PIDF [4].
	3. Extension for "Indicating User Agent Capabilities in the Session		3. Extension for "Indicating User Agent Capabilities in the Session
	Initiation Protocol (SIP)" in PIDF documents		Initiation Protocol (SIP)" in PIDF documents
	This section presents "Indicating User Agent Capabilities in the		This section presents "Indicating User Agent Capabilities in the
	Session Initiation Protocol (SIP)" extension namespace, its elements,		Session Initiation Protocol (SIP)" extension namespace, its elements,
	their values, and semantics. This section also describes how this		their values, and semantics. This section also describes how this
	extension can be further extended. Extension is intended to be used		extension can be further extended. Extension is intended to be used
	with "urn:ietf:params:xml:ns:pidf" namespace and that particular		with "urn:ietf:params:xml:ns:pidf" namespace and that particular
	usage is described here. This extension may also be used with other		usage is described here. This extension may also be used with other
	namespaces if appropriate.		namespaces if appropriate.
	3.1 Extension overview		3.1 Extension overview
	This extension adds features presented in "Indicating User Agent		This extension adds features presented in "Indicating User Agent
	Capabilities in the Session Initiation Protocol (SIP)" document [6]		Capabilities in the Session Initiation Protocol (SIP)" document [6]
	into PIDF presence document format. Extension also includes type		into the PIDF presence document format. Extension also includes type
	feature tag [7] and language feature tag [8]. Features presented in		feature tag RFC2913 [7] and language feature tag RFC2987 [8]
	[6], [7], and [8] are added here without any change in their		definitions. Features presented in "Indicating User Agent
	semantics. Bringing these features to PIDF presence document format		Capabilities in the Session Initiation Protocol (SIP)"[6], RFC2913
	basically means mapping them to XML structure. Namespace identifier		[7], and RFC2987 [8] are used here without any change in their
	for this extension is:		semantics. Bringing these features to the PIDF presence document
			format basically means mapping them to XML formatted structure.
			Namespace identifier for this extension is:
	urn:ietf:params:xml:ns:simple-prescaps-ext		urn:ietf:params:xml:ns:simple-prescaps-ext
	When this extension namespace is congregated with base PIDF document,		When this extension namespace is congregated with the PIDF document,
	combined document must follow the same general formatting rules as		combined document must follow the same general formatting rules as
	specified in [4] in chapter 4.1.		specified in the PIDF [4] in Section 4.1.
	3.2 <prescaps> element		3.2 <prescaps> element
	Root element of this extension namespace is <prescaps>. The root		Root element of this extension namespace is <prescaps>. The root
	element MUST be always present. This element MAY contain one or more		element MUST be always present. This element MAY contain one or more
	elements as specified later in this document.		elements as specified later in this document.
	<prescaps> element does not have any attributes and it MAY contain		<prescaps> element does not have any attributes and it MAY contain
	other namespace declarations for the extensions used in the presence		other namespace declarations for the extensions used in the presence
	XML document.		XML document.
	3.3 <audio> element		3.3 <audio> element
	The <audio> element indicates that the device supports audio as a		The <audio> element indicates that the device supports audio as a
	streaming media type as defined in [6].		streaming media type as defined in [6].
	The <audio> element can contain 'negated' attribute. This attribute		The <audio> element is of boolean type and does not have any
	is of boolean type. Value 'true' indicates that device supports audio		attributes. Value 'true' indicates that device supports audio media
	media type and value 'false' indicates that device does not support		type and value 'false' indicates that device does not support audio
	audio media type as defined in [6]. Default value for 'negated'		media type.
	attribute is 'false'.
	<audio> element can contain any number of <type> elements which can
	be used to describe audio media types supported by the device. If
	'negated' attribute has value 'true' it is NOT RECOMMENTED to include
	<type> elements. Media types included in <type> elements MUST start
	with 'audio/'.
	3.4 <application> element		3.4 <application> element
	The <application> element indicates that the device supports		The <application> element indicates that the device supports
	application as a streaming media type as defined in [6].		application as a streaming media type as defined in [6].
	The <application> element can contain 'negated' attribute. This		The <application> element is of boolean type and does not have any
	attribute is of boolean type. Value 'true' indicates that device		attributes. Value 'true' indicates that device supports application
	supports application media type and value 'false' indicates that		media type and value 'false' indicates that device does not support
	device does not support application media type as defined in [6].		application media type.
	Default value for 'negated' attribute is 'false'.
	<application> element can contain any number of <type> elements which
	can be used to describe application media types supported by the
	device. If 'negated' attribute has value 'true' it is NOT RECOMMENTED
	to include <type> elements. Media types included in <type> elements
	MUST start with 'application/'.
	3.5 <data> element		3.5 <data> element
	The <data> element indicates that the device supports data as a		The <data> element indicates that the device supports data as a
	streaming media type as defined in [6].		streaming media type as defined in [6].
	The <data> element can contain 'negated' attribute. This attribute is		The <data> element is of boolean type and does not have any
	of boolean type. Value 'true' indicates that device supports data		attributes. Value 'true' indicates that device supports data media
	media type and value 'false' indicates that device does not support		type and value 'false' indicates that device does not support data
	data media type as defined in [6]. Default value for 'negated'		media type.
	attribute is 'false'.
	<data> element can contain any number of <type> elements which can be
	used to describe data media types supported by the device. If
	'negated' attribute has value 'true' it is NOT RECOMMENTED to include
	<type> elements. Media types included in <type> elements MUST start
	with 'data/'.
	3.6 <control> element		3.6 <control> element
	The <control> element indicates that the device supports control as a		The <control> element indicates that the device supports control as a
	streaming media type as defined in [6].		streaming media type as defined in [6].
	The <control> element can contain 'negated' attribute. This attribute		The <control> element is of boolean type and does not have any
	is of boolean type. Value 'true' indicates that device supports		attributes. Value 'true' indicates that device supports control
	control media type and value 'false' indicates that device does not		media type and value 'false' indicates that device does not support
	support control media type as defined in [6]. Default value for		control media type.
	'negated' attribute is 'false'.
	<control> element can contain any number of <type> elements which can
	be used to describe control media types supported by the device. If
	'negated' attribute has value 'true' it is NOT RECOMMENTED to include
	<type> elements. Media types included in <type> elements MUST start
	with 'control/'.
	3.7 <video> element		3.7 <video> element
	The <video> element indicates that the device supports video as a		The <video> element indicates that the device supports video as a
	streaming media type as defined in [6].		streaming media type as defined in [6].
	The <video> element can contain 'negated' attribute. This attribute		The <video> element is of boolean type and does not have any
	is of boolean type. Value 'true' indicates that device supports video		attributes. Value 'true' indicates that device supports video media
	media type and value 'false' indicates that device does not support		type and value 'false' indicates that device does not support video
	video media type as defined in [6]. Default value for 'negated'		media type.
	attribute is 'false'.
	<video> element can contain any number of <type> elements which can
	be used to describe video media types supported by the device. If
	'negated' attribute has value 'true' it is NOT RECOMMENTED to include
	<type> elements. Media types included in <type> elements MUST start
	with 'video/'.
	3.8 <text> element		3.8 <text> element
	The <text> element indicates that the device supports text as a		The <text> element indicates that the device supports text as a
	streaming media type as defined in [6].		streaming media type as defined in [6].
	The <text> element can contain 'negated' attribute. This attribute is		The <text> element is of boolean type and does not have any
	of boolean type. Value 'true' indicates that device supports text		attributes. Value 'true' indicates that device supports text media
	media type and value 'false' indicates that device does not support		type and value 'false' indicates that device does not support text
	text media type as defined in [6]. Default value for 'negated'		media type.
	attribute is 'false'.
	<text> element can contain any number of <type> elements which can be
	used to describe text media types supported by the device. If
	'negated' attribute has value 'true' it is NOT RECOMMENTED to include
	<type> elements. Media types included in <type> elements MUST start
	with 'text/'.
	3.9 <type> element		3.9 <type> element
	The <type> element indicates indicates a MIME media content type		The <type> element indicates a MIME media content type (i.e. that
	(i.e. that appears in a 'Content-type:' header of the corresponding		appears in a 'Content-type:' header of the corresponding
	MIME-formatted data) as defined in [7].		MIME-formatted data) as defined in RFC2913[7].
	The <type> element is of string type and does not have any		The <type> element is of string type and does not have any
	attributes. It must be a string of the form "type/subtype", where		attributes. It must be a string of the form "type/subtype", where
	'type' and 'subtype' are defined by the MIME specification [17]. Only		'type' and 'subtype' are defined by the MIME specification RFC2045
	lower-case letters should be used.		[17]. Only lower-case letters should be used.
	This element can be used inside <audio>, <video>, <text>, <data>,
	<application>, and <control> elements.
	Open issue: Do we need to also allow separate <type> elements outside
	media tags? This would allow representation of other media type
	which are not included into this document (like multipart or
	message).
	3.10 <automata> element		3.10 <automata> element
	The <automata> element indicates whether the UA represents an		The <automata> element indicates whether the UA represents an
	automata (such as a voicemail server, conference server, IVR, or		automata (such as a voicemail server, conference server, IVR, or
	recording device) or a human as defined in [6].		recording device) or a human as defined in [6].
	The <automata> element is of boolean type and does not have any		The <automata> element is of boolean type and does not have any
	attributes. Value 'true' indicates that the UA represents an automata		attributes. Value 'true' indicates that the UA represents an
	and value 'false' indicates that it represents a human.		automata and value 'false' indicates that it represents a human.
	3.11 <class> element		3.11 <class> element
	The <class> element indicates the setting, business or personal, in		The <class> element indicates the setting, business or personal, in
	which a communications device is used as defined in [6].		which a communications device is used as defined in [6].
	The <class> element is of string type and does not have any		The <class> element is of string type and does not have any
	attributes. Possible values include: "business" and "personal".		attributes. Possible values include: "business" and "personal".
	3.12 <duplex> element		3.12 <duplex> element
	The <duplex> element lists whether a communications device can		The <duplex> element lists whether a communications device can
	simultaneously send and receive media ("full"), alternate between		simultaneously send and receive media ("full"), alternate between
	sending and receiving ("half"), can only receive ("receive-only") or		sending and receiving ("half"), can only receive ("receive-only") or
	only send ("send-only") defined in [6].		only send ("send-only") defined in [6].
	The <duplex> element is of string type and does not have any		The <duplex> element is of string type and does not have any
	attributes. possible values include: "full", "half", "receive-only",		attributes. possible values include: "full", "half", "receive-only",
	and "send-only".		and "send-only".
	3.13 <mobility> element		3.13 <mobility> element
	The <mobility> element indicates whether the device is fixed (meaning		The <mobility> element indicates whether the device is fixed (meaning
	that it is associated with a fixed point of contact with the		that it is associated with a fixed point of contact with the
	network), or mobile (meaning that it is not associated with a fixed		network), or mobile (meaning that it is not associated with a fixed
	point or contact). Note that cordless phones are fixed, not mobile,		point or contact). Note that cordless phones are fixed, not mobile,
	based on this definition.as defined in [6].		based on this definition.as defined in [6].
	The <mobility> element is of string type and does not have any		The <mobility> element is of string type and does not have any
	attributes. Possible values include: "fixed" and "mobile"		attributes. Possible values include: "fixed" and "mobile"
	3.14 <description> element		3.14 <description> element
	The <description> element provides a textual description of the		The <description> element provides a textual description of the
	device as defined in [6].		device as defined in [6].
	The <description> element is of string type and does not have any		The <description> element is of string type and does not have any
	attributes.		attributes.
	3.15 <event-packages> element		3.15 <event-packages> element
	The <event-packages> element lists the event packages [12] supported		The <event-packages> element lists the event packages [13] supported
	by a device.		by a device.
	<event-packages> element can contain any number of <event-package>		<event-packages> element can contain any number of <event-package>
	elements which can be used to describe individual event packages		elements which can be used to describe individual event packages
	supported by the device.		supported by the device.
	3.15.1 <event-package>		3.15.1 <event-package>
	The <event-package> is string type element and it is used to describe		The <event-package> is string type element and it is used to describe
	individual event package supported by the device. The <event-package>		individual event package supported by the device. The
	element can contain 'negated' attribute. This attribute is of boolean		<event-package> element can contain 'negated' attribute. This
	type. Value 'true' indicates that device supports particular event		attribute is of boolean type. Value 'true' indicates that device
	package and value 'false' indicates that device does not support		supports particular event package and value 'false' indicates that
	particular event package as defined in [6]. Default value for		device does not support particular event package as defined in [6].
	'negated' attribute is 'false'.		Default value for 'negated' attribute is 'false'.
	The values for this tag equal the event package names that are		The values for this tag equal the event package names that are
	registered by each event package as defined in [6].		registered by each event package as defined in [6].
	3.16 <priority> element		3.16 <priority> element
	The <priority> element indicates the call priorities the device is		The <priority> element indicates the call priorities the device is
	willing to handle. A value of X means that the device is willing to		willing to handle. A value of X means that the device is willing to
	take requests with priority X and higher as defined in [6].		take requests with priority X and higher as defined in [6].
	The <priority> element is of integer type does not have any		The <priority> element is of integer type does not have any
	attributes.		attributes.
	3.17 <methods> element		3.17 <methods> element
	The <methods> element indicates the SIP methods supported by this UA.		The <methods> element indicates the SIP methods supported by this UA.
	In this case, "supported" means that the UA can receive requests with		In this case, "supported" means that the UA can receive requests with
	this method. In that sense, it has the same connotation as the Allow		this method. In that sense, it has the same connotation as the Allow
	header field as defined in [6].		header field as defined in [6].
	<methods> element can contain any number of <method> elements which		<methods> element can contain any number of <method> elements which
	can be used to describe individual methods supported by the device.		can be used to describe individual methods supported by the device.
	3.17.1 <method>		3.17.1 <method>
	The <method> is string type element and it is used to describe		The <method> is string type element and it is used to describe
	individual method supported by the device. The <method> element can		individual method supported by the device. The <method> element can
	contain 'negated' attribute. This attribute is of boolean type. Value		contain 'negated' attribute. This attribute is of boolean type.
	'true' indicates that device supports particular method and value		Value 'false' indicates that device supports particular method and
	'false' indicates that device does not support particular method as		value 'true' indicates that device does not support particular method
	defined in [6]. Default value for 'negated' attribute is 'false'.		as defined in [6]. Default value for 'negated' attribute is 'false'.
	3.18 <extensions> element		3.18 <extensions> element
	The <extensions> element is a list of SIP extensions (each of which		The <extensions> element is a list of SIP extensions (each of which
	is defined by an option-tag registered with IANA) that are understood		is defined by an option-tag registered with IANA) that are understood
	by the UA. Understood, in this context, means that the option tag		by the UA. Understood, in this context, means that the option tag
	would be included in a Supported header field in a request as defined		would be included in a Supported header field in a request as defined
	in [6].		in [6].
	<extensions> element can contain any number of <extension> elements		<extensions> element can contain any number of <extension> elements
	which can be used to describe individual extensions supported by the		which can be used to describe individual extensions supported by the
	device.		device.
	3.18.1 <extension>		3.18.1 <extension>
	The <extension> is string type element and it is used to describe		The <extension> is string type element and it is used to describe
	individual extension supported by the device. The <extension> element		individual extension supported by the device. The <extension>
	can contain 'negated' attribute. This attribute is of boolean type.		element can contain 'negated' attribute. This attribute is of
	Value 'true' indicates that device supports particular extension and		boolean type. Value 'false' indicates that device supports
	value 'false' indicates that device does not support particular		particular extension and value 'true' indicates that device does not
	extension as defined in [6]. Default value for 'negated' attribute is		support particular extension as defined in [6]. Default value for
	'false'.		'negated' attribute is 'false'.
	3.19 <schemes> element		3.19 <schemes> element
	The <schemes> element provides the set of URI schemes that are		The <schemes> element provides the set of URI schemes that are
	supported by a UA. Supported implies, for example, that the UA would		supported by a UA. Supported implies, for example, that the UA would
	know how to handle a URI of that scheme in the Contact header field		know how to handle a URI of that scheme in the Contact header field
	of a redirect response as defined in [6].		of a redirect response as defined in [6].
	<schemes> element can contain any number of <scheme> elements which		<schemes> element can contain any number of <scheme> elements which
	can be used to describe individual schemes supported by the device.		can be used to describe individual schemes supported by the device.
	3.19.1 <scheme>		3.19.1 <scheme>
	The <scheme> is string type element and it is used to describe		The <scheme> is string type element and it is used to describe
	individual scheme supported by the device. The <scheme> element can		individual scheme supported by the device. The <scheme> element can
	contain 'negated' attribute. This attribute is of boolean type. Value		contain 'negated' attribute. This attribute is of boolean type.
	'true' indicates that device supports particular scheme and value		Value 'false' indicates that device supports particular scheme and
	'false' indicates that device does not support particular scheme as		value 'true' indicates that device does not support particular scheme
	defined in [6]. Default value for 'negated' attribute is 'false'.		as defined in [6]. Default value for 'negated' attribute is 'false'.
	3.20 <actor> element		3.20 <actor> element
	The <actor> element indicates the type of entity that is available at		The <actor> element indicates the type of entity that is available at
	this URI as defined in [6].		this URI as defined in [6].
	The <actor> element is of string type and does not have any		The <actor> element is of string type and does not have any
	attributes. Possible values include:		attributes. Possible values include:
	o principal: The device provides communication with the principal		o principal: The device provides communication with the principal
	that is associated with the device. Often this will be a specific		that is associated with the device. Often this will be a specific
	human being, but it can be an automata (for example, when calling		human being, but it can be an automata (for example, when calling
	a voice portal).		a voice portal).
	o attendant: The device provides communication with an automaton or		o attendant: The device provides communication with an automaton or
	person that will act as an intermediary in contacting the		person that will act as an intermediary in contacting the
	principal associated with the device, or a substitute.		principal associated with the device, or a substitute.
	o msg-taker: The device provides communication with an automaton or		o msg-taker: The device provides communication with an automaton or
	person that will take messages and deliver them to the principal.		person that will take messages and deliver them to the principal.
	o information: The device provides communication with an automaton		o information: The device provides communication with an automaton
	or person that will provide information about the principal.		or person that will provide information about the principal.
	3.21 <is-focus> element		3.21 <is-focus> element
	The <is-focus> element indicates that the UA is a conference server,		The <is-focus> element indicates that the UA is a conference server,
	also known as a focus, and will mix together the media for all calls		also known as a focus, and will mix together the media for all calls
	to the same URI as defined in [6].		to the same URI as defined in [6].
	The <is-focus> element is of boolean type and does not have any		The <is-focus> element is of boolean type and does not have any
	attributes.		attributes.
	3.22 <languages> element		3.22 <languages> element
	The <languages> element indicates Ability to display particular human		The <languages> element indicates Ability to display particular human
	languages as as defined in [8].		languages as as defined in [8].
	<languages> element can contain any number of <language> elements		<languages> element can contain any number of <language> elements
	which can be used to describe individual languages supported by the		which can be used to describe individual languages supported by the
	device.		device.
	3.22.1 <language>		3.22.1 <language>
	The <language> is string type element and it is used to describe		The <language> is string type element and it is used to describe
	individual language supported by the device. The <language> element		individual language supported by the device. The <language> element
	can contain 'negated' attribute. This attribute is of boolean type.		can contain 'negated' attribute. This attribute is of boolean type.
	Value 'true' indicates that device supports particular language and		Value 'false' indicates that device supports particular language and
	value 'false' indicates that device does not support particular		value 'true' indicates that device does not support particular
	language as defined in [6]. Default value for 'negated' attribute is		language as defined in [6]. Default value for 'negated' attribute is
	'false'.
	3.23 Extension elements
	This section defines how extension features present in "Indicating
	User Agent Capabilities in the Session Initiation Protocol (SIP)"
	[6] can be used in this extension.
	3.23.1 <string> element
	<string> element can be used to represent string type feature tags.
	This element MUST NOT be used to represent standard tags discussed in
	this document, for example to represent <language> tags. <string>
	element has one mandatory attribute called 'name'. This attribute is
	string type and it MUST contain the name of the feature tag. <string>
	has optional attribute 'negated' which is boolean type attribute.
	Value 'false' indicates that feature tag is supported and value
	'true' indicates that feature tag is not supported. Default value is
	'false'.
	3.23.2 <token> element
	<token> element can be used to represent token type feature tags.
	This element MUST NOT be used to represent standard tags discussed in
	this document, for example to represent <language> tags. <token>
	element has one mandatory attribute called 'name'. This attribute is
	string type and it MUST contain the name of the feature tag. <string>
	has optional attribute 'negated' which is boolean type attribute.
	Value 'false' indicates that feature tag is supported and value
	'true' indicates that feature tag is not supported. Default value is
	'false'.		'false'.
	3.23.3 <boolean> element		4. Publishing and using 'prescaps' elements
	<boolean> element can be used to represent boolean type feature tags.
	This element MUST NOT be used to represent standard tags discussed in
	this document, for example to represent <is-focus> tag. <boolean>
	element has one mandatory attribute called 'name'. This attribute is
	string type and it MUST contain the name of the feature tag.
	<boolean> can have two values: value 'true' indicates that feature
	tag is supported and value 'false' indicates that feature tag is not
	supported.
	3.23.4 <numeric> element
	<numeric> element can be used to represent numeric type feature tags.
	This element MUST NOT be used to represent standard tags discussed in
	this document, for example to represent <priority> tag. <numeric>
	element has one mandatory attribute called 'name'. This attribute is
	string type and it MUST contain the name of the feature tag.
	<numeric> has optional attribute 'negated' which is boolean type
	attribute. Value 'false' indicates that feature tag is supported and
	value 'true' indicates that feature tag is not supported. Default
	value is 'false'.
	4. Publishing and using 'prescaps' elements
	In [6] it is recommended that a UA provide complete information in		In "Indicating User Agent Capabilities in the Session Initiation
	its contact predicate. However, it may be that presentity is not		Protocol (SIP)" [6] it is recommended that a UA provides complete
	willing to publish such presence information which would be		information in its contact predicate. However, it may be that
	consistent with actual device capabilities (e.g. presentity may not		presentity is not willing to publish presence information which would
	want to indicate that he/she supports voice when the device actually		be consistent with actual device capabilities (e.g. presentity may
	is able to support it). Also authorization rules or policies in		not want to indicate that he/she supports voice when the device
	presence server may limit or modify published presence information in		actually is able to support it). Also authorization rules or
	a way that all published presence information may not end up to all		policies in presence server may limit or modify the published
	possible watchers.		presence information in a way that all published presence information
			may not end up to all possible watchers.
	It is RECOMMENTED that Presence User Agent (PUA) using this extension		It is RECOMMENTED that Presence User Agent (PUA) using this extension
	provider as complete presence information as it can. However, it is		provides as complete presence information as it can. However, it is
	not mandated that this presence information should be consistent with		not mandated that this presence information should be consistent with
	actual device capabilities. Also, watchers SHOULD NOT expect that		actual device capabilities. Also, watchers should not expect that
	presence information represented by this extension fully represents		presence information represented by this extension fully represents
	actual presentity's device capabilities.		actual presentity's device capabilities.
	5. Generating SIP request based on 'prescaps' extension		5. Using extension with PIDF document format
	UA receiving PIDF documents with 'prescaps' extension may wish to
	generate SIP request which would route to UA having capabilities
	described by 'prescaps' extension. UA MAY add Accept-Contact: header
	based on 'prescaps' extension elements. However, as discussed in
	Section 4 device capabilities described by this extension may not be
	consistent what UA has indicated in its registration. Due to this
	request may not route to correct UA.
	6. Using extension with PIDF document format
	This section presents guidelines how extension can be used with PIDF
	document format.
	PIDF format allows use of extension XML namespaces inside <presence>,		PIDF format allows use of extension XML namespaces inside <presence>,
	<tuple>, and <status> elements. <presence> element is intended to		<tuple>, and <status> elements. <presence> element is intended to
	describe presentity as a whole. 'Prescaps' extension is related to		describe presentity as a whole. PIDF extension namespace defined in
	contact address defined by PIDF to which this extension is applied		this document relates to contact address defined by PIDF <contact>
	to. These contact addresses can only appear inside <tuple> elements.		element to which this extension is applied to. These contact
	The use of this extension in <presence> element level is NOT		addresses can only appear inside <tuple> elements as defined in the
	RECOMMENDED for this purpose.		PIDF [4]. PIDF extension namespace defined in this document SHOULD
			be placed inside <status> element. Root element <prescaps> MUST NOT
	'Prescaps' extension elements SHOULD be placed inside <status>		appear more than once inside a single <tuple> element but MAY appear
	element. Root element <prescaps> MUST NOT appear more than once		multiple times in PIDF document format inside different <tuple>
	inside a single <tuple> element but can appear multiple times in		elements.
	PIDF document format inside different <tuple> elements.
	6.1 Contact URI		5.1 Contact URI
	"Indicating User Agent Capabilities in the Session Initiation		"Indicating User Agent Capabilities in the Session Initiation
	Protocol (SIP)" [6] has restrictions what kind of URIs can be used		Protocol (SIP)" [6] has restrictions what kind of URIs can be used
	with callee capabilities. As Address of Record of the presentity		with callee capabilities. As Address of Record of the presentity
	represents the union of all presentity's device capabilities it is		represents the union of all presentity's device capabilities it is
	RECOMMENTED that contact URI in <contact> element used with this		RECOMMENTED that contact URI in <contact> element used with this
	specifications SHOULD be Address of Record of the presentity.		specifications SHOULD be Address of Record of the presentity.
	7. Examples		6. Examples
			6.1 Example
	This section presents examples how this extension can be used with
	base PIDF document format.
	7.1 Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:ext="urn:ietf:params:xml:ns:simple-prescaps-ext		xmlns:ext="urn:ietf:params:xml:ns:simple-prescaps-ext
	entity="pres:someone@example.com">		entity="pres:someone@example.com">
	<tuple id="joi9877866786ua9">		<tuple id="joi9877866786ua9">
	<status>		<status>
	<basic>open</basic>		<basic>open</basic>
	<ext:prescaps>		<ext:prescaps>
	<ext:video negated="false"/>		<ext:video>true</ext:video>
	<ext:audio negated="false">		<ext:audio>true</ext:video>
	<ext:type>audio/gsm</ext:type>		<ext:text>false</ext:text>
	<ext:type>audio/amr-wb</ext:type>		<ext:mobile>true</ext:mobile>
	</ext:audio>		<ext:methods>
	<ext:text negated="true"/>		<ext:method>INVITE</ext:method>
	<ext:mobile>true</ext:mobile>		<ext:method>MESSAGE</ext:method>
	<ext:methods>		<ext:method>ACK</ext:method>
	<ext:method>INVITE</ext:method>		<ext:method>BYE</ext:method>
	<ext:method>MESSAGE</ext:method>		<ext:method>CANCEL</ext:method>
	<ext:method>ACK</ext:method>		<ext:method negated="true">REFER</ext:method>
	<ext:method>BYE</ext:method>		</ext:methods>
	<ext:method>CANCEL</ext:method>		</ext:prescaps>
	<ext:method negated="true">REFER</ext:method>		</status>
	</ext:methods>		<contact>sip:someone@example.com</contact>
	<ext:string name="myString" negated="false">myvalue		</tuple>
	</ext:string>
	</ext:prescaps>
	</status>
	<contact>sip:someone@example.com</contact>
	</tuple>
	</presence>		</presence>
	8. XML schema definitions		7. XML schema definitions
	This section gives the XML Schema Definition for the extension		This section gives the XML schema definition for the extension
	defined in this document which can be used in the context of		defined in this document.
	"application/cpim-pidf+xml" content type.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:simple-prescaps-ext"		targetNamespace="urn:ietf:params:xml:ns:simple-prescaps-ext"
	xmlns:tns="urn:ietf:params:xml:ns:simple-prescaps-ext"		xmlns:tns="urn:ietf:params:xml:ns:simple-prescaps-ext"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<!-- This import brings in the XML language		<!-- This import brings in the XML language
	attribute xml:lang-->		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:element name="prescaps" type="tns:prescaps"/>
	<xs:complexType name="prescaps">
	<xs:sequence>
	<xs:element name="audio" type="tns:audio" minOccurs="0"/>
	<xs:element name="application" type="tns:application"
	minOccurs="0"/>
	<xs:element name="data" type="tns:data" minOccurs="0"/>
	<xs:element name="control" type="tns:control"
	minOccurs="0"/>
	<xs:element name="video" type="tns:video" minOccurs="0"/>
	<xs:element name="text" type="tns:text" minOccurs="0"/>
	<xs:element name="automata" type="tns:automata"
	minOccurs="0"/>
	<xs:element name="class" type="tns:class" minOccurs="0"/>
	<xs:element name="duplex" type="tns:duplex" minOccurs="0"/>
	<xs:element name="mobility" type="tns:mobility"
	minOccurs="0"/>
	<xs:element name="description" type="tns:description"
	minOccurs="0"/>
	<xs:element name="event-packages" type="tns:event-packages"
	minOccurs="0"/>
	<xs:element name="priority" type="tns:priority"
	minOccurs="0"/>
	<xs:element name="methods" type="tns:methods"
	minOccurs="0"/>
	<xs:element name="extensions" type="tns:extensions"
	minOccurs="0"/>
	<xs:element name="schemes" type="tns:schemes"
	minOccurs="0"/>
	<xs:element name="actor" type="tns:actor" minOccurs="0"
	maxOccurs="4"/>
	<xs:element name="is-focus" type="tns:is-focus"
	minOccurs="0"/>
	<xs:element name="languages" type="tns:languages"
	minOccurs="0"
	maxOccurs="unbounded"/>
	<xs:element name="string" type="tns:string" minOccurs="0"
	maxOccurs="unbounded"/>
	<xs:element name="token" type="tns:token" minOccurs="0"
	maxOccurs="unbounded"/>
	<xs:element name="boolean" type="tns:boolean" minOccurs="0"
	maxOccurs="unbounded"/>
	<xs:element name="numeric" type="tns:numeric" minOccurs="0"
	maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="audio">
	<xs:sequence>
	<xs:element name="type" type="tns:type" minOccurs="0"
	maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="negated" type="xs:boolean"
	default="false"/>
	</xs:complexType>
	<xs:complexType name="application">
	<xs:sequence>
	<xs:element name="type" type="tns:type" minOccurs="0"
	maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="negated" type="xs:boolean"
	default="false"/>
	</xs:complexType>
	<xs:complexType name="data">
	<xs:sequence>
	<xs:element name="type" type="tns:type" minOccurs="0"
	maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="negated" type="xs:boolean"
	default="false"/>
	</xs:complexType>
	<xs:complexType name="control">		<xs:element name="prescaps" type="tns:prescaps"/>
	<xs:sequence>		<xs:complexType name="prescaps">
	<xs:element name="type" type="tns:type" minOccurs="0"		<xs:sequence>
	maxOccurs="unbounded"/>		<xs:element name="audio" type="tns:audio" minOccurs="0"/>
	</xs:sequence>		<xs:element name="application" type="tns:application"
	<xs:attribute name="negated" type="xs:boolean"		minOccurs="0"/>
	default="false"/>		<xs:element name="data" type="tns:data" minOccurs="0"/>
	</xs:complexType>		<xs:element name="control" type="tns:control"
			minOccurs="0"/>
			<xs:element name="video" type="tns:video" minOccurs="0"/>
			<xs:element name="text" type="tns:text" minOccurs="0"/>
			<xs:element name="automata" type="tns:automata"
			minOccurs="0"/>
			<xs:element name="class" type="tns:class" minOccurs="0"/>
			<xs:element name="duplex" type="tns:duplex" minOccurs="0"/>
			<xs:element name="mobility" type="tns:mobility"
			minOccurs="0"/>
			<xs:element name="description" type="tns:description"
			minOccurs="0"/>
			<xs:element name="event-packages" type="tns:event-packages"
			minOccurs="0"/>
			<xs:element name="priority" type="tns:priority"
			minOccurs="0"/>
			<xs:element name="methods" type="tns:methods"
			minOccurs="0"/>
			<xs:element name="extensions" type="tns:extensions"
			minOccurs="0"/>
			<xs:element name="schemes" type="tns:schemes"
			minOccurs="0"/>
			<xs:element name="actor" type="tns:actor" minOccurs="0"
			maxOccurs="4"/>
			<xs:element name="is-focus" type="tns:is-focus"
			minOccurs="0"/>
			<xs:element name="languages" type="tns:languages"
			minOccurs="0"
			maxOccurs="unbounded"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:complexType>
	<xs:complexType name="video">		<xs:complexType name="audio">
	<xs:sequence>		<xs:restriction base="xs:boolean"/>
	<xs:element name="type" type="tns:type" minOccurs="0"		</xs:complexType>
	maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="negated" type="xs:boolean"
	default="false"/>
	</xs:complexType>
	<xs:complexType name="text">		<xs:complexType name="application">
	<xs:sequence>		<xs:restriction base="xs:boolean"/>
	<xs:element name="type" type="tns:type" minOccurs="0"		</xs:complexType>
	maxOccurs="unbounded"/>		<xs:complexType name="data">
	</xs:sequence>		<xs:restriction base="xs:boolean"/>
	<xs:attribute name="negated" type="xs:boolean"		</xs:complexType>
	default="false"/>
	</xs:complexType>
	<xs:simpleType name="type">		<xs:complexType name="control">
	<xs:restriction base="xs:string"/>		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>		</xs:complexType>
	<xs:simpleType name="automata">		<xs:complexType name="video">
	<xs:restriction base="xs:boolean"/>		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>		</xs:complexType>
	<xs:simpleType name="class">		<xs:complexType name="text">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:boolean"/>
	<xs:enumeration value="personal"/>		</xs:complexType>
	<xs:enumeration value="business"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="duplex">		<xs:simpleType name="type">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string"/>
	<xs:enumeration value="full"/>		</xs:simpleType>
	<xs:enumeration value="half"/>
	<xs:enumeration value="receive-only"/>
	<xs:enumeration value="send-only"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="mobility">		<xs:simpleType name="automata">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:boolean"/>
	<xs:enumeration value="fixed"/>		</xs:simpleType>
	<xs:enumeration value="mobile"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="description">		<xs:simpleType name="class">
	<xs:restriction base="xs:string"/>		<xs:restriction base="xs:string">
	</xs:simpleType>		<xs:enumeration value="personal"/>
			<xs:enumeration value="business"/>
			</xs:restriction>
			</xs:simpleType>
	<xs:complexType name="event-packages">		<xs:simpleType name="duplex">
	<xs:sequence>		<xs:restriction base="xs:string">
	<xs:element name="event-package" type="tns:event-package"		<xs:enumeration value="full"/>
	minOccurs="0" maxOccurs="unbounded"/>		<xs:enumeration value="half"/>
	</xs:sequence>		<xs:enumeration value="receive-only"/>
	</xs:complexType>		<xs:enumeration value="send-only"/>
			</xs:restriction>
			</xs:simpleType>
	<xs:complexType name="event-package">		<xs:simpleType name="mobility">
	<xs:simpleContent>		<xs:restriction base="xs:string">
	<xs:extension base="xs:string">		<xs:enumeration value="fixed"/>
	<xs:attribute name="negated" type="xs:boolean"/>		<xs:enumeration value="mobile"/>
	</xs:extension>		</xs:restriction>
	</xs:simpleContent>		</xs:simpleType>
	</xs:complexType>
	<xs:simpleType name="priority">		<xs:simpleType name="description">
	<xs:restriction base="xs:integer"/>		<xs:restriction base="xs:string"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:complexType name="methods">		<xs:complexType name="event-packages">
	<xs:sequence>		<xs:sequence>
	<xs:element name="method" type="tns:method"		<xs:element name="event-package" type="tns:event-package"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="method">		<xs:complexType name="event-package">
	<xs:simpleContent>		<xs:simpleContent>
	<xs:extension base="xs:string">		<xs:extension base="xs:string">
	<xs:attribute name="negated" type="xs:boolean"/>		<xs:attribute name="negated" type="xs:boolean"/>
	</xs:extension>		</xs:extension>
	</xs:simpleContent>		</xs:simpleContent>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="extensions">		<xs:simpleType name="priority">
	<xs:sequence>		<xs:restriction base="xs:integer"/>
	<xs:element name="extension" type="tns:extension"		</xs:simpleType>
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="extension">		<xs:complexType name="methods">
	<xs:simpleContent>		<xs:sequence>
	<xs:extension base="xs:string">		<xs:element name="method" type="tns:method"
	<xs:attribute name="negated" type="xs:boolean"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:extension>		</xs:sequence>
	</xs:simpleContent>		</xs:complexType>
	</xs:complexType>
	<xs:complexType name="schemes">
	<xs:sequence>
	<xs:element name="scheme" type="tns:scheme"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="scheme">		<xs:complexType name="method">
	<xs:simpleContent>		<xs:simpleContent>
	<xs:extension base="xs:string">		<xs:extension base="xs:string">
	<xs:attribute name="negated" type="xs:boolean"/>		<xs:attribute name="negated" type="xs:boolean"/>
	</xs:extension>		</xs:extension>
	</xs:simpleContent>		</xs:simpleContent>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="actor">		<xs:complexType name="extensions">
	<xs:restriction base="xs:string">		<xs:sequence>
	<xs:enumeration value="principal"/>		<xs:element name="extension" type="tns:extension"
	<xs:enumeration value="attendant"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:enumeration value="msg-taker"/>		</xs:sequence>
	<xs:enumeration value="information"/>		</xs:complexType>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="is-focus">		<xs:complexType name="extension">
	<xs:restriction base="xs:boolean"/>		<xs:simpleContent>
	</xs:simpleType>		<xs:extension base="xs:string">
			<xs:attribute name="negated" type="xs:boolean"/>
	<xs:complexType name="languages">		</xs:extension>
	<xs:sequence>		</xs:simpleContent>
	<xs:element name="language" type="tns:language"		</xs:complexType>
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="language">		<xs:complexType name="schemes">
	<xs:simpleContent>		<xs:sequence>
	<xs:extension base="xs:string">		<xs:element name="scheme" type="tns:scheme"
	<xs:attribute name="negated" type="xs:boolean"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:extension>		</xs:sequence>
	</xs:simpleContent>		</xs:complexType>
	</xs:complexType>
	<!-- Extension tag definitions -->		<xs:complexType name="scheme">
			<xs:simpleContent>
			<xs:extension base="xs:string">
			<xs:attribute name="negated" type="xs:boolean"/>
			</xs:extension>
			</xs:simpleContent>
			</xs:complexType>
	<xs:complexType name="token">		<xs:simpleType name="actor">
	<xs:simpleContent>		<xs:restriction base="xs:string">
	<xs:extension base="xs:string">		<xs:enumeration value="principal"/>
	<xs:attribute name="name" type="xs:string"		<xs:enumeration value="attendant"/>
	use="required"/>		<xs:enumeration value="msg-taker"/>
	<xs:attribute name="negated" type="xs:boolean"		<xs:enumeration value="information"/>
	default="false"/>		</xs:restriction>
	</xs:extension>		</xs:simpleType>
	</xs:simpleContent>
	</xs:complexType>
	<xs:complexType name="string">		<xs:simpleType name="is-focus">
	<xs:simpleContent>		<xs:restriction base="xs:boolean"/>
	<xs:extension base="xs:string">		</xs:simpleType>
	<xs:attribute name="name" type="xs:string"
	use="required"/>
	<xs:attribute name="negated" type="xs:boolean"
	default="false"/>
	</xs:extension>
	</xs:simpleContent>
	</xs:complexType>
	<xs:complexType name="boolean">		<xs:complexType name="languages">
	<xs:simpleContent>		<xs:sequence>
	<xs:extension base="xs:boolean">		<xs:element name="language" type="tns:language"
	<xs:attribute name="name" type="xs:string"		minOccurs="0" maxOccurs="unbounded"/>
	use="required"/>		</xs:sequence>
	</xs:extension>		</xs:complexType>
	</xs:simpleContent>
	</xs:complexType>
	<xs:complexType name="numeric">		<xs:complexType name="language">
	<xs:simpleContent>		<xs:simpleContent>
	<xs:extension base="xs:integer">		<xs:extension base="xs:string">
	<xs:attribute name="name" type="xs:string"		<xs:attribute name="negated" type="xs:boolean"/>
	use="required"/>		</xs:extension>
	<xs:attribute name="negated" type="xs:boolean"		</xs:simpleContent>
	default="false"/>		</xs:complexType>
	</xs:extension>
	</xs:simpleContent>
	</xs:complexType>
	</xs:schema>		</xs:schema>
	Figure 2		Figure 2
	9. IANA Considerations		8. IANA Considerations
	This memo calls for IANA to register a new XML namespace URN as		This memo calls for IANA to register a new XML namespace URN as
	defined in [15]		defined in [9]
	9.1 URN sub-namespace registration for		8.1 URN sub-namespace registration for
	'urn:ietf:params:xml:ns:simple-prescaps-ext'		'urn:ietf:params:xml:ns:simple-prescaps-ext'
	URI:		URI:
	urn:ietf:params:xml:ns:simple-prescaps-ext		urn:ietf:params:xml:ns:simple-prescaps-ext
	Description:		Description:
	This is the XML namespace for XML elements defined by [[[RFCXXXX]]]		This is the XML namespace for XML elements defined by [[[RFCXXXX]]]
	to describe communication means extension for CPIM-PIDF presence		to describe user agent capability extension for PIDF presence
	document format in application/cpim-pidf+xml content type.		document format in application/pidf+xml content type.
	Registrant Contact:		Registrant Contact:
	IETF, SIMPLE working group, <simple@ietf.org>		IETF, SIMPLE working group, <simple@ietf.org>
	Mikko Lonnfors, <mikko.lonnfors@nokia.com>		Mikko Lonnfors, <mikko.lonnfors@nokia.com>
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml		<html xmlns="http://www.w3.org/1999/xhtml
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	content="text/html;charset=iso-8859-1"/>		content="text/html;charset=iso-8859-1"/>
	<title>PIDF User Agent capability extension</title>		<title>User agent capability extension to the Presence
			information data format (PIDF)</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for PIDF User Agent capability extension</h1>		<h1>Namespace for PIDF user agent capability extension</h1>
	<h2>application/cpim-pidf+xml</h2>		<h2>urn:ietf:params:xml:ns:simple-prescaps-ext</h2>
	<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>		<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	10. Security Considerations		9. Security Considerations
	All security considerations specified in CPIM [5] and in PIDF [4]		All security considerations specified in CPIM [5] and in PIDF [4]
	documents apply also to this document. For clarity some of the		documents apply to this document. Compared to PIDF [4] this presence
	security considerations are repeated here.		document format may reveal additional information about user's device
			capabilities.
	Because presence is very privacy-sensitive information, the transport		Because presence is very privacy-sensitive information, the transport
	protocol for the presence information SHOULD have capabilities to		protocol for the presence information SHOULD have capabilities to
	protect protocol messages from possible threats, such as		protect protocol messages from possible threats, such as
	eavesdropping, corruption, tamper and replay attacks. The protocols		eavesdropping, corruption, tamper and replay attacks. The protocols
	SHOULD be able to use security mechanisms which are standardized or		SHOULD be able to use security mechanisms which are standardized or
	being standardized in IETF. However, it depends on the actual		being standardized in IETF. However, it depends on the actual
	transport protocols which security mechanisms should be used, and it		transport protocols which security mechanisms should be used, and it
	is beyond the scope of this memo.		is beyond the scope of this memo.
	11. Acknowledgements		10. Acknowledgments
	Authors of this document would like to thank following people for		Authors of this document would like to thank following people for
	their contributions and valuable comments: Paul Kyzivat, Jonathan		their contributions and valuable comments: Paul Kyzivat, Jonathan
	Rosenberg, Markus Isomaki, Eva Leppanen, and Hisham Khartabil.		Rosenberg, Markus Isomaki, Eva Leppanen, and Hisham Khartabil.
	Normative references		11. References
			11.1 Normative references
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and		[2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
	Instant Messaging", RFC 2778, February 2000.		Instant Messaging", RFC 2778, February 2000.
	[3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant		[3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant
	Messaging / Presence Protocol Requirements", RFC 2779, February		Messaging / Presence Protocol Requirements", RFC 2779, February
	2000.		2000.
	skipping to change at page 24, line 44 ¶		skipping to change at page 20, line 6 ¶
	[6] Schulzrinne, H., Rosenberg, J. and P. Kyzivat, "Indicating User		[6] Schulzrinne, H., Rosenberg, J. and P. Kyzivat, "Indicating User
	Agent Capabilities in the Session Initiation Protocol (SIP)",		Agent Capabilities in the Session Initiation Protocol (SIP)",
	draft-ietf-sip-callee-caps-03 (work in progress), December 2003.		draft-ietf-sip-callee-caps-03 (work in progress), December 2003.
	[7] Klyne, G., "MIME Content Types in Media Feature Expressions",		[7] Klyne, G., "MIME Content Types in Media Feature Expressions",
	RFC 2913, September 2000.		RFC 2913, September 2000.
	[8] Hoffman, P., "Registration of Charset and Languages Media		[8] Hoffman, P., "Registration of Charset and Languages Media
	Features Tags", RFC 2987, November 2000.		Features Tags", RFC 2987, November 2000.
	Informative references		[9] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
	[9] Schulzrinne, H., Rosenberg, J. and P. Kyzivat, "Caller		11.2 Informative references
			[10] Schulzrinne, H., Rosenberg, J. and P. Kyzivat, "Caller
	Preferences for the Session Initiation Protocol (SIP)",		Preferences for the Session Initiation Protocol (SIP)",
	draft-ietf-sip-callerprefs-10 (work in progress), October 2003.		draft-ietf-sip-callerprefs-10 (work in progress), October 2003.
	[10] Peterson, J., "Common Profile for Instant Messaging (CPIM)",		[11] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
	draft-ietf-impp-im-04 (work in progress), August 2003.		draft-ietf-impp-im-04 (work in progress), August 2003.
	[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[12] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event		[13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
	Notification", RFC 3265, June 2002.		Notification", RFC 3265, June 2002.
	[13] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions		[14] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
	for Presence", draft-ietf-simple-presence-10.txt (work in		for Presence", draft-ietf-simple-presence-10.txt (work in
	progress), May 2002.		progress), May 2002.
	[14] Handley, M. and V. Jacobson, "SDP: Session Description		[15] Handley, M. and V. Jacobson, "SDP: Session Description
	Protocol", RFC 2327, April 1998.		Protocol", RFC 2327, April 1998.
	[15] Mealling, M., "The IETF XML Registry",
	draft-mealling-iana-xmlns-registry-05 (work in progress), June
	2002.
	[16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) part two: Media Types", RFC 2046, November		Extensions (MIME) part two: Media Types", RFC 2046, November
	1996.		1996.
	[17] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[17] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) part one:Format of Internet Message Bodies",		Extensions (MIME) part one:Format of Internet Message Bodies",
	RFC 2045, November 1996.		RFC 2045, November 1996.
	[18] Alvestrand, H., "Tags for the Identification of Languages", RFC		[18] Alvestrand, H., "Tags for the Identification of Languages", RFC
	1766, March 1995.		1766, March 1995.
	[19] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag		[19] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
	Registration Procedure", RFC 2046, March 1999.		Registration Procedure", RFC 2046, March 1999.
	Authors' Addresses		Authors' Addresses
	Mikko Lonnfors		Mikko Lonnfors
	Nokia Research Center		Nokia
	Itamerenkatu 11-13 00180		Itamerenkatu 11-13 00180
	Helsinki		Helsinki
	Finland		Finland
	Phone: +358 71 8008000		Phone: +358 71 8008000
	EMail: mikko.lonnfors@nokia.com		EMail: mikko.lonnfors@nokia.com
	Krisztian Kiss		Krisztian Kiss
	Nokia		Nokia
	12278 Scripps Summit Drive		12278 Scripps Summit Drive
	San Diego		San Diego
	US		US
	Phone: +18582049141		Phone: +18582049141
	EMail: krisztian.kiss@nokia.com		EMail: krisztian.kiss@nokia.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the procedures with respect to rights in RFC documents can be
	standards-related documentation can be found in BCP-11. Copies of		found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 153 change blocks.
	716 lines changed or deleted		500 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/