< draft-ietf-simple-common-policy-caps-00.txt		draft-ietf-simple-common-policy-caps-01.txt >
	SIMPLE J. Rosenberg		SIMPLE J. Rosenberg
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: January 11, 2006 July 10, 2005		Expires: December 28, 2006 June 26, 2006
	An Extensible Markup Language (XML) Representation for Expressing Policy		An Extensible Markup Language (XML) Representation for Expressing Policy
	Capabilities		Capabilities
	draft-ietf-simple-common-policy-caps-00		draft-ietf-simple-common-policy-caps-01
	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 34 ¶		skipping to change at page 1, line 34 ¶
	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 11, 2006.		This Internet-Draft will expire on December 28, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	An important component of presence and location services is policy.		An important component of presence and location services is policy.
	Policy systems allow the presentity or location target to grant		Policy systems allow the presentity or location target to grant
	access to specific pieces of information to specific watchers or		access to specific pieces of information to specific watchers or
	requestors. These policy systems can be extremely simple, allowing a		requestors. These policy systems can be extremely simple, allowing a
	user to accept or block requests based solely on the identity of the		user to accept or block requests based solely on the identity of the
	requestor, to extremely complex, allowing for time based rules that		requestor, to extremely complex, allowing for time based rules that
	grant or deny specific pieces of information. Policy systems often		grant or deny specific pieces of information. Policy systems often
	support vendor proprietary features. To allow for interoperability		support vendor proprietary features. To allow for interoperability
	between clients which set such policies, and servers which execute		between clients which set such policies, and servers which execute
	them, it is necessary for clients to be able to determine the		them, it is necessary for clients to be able to determine the
	capabilities of the server to which it is connected. This		capabilities of the server to which it is connected. This
	specification defines an Extensible Markup Language (XML) based		specification defines an Extensible Markup Language (XML) based
	format for expressing such capabilities.		format for expressing such capabilities.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview of Operation . . . . . . . . . . . . . . . . . . . 3		3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
	4. Structure of Policy Capabilities . . . . . . . . . . . . . . 4		4. Structure of Policy Capabilities . . . . . . . . . . . . . . . 4
	5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Example Document . . . . . . . . . . . . . . . . . . . . . . 7		6. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . . 7		7. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1 Application Unique ID . . . . . . . . . . . . . . . . . . 7		7.1. Application Unique ID . . . . . . . . . . . . . . . . . . 7
	7.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7		7.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.3 Default Namespace . . . . . . . . . . . . . . . . . . . . 8		7.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 8
	7.4 MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 8		7.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.5 Validation Constraints . . . . . . . . . . . . . . . . . . 8		7.5. Validation Constraints . . . . . . . . . . . . . . . . . . 8
	7.6 Data Semantics . . . . . . . . . . . . . . . . . . . . . . 8		7.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 8
	7.7 Naming Conventions . . . . . . . . . . . . . . . . . . . . 8		7.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 8
	7.8 Resource Interdependencies . . . . . . . . . . . . . . . . 8		7.8. Resource Interdependencies . . . . . . . . . . . . . . . . 8
	7.9 Authorization Policies . . . . . . . . . . . . . . . . . . 8		7.9. Authorization Policies . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 9		9.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 9
	9.2 MIME Type Registration . . . . . . . . . . . . . . . . . . 9		9.2. MIME Type Registration . . . . . . . . . . . . . . . . . . 9
	9.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 10		9.3. URN Sub-Namespace Registrations . . . . . . . . . . . . . 10
	9.4 XML Schema Registration . . . . . . . . . . . . . . . . . 11		9.4. XML Schema Registration . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1 Normative References . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	10.2 Informative References . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . . . 14
	1. Terminology		1. Terminology
	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.
	2. Introduction		2. Introduction
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	(referred to generically as the Presentity Target (PT)) to grant		(referred to generically as the Presentity Target (PT)) to grant
	access to specific pieces of information to specific watchers or		access to specific pieces of information to specific watchers or
	requestors (referred to as a WR) [5]. These policy systems can be		requestors (referred to as a WR) [5]. These policy systems can be
	extremely simple, allowing a PT to accept or block requests based		extremely simple, allowing a PT to accept or block requests based
	solely on the identity of the WR, to extremely complex, allowing for		solely on the identity of the WR, to extremely complex, allowing for
	time based rules that grant or deny specific pieces of information.		time based rules that grant or deny specific pieces of information.
	[5] specifies a generic format for representing these policies, using		[5] specifies a generic format for representing these policies, using
	the Extensible Markup Language (XML). These policies consist of		the Extensible Markup Language (XML). These policies consist of
	conditions, actions, and transformations. That specification defines		conditions, actions, and transformations. That specification defines
	very few actual conditions, actions or transformations. Rather, it		very few actual conditions, actions or transformations. Rather, it
	leaves such definitions to actual policy systems, such as [5] for		leaves such definitions to actual policy systems, such as [12] for
	location services, and [13] for presence services.		location services, and [13] for presence services.
	In addition to the conditions, actions and transformations specificed		In addition to the conditions, actions and transformations specificed
	in the documents referenced above, policy systems often support		in the documents referenced above, policy systems often support
	vendor proprietary features. It is also anticipated that future		vendor proprietary features. It is also anticipated that future
	specifications will be continually developed that add new types of		specifications will be continually developed that add new types of
	policies. This presents an interoperability challenge. Clients may		policies. This presents an interoperability challenge. Clients may
	support policies that are not supported by the servers they are		support policies that are not supported by the servers they are
	using. This could lead to protocol failures or poor user		using. This could lead to protocol failures or poor user
	experiences.		experiences.
	skipping to change at page 3, line 51 ¶		skipping to change at page 4, line 4 ¶
	framework established in [5].		framework established in [5].
	3. Overview of Operation		3. Overview of Operation
	This specification defines an XML-based document format that allows a		This specification defines an XML-based document format that allows a
	server to represent its capabilities. When a client, acting as an		server to represent its capabilities. When a client, acting as an
	agent of a PT, starts up, it obtains this document from its policy		agent of a PT, starts up, it obtains this document from its policy
	server. This specification does not prescribe a singular means of		server. This specification does not prescribe a singular means of
	transporting such a document between the server and the client. It		transporting such a document between the server and the client. It
	is anticipated that different systems may use different techniques.		is anticipated that different systems may use different techniques.
	However, for systems that make use of the XML Configuration Access		However, for systems that make use of the XML Configuration Access
	Protocol (XCAP) [4], Section 7 defines an application usage that		Protocol (XCAP) [4], Section 7 defines an application usage that
	allows for the transfer of the document using XCAP.		allows for the transfer of the document using XCAP.
	Once the document has been obtained by the client, it can determine		Once the document has been obtained by the client, it can determine
	which actions, conditions and transformations are understood by the		which actions, conditions and transformations are understood by the
	server. This set is matched against those supported by the client.		server. This set is matched against those supported by the client.
	Those actions, conditions and transformations supported by the		Those actions, conditions and transformations supported by the
	client, but not by the server, can be "greyed out" from a user		client, but not by the server, can be "greyed out" from a user
	interface, for example.		interface, for example.
	It is anticipated that the capabilities of the server can change over		It is anticipated that the capabilities of the server can change over
	time. As a result, it is RECOMMENDED that clients obtain a fresh		time. As a result, it is RECOMMENDED that clients obtain a fresh
	copy of the capabilities document each time they start.		copy of the capabilities document each time they start.
	4. Structure of Policy Capabilities		4. Structure of Policy Capabilities
	A policy capabilities document is an XML [6] document that MUST be		A policy capabilities document is an XML [6] document that MUST be
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 40 ¶
	<transformations>		<transformations>
	<vpp:min-security/>		<vpp:min-security/>
	</transformations>		</transformations>
	</policy-capabilities>		</policy-capabilities>
	7. Usage with XCAP		7. Usage with XCAP
	The following section defines the details necessary for clients to		The following section defines the details necessary for clients to
	read supported permissions documents from a server using XCAP.		read supported permissions documents from a server using XCAP.
	7.1 Application Unique ID		7.1. Application Unique ID
	XCAP requires application usages to define an application unique ID		XCAP requires application usages to define an application unique ID
	(AUID) in either the IETF tree or a vendor tree. This specification		(AUID) in either the IETF tree or a vendor tree. This specification
	defines the "policy-capabilities" AUID within the IETF tree, via the		defines the "policy-capabilities" AUID within the IETF tree, via the
	IANA registration in Section 9.		IANA registration in Section 9.
	7.2 XML Schema		7.2. XML Schema
	The schema is defined in Section 5.		The schema is defined in Section 5.
	7.3 Default Namespace		7.3. Default Namespace
	The default namespace used in evaluating a URI is		The default namespace used in evaluating a URI is
	urn:ietf:params:xml:ns:policy-capabilities.		urn:ietf:params:xml:ns:policy-capabilities.
	7.4 MIME Type		7.4. MIME Type
	The MIME type for this document is "application/policy-caps+xml".		The MIME type for this document is "application/policy-caps+xml".
	7.5 Validation Constraints		7.5. Validation Constraints
	This specification does not introduce any additional validation		This specification does not introduce any additional validation
	constraints beyond those defined in the schema.		constraints beyond those defined in the schema.
	7.6 Data Semantics		7.6. Data Semantics
	Semantics for the document content are provided in Section 4.		Semantics for the document content are provided in Section 4.
	7.7 Naming Conventions		7.7. Naming Conventions
	When a client starts, it can fetch the capabilities of the server in		When a client starts, it can fetch the capabilities of the server in
	one of two places. If the server capabilities differ on a user by		one of two places. If the server capabilities differ on a user by
	user basis, the capabilities for user foo can be found in the		user basis, the capabilities for user foo can be found in the
	document with filename "cap.xml" in the user's home directory for		document with filename "cap.xml" in the user's home directory for
	this application usage. A client SHOULD check this file first. If		this application usage. A client SHOULD check this file first. If
	this document doesn't exist, the client should next check for the		this document doesn't exist, the client should next check for the
	system wide permissions by reading the document with filename		system wide permissions by reading the document with filename
	"cap.xml" in the global directory for this application usage.		"cap.xml" in the global directory for this application usage.
	7.8 Resource Interdependencies		7.8. Resource Interdependencies
	Policy capability documents are usually either created automatically		Policy capability documents are usually either created automatically
	by the server, or modified by administrator to reflect the features		by the server, or modified by administrator to reflect the features
	of a server. For those users that have access to the full		of a server. For those users that have access to the full
	capabilities of the server, a change in the server-wide capabilities,		capabilities of the server, a change in the server-wide capabilities,
	expressed in the "cap.xml" file in the global directory, MUST be		expressed in the "cap.xml" file in the global directory, MUST be
	reflected in any "cap.xml" documents in user's home directories.		reflected in any "cap.xml" documents in user's home directories.
	7.9 Authorization Policies		7.9. Authorization Policies
	This application usage does not use the default XCAP authorization		This application usage does not use the default XCAP authorization
	policies.		policies.
	A user cannot modify the supported permissions document, they can		A user cannot modify the supported permissions document, they can
	only read it. Write access is granted only to administrators.		only read it. Write access is granted only to administrators.
	A user can read the "cap.xml" document in the global directory, but		A user can read the "cap.xml" document in the global directory, but
	cannot modify it. Write access is granted only to administrators.		cannot modify it. Write access is granted only to administrators.
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 30 ¶
	capability elements, therefore reducing the level of service received		capability elements, therefore reducing the level of service received
	by the client. This can therefore form a type of denial-of-service		by the client. This can therefore form a type of denial-of-service
	attack. As a result, systems which transfer these documents SHOULD		attack. As a result, systems which transfer these documents SHOULD
	provide for message integrity.		provide for message integrity.
	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 XCAP Application Usage ID		9.1. XCAP Application Usage ID
	This section registers an XCAP Application Unique ID (AUID) according		This section registers an XCAP Application Unique ID (AUID) according
	to the IANA procedures defined in [4].		to the IANA procedures defined in [4].
	Name of the AUID: policy-capabilities		Name of the AUID: policy-capabilities
	Description: Policy capability documents describe the capabilities		Description: Policy capability documents describe the capabilities
	of a policy server to support different conditions, actions, and		of a policy server to support different conditions, actions, and
	transformations, as defined in [5].		transformations, as defined in [5].
	9.2 MIME Type Registration		9.2. MIME Type Registration
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 2048 [8] and guidelines in RFC		according to the procedures of RFC 2048 [8] and guidelines in RFC
	3023 [9].		3023 [9].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: policy-caps+xml		MIME subtype name: policy-caps+xml
	Mandatory parameters: none		Mandatory parameters: none
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 41 ¶
	Macintosh file type code: "TEXT"		Macintosh file type code: "TEXT"
	Personal and email address for further information: Jonathan		Personal and email address for further information: Jonathan
	Rosenberg, jdrosen@jdrosen.net		Rosenberg, jdrosen@jdrosen.net
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: The IETF.		Author/Change controller: The IETF.
	9.3 URN Sub-Namespace Registrations		9.3. URN Sub-Namespace Registrations
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	[7]		[7]
	URI: The URI for this namespace is		URI: The URI for this namespace is
	urn:ietf:params:xml:ns:policy-capabilities.		urn:ietf:params:xml:ns:policy-capabilities.
	Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),		Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
	Jonathan Rosenberg (jdrosen@jdrosen.net).		Jonathan Rosenberg (jdrosen@jdrosen.net).
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 30 ¶
	<body>		<body>
	<h1>Namespace for Policy Capabilities</h1>		<h1>Namespace for Policy Capabilities</h1>
	<h2>urn:ietf:params:xml:ns:policy-capabilities</h2>		<h2>urn:ietf:params:xml:ns:policy-capabilities</h2>
	<p>See <a href="[URL of published RFC]">RFCXXXX[[NOTE		<p>See <a href="[URL of published RFC]">RFCXXXX[[NOTE
	TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this		TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this
	specification.</a>.</p>		specification.</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.4 XML Schema Registration		9.4. XML Schema Registration
	This section registers an XML schema as per the procedures in [7].		This section registers an XML schema as per the procedures in [7].
	URI: urn:ietf:params:xml:schema:policy-capabilities		URI: urn:ietf:params:xml:schema:policy-capabilities
	Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),		Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
	Jonathan Rosenberg (jdrosen@jdrosen.net).		Jonathan Rosenberg (jdrosen@jdrosen.net).
	The XML for this schema can be found as the sole content of		The XML for this schema can be found as the sole content of
	Section 5.		Section 5.
	10. References		10. References
	10.1 Normative References		10.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] Moats, R., "URN Syntax", RFC 2141, May 1997.		[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
	[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,		[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
	August 1999.		August 1999.
	[4] Rosenberg, J., "The Extensible Markup Language (XML)		[4] Rosenberg, J., "The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-07		Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-11
	(work in progress), June 2005.		(work in progress), May 2006.
	[5] Schulzrinne, H., "A Document Format for Expressing Privacy		[5] Schulzrinne, H., "Common Policy: An XML Document Format for
	Preferences", draft-ietf-geopriv-common-policy-04 (work in		Expressing Privacy Preferences",
	progress), February 2005.		draft-ietf-geopriv-common-policy-10 (work in progress),
			May 2006.
	[6] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,		[6] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray,
	"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C		"Extensible Markup Language (XML) 1.0 (Second Edition)", World
	FirstEdition REC-xml-20001006, October 2000.		Wide Web Consortium
			FirstEdition http://www.w3.org/TR/2000/REC-xml-20001006,
			October 2000.
	[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet		[8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
	Mail Extensions (MIME) Part Four: Registration Procedures",		Mail Extensions (MIME) Part Four: Registration Procedures",
	BCP 13, RFC 2048, November 1996.		BCP 13, RFC 2048, November 1996.
	[9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",		[9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
	RFC 3023, January 2001.		RFC 3023, January 2001.
	10.2 Informative References		10.2. Informative References
	[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence		[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
	and Instant Messaging", RFC 2778, February 2000.		and Instant Messaging", RFC 2778, February 2000.
	[11] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.		[11] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
	Polk, "Geopriv Requirements", RFC 3693, February 2004.		Polk, "Geopriv Requirements", RFC 3693, February 2004.
	[12] Schulzrinne, H., "A Document Format for Expressing Privacy		[12] Schulzrinne, H., "A Document Format for Expressing Privacy
	Preferences for Location Information",		Preferences for Location Information",
	draft-ietf-geopriv-policy-05 (work in progress), November 2004.		draft-ietf-geopriv-policy-08 (work in progress), February 2006.
	[13] Rosenberg, J., "Presence Authorization Rules",		[13] Rosenberg, J., "Presence Authorization Rules",
	draft-ietf-simple-presence-rules-02 (work in progress),		draft-ietf-simple-presence-rules-07 (work in progress),
	February 2005.		June 2006.
	Author's Address		Author's Address
	Jonathan Rosenberg		Jonathan Rosenberg
	Cisco Systems		Cisco Systems
	600 Lanidex Plaza		600 Lanidex Plaza
	Parsippany, NJ 07054		Parsippany, NJ 07054
	US		US
	Phone: +1 973 952-5000		Phone: +1 973 952-5000
	skipping to change at page 14, line 41 ¶		skipping to change at page 14, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		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. 29 change blocks.
	60 lines changed or deleted		64 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/