< draft-rosenberg-simple-pres-policy-caps-01.txt		draft-rosenberg-simple-pres-policy-caps-02.txt >
	SIMPLE J. Rosenberg		SIMPLE J. Rosenberg
	Internet-Draft dynamicsoft		Internet-Draft Cisco Systems
	Expires: January 17, 2005 July 19, 2004		Expires: August 22, 2005 February 21, 2005
	An Extensible Markup Language (XML) Representation for Expressing		An Extensible Markup Language (XML) Representation for Expressing
	Presence Policy Capabilities		Presence Policy Capabilities
	draft-rosenberg-simple-pres-policy-caps-01		draft-rosenberg-simple-pres-policy-caps-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any 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 become aware will be disclosed, in accordance with
	RFC 3668.		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		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		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		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 17, 2005.		This Internet-Draft will expire on August 22, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	An important component of presence services is policy. Policy		An important component of presence services is policy. Policy
	systems allow the presentity to grant access to specific pieces of		systems allow the presentity to grant access to specific pieces of
	information to specific watchers. To allow for interoperability		information to specific watchers. 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 a set of Extensible Markup Language (XML)		specification defines a set of Extensible Markup Language (XML)
	elements for expressing presence policy capabilities.		elements for expressing presence policy capabilities.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Structure of Presence Policy Capabilities . . . . . . . . . . 3		3. Structure of Presence Policy Capabilities . . . . . . . . . . 3
	4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 4		5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7.1 URN Sub-Namespace Registrations . . . . . . . . . . . . . 5		7.1 URN Sub-Namespace Registrations . . . . . . . . . . . . . 6
	7.2 XML Schema Registration . . . . . . . . . . . . . . . . . 5		7.2 XML Schema Registration . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1 Normative References . . . . . . . . . . . . . . . . . . . . 6		8.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
	8.2 Informative References . . . . . . . . . . . . . . . . . . . 6		8.2 Informative References . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . 7		Intellectual Property and Copyright Statements . . . . . . . . 9
	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 [3] and		and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
	indicate requirement levels for compliant implementations.		indicate requirement levels for compliant implementations.
	2. Introduction		2. Introduction
	An important component of presence [5] is policy. Policy systems		An important component of presence [6] is policy. Policy systems
	allow the presentity to grant access to specific pieces of		allow the presentity to grant access to specific pieces of
	information to specific watchers. These policy systems can be		information to specific watchers. These policy systems can be
	extremely simple or extremely complex. For this reason [1] defines a		extremely simple or extremely complex. For this reason [1] defines a
	generic Extensible Markup Language (XML) based format for		generic Extensible Markup Language (XML) based format for
	representing policy capabilities. That format applies to many		representing policy capabilities. That format applies to many
	services, including location and presence. This specification		services, including location and presence. This specification
	extends that one by defining policy capabilities specific to		extends that one by defining policy capabilities specific to
	presence. Those policy capabilities correspond to the conditions,		presence. Those policy capabilities correspond to the conditions,
	actions and transformations defined in [2].		actions and transformations defined in [2].
	3. Structure of Presence Policy Capabilities		3. Structure of Presence Policy Capabilities
	[1] defines the structure of common policy capability documents. In		[1] defines the structure of common policy capability documents. In
	that specification, each policy capability document has three		that specification, each policy capability document has three
	components - a list of supported conditions, a list of supported		components - a list of supported conditions, a list of supported
	actions, and a list of supported transformations. This specification		actions, and a list of supported transformations. This specification
	merely extends that document with the conditions, actions and		merely extends that document with the conditions, actions and
	transformations defined in [2]. It does so by defining six empty		transformations defined in [2]. It does so by defining the elements
	elements - "anonymous", "accept-subscription", "provide-presence",		<provide-services>, <provide-devices> and <provide-person>, each of
	"show-namespace", "show-tuple", "show-element" - each of which		which is a presence transformation that the server can support.
	indicates whether the respective attribute in [2] is supported. All		Furthermore, each of those includes elements that define the specific
	of these elements are defined within the namespace:		ways of identifying services, devices and persons, respectively.
	urn:ietf:params:xml:ns:supported-pres-permissions
			The document also defines capabilities for transformations that
			provide individual presence attributes, including
			<provide-activities>, <provide-class>, <provide-device-id>,
			<provide-mood>, <provide-place-is>, <provide-place-type>,
			<provide-privacy>, <provide-relationship>, <provide-status-icon>,
			<provide-sphere>, <provide-time-offset>, <provide-user-input>,
			<provide-note>, <component-id>, <provide-unknown-attribute>, and
			<provide-all-attributes>, each of which is a boolean indicating
			whether that transformation is supported.
			Finally, this document defines the <sub-handling> element, which is a
			boolean indicating whether or not the corresponding action is
			supported.
			OPEN ISSUE: should we define capabilities for specific values of
			sub-handling and component-id?
			All of these elements are defined within the namespace:
			urn:ietf:params:xml:ns:presence-policy-capabilities
	4. XML Schema		4. XML Schema
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:supported-pres-permissions"		targetNamespace="urn:ietf:params:xml:ns:presence-policy-capabilities"
	xmlns:pc="urn:ietf:params:xml:ns:supported-pres-permissions"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:cc="urn:ietf:params:xml:ns:supported-permissions"		xmlns:cc="urn:ietf:params:xml:ns:policy-capabilities"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:pc="urn:ietf:params:xml:ns:presence-policy-capabilities"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:import namespace="urn:ietf:params:xml:ns:supported-permissions"/>		<xs:import namespace="urn:ietf:params:xml:ns:policy-capabilities"
	<xs:element name="anonymous" substitutionGroup="cc:condition"/>		schemaLocation="sbase.xsd"/>
	<xs:element name="accept-subscription" substitutionGroup="cc:action"/>		<xs:element name="provide-services">
	<xs:element name="provide-presence" substitutionGroup="cc:action"/>		<xs:complexType>
	<xs:element name="show-namespace" substitutionGroup="cc:transformation"/>		<xs:sequence>
	<xs:element name="show-element" substitutionGroup="cc:transformation"/>		<xs:element name="service-uri" type="cc:emptyType" minOccurs="0"/>
	<xs:element name="show-tuple" substitutionGroup="cc:transformation"/>		<xs:element name="service-uri-scheme" type="cc:emptyType" minOccurs="0"/>
			<xs:element name="instance-id" type="cc:emptyType" minOccurs="0"/>
			<xs:element name="class" type="cc:emptyType" minOccurs="0"/>
			<xs:any namespace="##other" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
			</xs:element>
			<xs:element name="provide-devices">
			<xs:complexType>
			<xs:sequence>
			<xs:element name="device-id" type="cc:emptyType" minOccurs="0"/>
			<xs:element name="instance-id" type="cc:emptyType" minOccurs="0"/>
			<xs:element name="class" type="cc:emptyType" minOccurs="0"/>
			<xs:any namespace="##other" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
			</xs:element>
			<xs:element name="provide-person">
			<xs:complexType>
			<xs:sequence>
			<xs:element name="instance-id" type="cc:emptyType" minOccurs="0"/>
			<xs:element name="class" type="cc:emptyType" minOccurs="0"/>
			<xs:any namespace="##other" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
			</xs:element>
			<xs:element name="provide-activities" type="cc:emptyType"/>
			<xs:element name="provide-class" type="cc:emptyType"/>
			<xs:element name="provide-device-id" type="cc:emptyType"/>
			<xs:element name="provide-mood" type="cc:emptyType"/>
			<xs:element name="provide-place-is" type="cc:emptyType"/>
			<xs:element name="provice-place-type" type="cc:emptyType"/>
			<xs:element name="provide-privacy" type="cc:emptyType"/>
			<xs:element name="provide-relationship" type="cc:emptyType"/>
			<xs:element name="provide-status-icon" type="cc:emptyType"/>
			<xs:element name="provide-sphere" type="cc:emptyType"/>
			<xs:element name="provide-time-offset" type="cc:emptyType"/>
			<xs:element name="provide-user-input" type="cc:emptyType"/>
			<xs:element name="provide-note" type="cc:emptyType"/>
			<xs:element name="component-id" type="cc:emptyType"/>
			<xs:element name="sub-handling" type="cc:emptyType"/>
			<xs:element name="provide-unknown-attribute" type="cc:emptyType"/>
			<xs:element name="provide-all-attributes" type="cc:emptyType"/>
	</xs:schema>		</xs:schema>
	5. Example Document		5. Example Document
	The following document indicates that the identity, validity, sphere		The following document is an example.
	and confirmation attributes are supported. It also indicates that a
	vendor-specific condition, called "temp", is supported, in addition
	to two vendor-specific transformations - "max-security" and
	"min-security". The "show-tuple" element is also supported.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<supported-permissions		<cc:policy-capabilities
	xmlns="urn:ietf:params:xml:ns:supported-permissions"		xmlns="urn:ietf:params:xml:ns:presence-policy-capabilities"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:pc="urn:ietf:params:xml:ns:presence-policy-capabilities"
	xmlns:vpp="http://www.vendor.com/extension1"		xmlns:cc="urn:ietf:params:xml:ns:policy-capabilities"
	xmlns:pc="urn:ietf:params:xml:ns:supported-pres-permissions">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	<conditions>		xsi:schemaLocation="urn:ietf:params:xml:ns:presence-policy-capabilities
	<identity/>		spres.xsd">
	<validity/>		<cc:conditions>
	<sphere/>		<cc:identity/>
			<cc:sphere/>
			<cc:validity/>
			<cc:sphere/>
	<vpp:temp/>		<vpp:temp/>
	</conditions>		</cc:conditions>
	<actions>		<cc:actions>
	<confirmation/>		<sub-handling/>
	</actions>		</cc:actions>
	<transformations>		<cc:transformations>
	<vpp:min-security/>		<vpp:min-security/>
	<vpp:max-security/>		<vpp:max-security/>
	<pc:show-tuple/>		<component-id/>
			<provide-person>
			<class/>
			</provide-person>
			</cc:transformations>
			</cc:policy-capabilities>
	</transformations>		NOTE: this example needs work - doens't validate against the
	</supported-permissions>		schema.
	6. Security Considerations		6. Security Considerations
	This specification does not introduce any new security considerations		This specification does not introduce any new security considerations
	beyond those discussed in [1].		beyond those discussed in [1].
	7. IANA Considerations		7. IANA Considerations
	There are several IANA considerations associated with this		There are several IANA considerations associated with this
	specification.		specification.
	7.1 URN Sub-Namespace Registrations		7.1 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
	[4]		[4]
	URI: The URI for this namespace is		URI: The URI for this namespace is
	urn:ietf:params:xml:ns:supported-pres-permissions.		urn:ietf:params:xml:ns:presence-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).
	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>Supported Presence Permissions Namespace</title>		<title>Supported Presence Permissions Namespace</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for Supported Permissions</h1>		<h1>Namespace for Supported Permissions</h1>
	<h2>urn:ietf:params:xml:ns:supported-pres-permissions</h2>		<h2>urn:ietf:params:xml:ns:presence-policy-capabilities</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
	7.2 XML Schema Registration		7.2 XML Schema Registration
	This section registers an XML schema as per the procedures in [4].		This section registers an XML schema as per the procedures in [4].
	URI: please assign.		URI: urn:ietf:params:xml:schema:presence-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 4.		Section 4.
	8. References		8. References
	8.1 Normative References		8.1 Normative References
	[1] Rosenberg, J., "An Extensible Markup Language (XML)		[1] Rosenberg, J., "An Extensible Markup Language (XML)
	Representation for Expressing Policy Capabilities",		Representation for Expressing Policy Capabilities",
	draft-rosenberg-simple-common-policy-caps-00 (work in progress),		draft-rosenberg-simple-common-policy-caps-01 (work in progress),
	February 2004.		July 2004.
	[2] Rosenberg, J., "Presence Authorization Rules",		[2] Rosenberg, J., "Presence Authorization Rules",
	draft-rosenberg-simple-rules-00 (work in progress), February		draft-ietf-simple-presence-rules-01 (work in progress), October
	2004.		2004.
	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[3] 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.
	[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January		[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
	2004.		2004.
	8.2 Informative References		8.2 Informative References
	[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and		[5] Rosenberg, J., "The Extensible Markup Language (XML)
			Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-06
			(work in progress), February 2005.
			[6] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
	Instant Messaging", RFC 2778, February 2000.		Instant Messaging", RFC 2778, February 2000.
	Author's Address		Author's Address
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		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
	EMail: jdrosen@dynamicsoft.com		EMail: jdrosen@cisco.com
	URI: http://www.jdrosen.net		URI: http://www.jdrosen.net
	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 Rights 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; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	skipping to change at page 7, line 41 ¶		skipping to change at page 9, 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 (2004). This document is subject		Copyright (C) The Internet Society (2005). 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. 25 change blocks.
	70 lines changed or deleted		147 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/