< draft-rosenberg-simple-common-policy-caps-01.txt   draft-rosenberg-simple-common-policy-caps-02.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft Cisco Systems
Expires: January 16, 2005 July 18, 2004 Expires: August 22, 2005 February 21, 2005
An Extensible Markup Language (XML) Representation for Expressing An Extensible Markup Language (XML) Representation for Expressing
Policy Capabilities Policy Capabilities
draft-rosenberg-simple-common-policy-caps-01 draft-rosenberg-simple-common-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 16, 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 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
skipping to change at page 2, line 19 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Example Document . . . . . . . . . . . . . . . . . . . . . . . 6 6. Example Document . . . . . . . . . . . . . . . . . . . . . . . 6
7. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . . . 6 7. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 Application Unique ID . . . . . . . . . . . . . . . . . . 6 7.1 Application Unique ID . . . . . . . . . . . . . . . . . . 6
7.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 7.3 Default Namespace . . . . . . . . . . . . . . . . . . . . 7
7.4 Additional Constraints . . . . . . . . . . . . . . . . . . 7 7.4 MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 7
7.5 Data Semantics . . . . . . . . . . . . . . . . . . . . . . 7 7.5 Validation Constraints . . . . . . . . . . . . . . . . . . 7
7.6 Naming Conventions . . . . . . . . . . . . . . . . . . . . 7 7.6 Data Semantics . . . . . . . . . . . . . . . . . . . . . . 7
7.7 Resource Interdependencies . . . . . . . . . . . . . . . . 7 7.7 Naming Conventions . . . . . . . . . . . . . . . . . . . . 7
7.8 Authorization Policies . . . . . . . . . . . . . . . . . . 7 7.8 Resource Interdependencies . . . . . . . . . . . . . . . . 7
7.9 Authorization Policies . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 8 9.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 8
9.2 MIME Type Registration . . . . . . . . . . . . . . . . . . 8 9.2 MIME Type Registration . . . . . . . . . . . . . . . . . . 8
9.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 9 9.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 9
9.4 XML Schema Registration . . . . . . . . . . . . . . . . . 10 9.4 XML Schema Registration . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 10
10.2 Informative References . . . . . . . . . . . . . . . . . . . 11 10.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13
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 6, line 45 skipping to change at page 6, line 46
</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 a unique application usage XCAP requires application usages to define an application unique ID
ID (AUID) in either the IETF tree or a vendor tree. This (AUID) in either the IETF tree or a vendor tree. This specification
specification defines the "policy-capabilities" AUID within the IETF defines the "policy-capabilities" AUID within the IETF tree, via the
tree, via the IANA registration in Section 9. IANA registration in Section 9.
7.2 MIME Type 7.2 XML Schema
The MIME type for this document is "application/policy-caps+xml". The schema is defined in Section 5.
7.3 XML Schema 7.3 Default Namespace
The schema is defined in Section 5. The default namespace used in evaluating a URI is
urn:ietf:params:xml:ns:policy-capabilities.
7.4 Additional Constraints 7.4 MIME Type
This specification does not introduce any additional constraints The MIME type for this document is "application/policy-caps+xml".
beyond those defined in the schema.
7.5 Data Semantics 7.5 Validation Constraints
This specification does not introduce any additional validation
constraints beyond those defined in the schema.
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.6 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.7 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.8 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 8, line 33 skipping to change at page 8, line 39
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 Usage 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
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [9]. specified in RFC 3023 [9].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [9]. application/xml as specified in RFC 3023 [9].
Security considerations: See Section 10 of RFC 3023 [9] and Security considerations: See Section 10 of RFC 3023 [9] and
Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
XXXX with the RFC number of this specification]]. XXXX with the RFC number of this specification]].
Interoperability considerations: none. Interoperability considerations: none.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this specification]] Please replace XXXX with the RFC number of this specification]]
Applications which use this media type: This document type has Applications which use this media type: This document type has
been used to support capabilities for presence and geolocation. been used to support capabilities for presence and geolocation.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .pcp or .xml
File Extension: .pcp
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).
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"/>
skipping to change at page 10, line 9 skipping to change at page 10, line 35
<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-02 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-06
(work in progress), February 2004. (work in progress), February 2005.
[5] Schulzrinne, H., "Common Policy", [5] Schulzrinne, H., "A Document Format for Expressing Privacy
draft-ietf-geopriv-common-policy-00 (work in progress), February Preferences", draft-ietf-geopriv-common-policy-03 (work in
2004. progress), October 2004.
[6] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [6] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
FirstEdition REC-xml-20001006, October 2000. FirstEdition REC-xml-20001006, October 2000.
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004. 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", BCP Mail Extensions (MIME) Part Four: Registration Procedures", BCP
skipping to change at page 11, line 13 skipping to change at page 11, line 41
3023, January 2001. 3023, January 2001.
10.2 Informative References 10.2 Informative References
[10] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and [10] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000. 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., "Geopriv Policy", draft-ietf-geopriv-policy-01 [12] Schulzrinne, H., "A Document Format for Expressing Privacy
(work in progress), February 2004. Preferences for Location Information",
draft-ietf-geopriv-policy-05 (work in progress), November 2004.
[13] Rosenberg, J., "Presence Authorization Rules", [13] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-00 (work in progress), May draft-ietf-simple-presence-rules-01 (work in progress), October
2004. 2004.
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 12, line 41 skipping to change at page 13, 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. 47 change blocks. 
45 lines changed or deleted 76 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/