XCON H. Khartabil
Internet-Draft A. Niemi
Expires: April 12, 2005 Nokia
October 12, 2004
Privileges for Manipulating a Conference Policy
draft-ietf-xcon-conference-policy-privileges-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The Conference Policy is defined as the complete set of rules for a
particular conference manipulated by the conference policy server.
The Conferece Policy Control Protocol (CPCP) is the protocol used by
client to manipulate the conference policy. This document specifies
an Extensible Markup Language (XML) Schema that enumerates the
conference policy meta data that enable a user to assign privileges
to users that enables them to read and/or manipulate parts of or the
Khartabil & Niemi Expires April 12, 2005 [Page 1]
Internet-Draft CPCP-Privileges October 2004
entire conference policy.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Structure of a Conference Policy Privileges XML Document . . . 4
4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4
4.2 Privileges Root . . . . . . . . . . . . . . . . . . . . . 5
4.3 XML Document Description . . . . . . . . . . . . . . . . . 5
4.3.1 Conference Policy Privileges . . . . . . . . . . . . . 5
4.3.1.1 Conditions . . . . . . . . . . . . . . . . . . . . 6
4.3.1.1.1 Validity . . . . . . . . . . . . . . . . . . . 6
4.3.1.1.2 Identity . . . . . . . . . . . . . . . . . . . 7
4.3.1.1.2.1 Interpreting the <id> Element . . . . . . 8
4.3.1.1.3 Conference Policy Identity . . . . . . . . . . 8
4.3.1.1.3.1 Matching Any Identity . . . . . . . . . . 8
4.3.1.1.3.2 Matching Identities in External Lists . . 8
4.3.1.1.4 Sphere . . . . . . . . . . . . . . . . . . . . 8
4.3.1.2 Actions . . . . . . . . . . . . . . . . . . . . . 8
4.3.1.2.1 Modifying Conference setting . . . . . . . . . 8
4.3.1.2.2 Modifying Conference Information . . . . . . . 9
4.3.1.2.3 Modifying Conference Time . . . . . . . . . . 9
4.3.1.2.4 Modifying Authorization rules . . . . . . . . 9
4.3.1.2.5 Modifying Conference Dial-out List . . . . . . 9
4.3.1.2.6 Modifying Conference Refer List . . . . . . . 9
4.3.1.2.7 Modifying Conference media streams . . . . . . 10
4.3.1.2.8 Creating Sidebars . . . . . . . . . . . . . . 10
4.3.1.2.9 Modifying Conference Dial-in List . . . . . . 10
4.3.1.2.10 Reading Conference setting . . . . . . . . . . 10
4.3.1.2.11 Reading Conference Information . . . . . . . . 11
4.3.1.2.12 Reading Conference Time . . . . . . . . . . . 11
4.3.1.2.13 Reading Authorization rules . . . . . . . . . 11
4.3.1.2.14 Reading Conference Dial-out List . . . . . . . 11
4.3.1.2.15 REading Conference Refer List . . . . . . . . 11
4.3.1.2.16 Reading Conference media streams
Information . . . . . . . . . . . . . . . . . 12
4.3.1.2.17 Reading Sidebar Information . . . . . . . . . 12
4.3.1.2.18 Reading Conference Dial-in List . . . . . . . 12
4.3.1.3 Transformations . . . . . . . . . . . . . . . . . 12
4.4 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 A Simple Conference Policy Privileges Document . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1 application/privileges+xml MIME TYPE . . . . . . . . . . . 15
7.2 URN Sub-Namespace Registration for
Khartabil & Niemi Expires April 12, 2005 [Page 2]
Internet-Draft CPCP-Privileges October 2004
urn:ietf:params:xml:ns:privileges . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Khartabil & Niemi Expires April 12, 2005 [Page 3]
Internet-Draft CPCP-Privileges October 2004
1. Introduction
The Conference Policy Control Protocol (CPCP) [1]specifies an
Extensible Markup Language (XML) Schema that enumerates the
conference policy data elements that enable a user to define a
conference policy. It, however, does not define user privileges (who
is allowed to read or modify certain parts or all of a conference
policy).
In many cases, the creator of the conference policy is the sole user
with access rights to the conference policy and other users do not
have any rights to view nor modify the document. However, there is a
need for different privileges to exist where users can modify certain
parts of the conference policy XML document. This document specifies
an Extensible Markup Language (XML) Schema that enumerates the
conference policy meta data that enable such privileges to exist.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
3. Terminology
This document uses terminology from [13]. Some additional
definitions are introduced in [1], including the defintion of a
privileged user.
4. Structure of a Conference Policy Privileges XML Document
The conference policy privileges document is an XML [4] document that
MUST be well-formed and MUST be valid according to schemas, including
extension schemas, available to the validater and applicable to the
XML document. The Conference policy privelges documents MUST be
based on XML 1.0 and MUST be encoded using UTF-8. This specification
makes use of XML namespaces for identifying conference policy
privileges documents and document fragments. The namespace URI for
elements defined by this specification is a URN [6], using the
namespace identifier 'ietf' defined by [7] and extended by [8]. This
URN is:
urn:ietf:params:xml:ns:privileges
4.1 MIME Type for CPCP XML Document
The MIME type for the CPCP XML document is
Khartabil & Niemi Expires April 12, 2005 [Page 4]
Internet-Draft CPCP-Privileges October 2004
"application/privileges+xml".
4.2 Privileges Root
A conference policy privileges document begins with the root element
tag <privileges>. Other elements from different namespaces MAY be
present for the purposes of extensibility. Elements or attributes
from unknown namespaces MUST be ignored.
A user may create a new conference policy privieleges at the CPS by
placing a new conference policy document at the CPS. Depending on
server policy and user privileges, the CPS may accept the creation.
Only the creator of the conference can create a conference policy
privileges document for that conference policy.
A conference that exists without a conference policy privileges
document allows all privileges to the creator of the conference
policy only. A conference policy privielges document can be deleted
permanently by removing the conference policy document from the CPS.
When the user deletes a conference policy document, the user SHOULD
also delete the conference policy privielges document associated with
the deleted conference. A CPS may apply local policy in determining
when and if to delete the conference policy privielges document if it
has not been removed after a the conference policy document was
deleted.
4.3 XML Document Description
4.3.1 Conference Policy Privileges
One of the key components of the conference policy privileges
document is the set of authorization rules that specify who is
allowed to read and manipulate a conference policy. The unordered
list of authorization rules together define the conference policy
privileges in the form of an authorization policy.
The <uri> element appears after the root element and contains the URI
of the conference policy document that the privileges defines within
it apply to. This is followed by the <ruleset> element which carry
the rules defining the actual privileges.
The conference policy privileges are enclosed in the <ruleset>
element are formatted according to the XML schema defined in the
common policy framework [2]. In the <ruleset> element, there can be
multiple rules, each rule is represented by the <rule> element, each
of which consist of three parts: conditions, actions and
transformations. Conditions determine whether a particular rule
applies to a request. Each action or transformation in the applied
Khartabil & Niemi Expires April 12, 2005 [Page 5]
Internet-Draft CPCP-Privileges October 2004
rule is a positive grant of permission to the conference policy user.
The details of each specific element and attribute is described in
[2].
Asking the conference policy server to allow certain users to
manipulate the conference policy is achieved by modifying an existing
authorization rule or creating a new one.
If the conference is long-lasting, it is possible that new rules are
added all the time but old rules are almost never removed (some of
them are overwritten, though). This leads easily to the situation
that the conference policy meta data contains many unnecessary rules
which are not really needed anymore. Therefore, there is a need to
delete rules. This can be achieved by removing that portion of the
policy.
Conflicting rules may exist (for example, both allowed and blocked
action is defined for same target). The common policy directives [2]
dictate the behaviour in such situations.
This section outlines the new conditions, actions and transformations
for conference policy privileges.
4.3.1.1 Conditions
4.3.1.1.1 Validity
The <validity> element, as defined in the common policy framework
[2], expresses the rule validity period by two attributes, a starting
and a ending time. Times are expressed in XML dateTime format.
Expressing the lifetime of a rule implements a garbage collection
mechanism. A rule maker might not have always access to the
conference policy server to remove some rules which grant
permissions. Hence this mechanisms allows to remove or invalidate
granted permissions automatically without further interaction between
the rule maker and the conference policy server.
To give a real life example, there are often meetings where users can
have access to modify the dial-out list from 10 minutes before the
conference starts until 10 mintues after the conference starts. One
rules can be set in this scenario. The following example demostrates
this. The meeting starts at 9:30 and ends at 12:30. A manager with
identity "manager@example.com" can read and modify the dial-out list
betweem 8:50 and 9:40. After that time until the conference ends,
the manager can only read the dial-out-list
Khartabil & Niemi Expires April 12, 2005 [Page 6]
Internet-Draft CPCP-Privileges October 2004
<rule id="1">
<conditions>
<validity>
<from>2004-12-17T08:50:00-05:00</from>
<to>2004-12-17T09:40:00-05:00</to>
</validity>
<identity>
<id>manager@example.com</id>
</identity>
</conditions>
<actions>
<allow-modify-dol>allow</allow-modify-dol>
</actions>
<transformations/>
</rule>
<rule id="2">
<conditions>
<identity>
<id>manager@example.com</id>
</identity>
</conditions>
<actions>
<allow-read-dol>allow</allow-read-dol>
</actions>
<transformations/>
</rule>
...
<time>
<occurrence>
<mixing-start-time required-participant="participant">
2004-12-17T09:30:00-05:00</mixing-start-time>
<mixing-stop-time required-participant="none">
2004-12-17T12:30:00-05:00</mixing-stop-time>
</occurrence>
</time>
4.3.1.1.2 Identity
The <identity> element is already defined in the common policy
framework [2]The presence of the <identity> element is a condition
requires any identity within it to be authenticated before a rule is
applied to it. This includes the <id> element (Section 4.3.1.1.2.1),
the <any> element (Section 4.3.1.1.3.1), the <external-list> element
(Section 4.3.1.1.3.2), their exceptions, and any future extension
that carries an identity. The absence of the <identity> element with
in a condition indicated that the rule applies to all unauthenticated
Khartabil & Niemi Expires April 12, 2005 [Page 7]
Internet-Draft CPCP-Privileges October 2004
identities. That is participants that have provided no authenticated
identity to the conference focus.
4.3.1.1.2.1 Interpreting the <id> Element
As earlier indicated, the <identity> element is already defined in
the common policy framework [2]. However, the rules for interpreting
the identities in <id> elements are left for each application to
define separately. This document, however, does not define the rules
for interpreting identities in <id> elements in conferencing
applications since those interpretation rules are signalling protocol
specific.
OPEN ISSUE: Do we need to state more than this? How are identities
derived from users that join using POTS, H.323, etc.?
4.3.1.1.3 Conference Policy Identity
4.3.1.1.3.1 Matching Any Identity
The <any> element is used to match any participant. This allows a
conference priveleges to be open to any authenticated user. Just as
for the <domain> element in <identity> element, The <any> element
contains a list of <except> elements and allows to implement a simple
blacklist mechanism. The <except> element contains the identity. It
differs from the <domain> element in that the domain part is needed
in the identity since it has not domain to refer to.
4.3.1.1.3.2 Matching Identities in External Lists
The <external-list> element can be used to match those participants
that are part of a resource list that is created externally. The use
of <external-list> is similar to that defined in Section x of [1].
4.3.1.1.4 Sphere
The <sphere> element has no meaning in the context of conference
policy and MUST be ignored if present.
4.3.1.2 Actions
4.3.1.2.1 Modifying Conference setting
The <allow-modify-settings> element represents a boolean action. If
set to TRUE, the identity is allowed to modify the conference
settings in the conference policy. If set to FALSE, any
modifications to the conference settings are rejected.
Khartabil & Niemi Expires April 12, 2005 [Page 8]
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.2 Modifying Conference Information
The <allow-modify-information> element represents a boolean action.
If set to TRUE, the identity is allowed to modify the conference
information in the conference policy. If set to FALSE, any
modifications to the conference information are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.3 Modifying Conference Time
The <allow-modify-time> element represents a boolean action. If set
to TRUE, the identity is allowed to modify the conference time in
the conference policy. If set to FALSE, any modifications to the
conference time are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.4 Modifying Authorization rules
The <allow-modify-authorization-rules> element represents a boolean
action. If set to TRUE, the identity is allowed to modify the
authorization rules of a conference in the conference policy. If set
to FALSE, any modifications to the rules are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.5 Modifying Conference Dial-out List
The <allow-modify-dol> element represents a boolean action. If set
to TRUE, the identity is allowed to modify the conference dial-out
list in the conference policy. If set to FALSE, any modifications to
the dial-out list are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.6 Modifying Conference Refer List
The <allow-modify-rl> element represents a boolean action. If set to
TRUE, the identity is allowed to modify the conference refer list in
the conference policy. If set to FALSE, any modifications to the
refer list are rejected.
Khartabil & Niemi Expires April 12, 2005 [Page 9]
Internet-Draft CPCP-Privileges October 2004
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.7 Modifying Conference media streams
The <allow-modify-ms> element represents a boolean action. If set to
TRUE, the identity is allowed to modify the conference media streams
in the conference policy. If set to FALSE, any modifications to the
media streams are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.8 Creating Sidebars
The <allow-modify-sidebar> element represents a boolean action. If
set to TRUE, the identity is allowed to create and manipulate a
sidebar by creating and modifying a <sidebar> element in a conference
policy. If set to FALSE, any sidebar creation and manipulation is
rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.9 Modifying Conference Dial-in List
The conference dial-in list is virtual and is not represented by a
physical list in the conference policy. It is rather a collection of
authorization rules that allow users to join a conference. The
<allow-modify-dil> element represents a boolean action. If set to
TRUE, the identity is allowed to create an authorization rule in the
conference policy that give a user a join handling of "allow". If
set to FALSE, any modifications to authorization rules are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.10 Reading Conference setting
The <allow-read-settings> element represents a boolean action. If
set to TRUE, the identity is allowed to read the conference settings
in the conference policy. If set to FALSE, any attempts to read the
conference settings are rejected.
If this element is undefined it has a value of FALSE, causing the
read requests to be rejected.
Khartabil & Niemi Expires April 12, 2005 [Page 10]
Internet-Draft CPCP-Privileges October 2004
4.3.1.2.11 Reading Conference Information
The <allow-read-information> element represents a boolean action. If
set to TRUE, the identity is allowed to read the conference
information in the conference policy. If set to FALSE, any attempts
to read the conference information are rejected.
If this element is undefined it has a value of FALSE, causing the
read requests to be rejected.
4.3.1.2.12 Reading Conference Time
The <allow-read-time> element represents a boolean action. If set to
TRUE, the identity is allowed to read the conference time in the
conference policy. If set to FALSE, any attempts to read the
conference time are rejected.
If this element is undefined it has a value of FALSE, causing the
read requests to be rejected.
4.3.1.2.13 Reading Authorization rules
The <allow-read-authorization-rules> element represents a boolean
action. If set to TRUE, the identity is allowed to read the
authorization rules of a conference in the conference policy. If set
to FALSE, any attempts to read the rules are rejected.
If this element is undefined it has a value of FALSE, causing the
read requests to be rejected.
4.3.1.2.14 Reading Conference Dial-out List
The <allow-read-dol> element represents a boolean action. If set to
TRUE, the identity is allowed to read the conference dial-out list
in the conference policy. If set to FALSE, any attempts to read the
dial-out list are rejected.
If this element is undefined it has a value of FALSE, causing the
read requests to be rejected.
4.3.1.2.15 REading Conference Refer List
The <allow-read-rl> element represents a boolean action. If set to
TRUE, the identity is allowed to read the conference refer list in
the conference policy. If set to FALSE, any attempts to read the
refer list are rejected.
If this element is undefined it has a value of FALSE, causing the
Khartabil & Niemi Expires April 12, 2005 [Page 11]
Internet-Draft CPCP-Privileges October 2004
read requests to be rejected.
4.3.1.2.16 Reading Conference media streams Information
The <allow-read-ms> element represents a boolean action. If set to
TRUE, the identity is allowed to read the conference media streams
information in the conference policy. If set to FALSE, any attempts
to read the media streams information are rejected.
If this element is undefined it has a value of FALSE, causing the
read requests to be rejected.
4.3.1.2.17 Reading Sidebar Information
The <allow-read-sidebar> element represents a boolean action. If set
to TRUE, the identity is allowed to read side bar inforation in the
conference policy, indicating how many sidebars are currently in a
conference. If set to FALSE, any attempts to read sidebar
information is rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.1.2.18 Reading Conference Dial-in List
The Dial-in List is defined in Section 4.3.1.2.9. If set to TRUE,
the identity is allowed to read authorizations rule in the
conference policy that give a user a join handling of "allow". If
set to FALSE, any attempts to read such rules are rejected.
If this element is undefined it has a value of FALSE, causing the
read requests to be rejected.
4.3.1.3 Transformations
No transformations are defined at this time.
4.4 XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:privileges" xmlns="urn:ietf:params:xml:ns:privileges" xmlns:cr="urn:ietf:params:xml:ns:common-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- This import brings in the common-policy-->
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<xs:element name="privileges">
<xs:complexType>
Khartabil & Niemi Expires April 12, 2005 [Page 12]
Internet-Draft CPCP-Privileges October 2004
<xs:sequence>
<xs:element name="uri" type="xs:string"/>
<xs:element ref="cr:ruleset"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="cp-identity" substitutionGroup="cr:condition">
<xs:complexType>
<xs:choice>
<xs:sequence>
<xs:element name="any"/>
<xs:sequence minOccurs="0">
<xs:element name="except" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
<xs:sequence>
<xs:element name="external-list" type="xs:string"/>
<xs:sequence minOccurs="0">
<xs:element name="except" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="allow-modify-settings" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-information" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-time" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-authorization-rules" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-dol" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-rl" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-ms" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-sidebar" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-dil" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-settings" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-information" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-time" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-authorization-rules" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-dol" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-rl" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-ms" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-sidebar" type="xs:boolean" substitutionGroup="cr:action"/>
</xs:schema>
5. Examples
Khartabil & Niemi Expires April 12, 2005 [Page 13]
Internet-Draft CPCP-Privileges October 2004
5.1 A Simple Conference Policy Privileges Document
The following document dictates that Bob and Alice are allowed to
read and modify the conference settings at
"http://xcap.example.com/services/conferences/users/Alice/conference.
xml" why John can only read the dial-out list.
<?xml version="1.0" encoding="UTF-8"?>
<privileges xmlns="urn:ietf:params:xml:ns:privileges" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cr="urn:ietf:params:xml:ns:common-policy">
<uri>http://xcap.example.com/services/conferences/users/Alice/conference.xml"</uri>
<cr:ruleset>
<cr:rule id="1">
<cr:conditions>
<cr:identity>
<cr:id>bob@example.com</cr:id>
<cr:id>alice@example.com</cr:id>
</cr:identity>
</cr:conditions>
<cr:actions>
<allow-modify-settings>true</allow-modify-settings>
<allow-read-settings>true</allow-read-settings>
</cr:actions>
<cr:transformations/>
</cr:rule>
<cr:rule id="2">
<cr:conditions>
<cr:identity>
<cr:id>john@example.com</cr:id>
</cr:identity>
</cr:conditions>
<cr:actions>
<allow-read-dol>true</allow-read-dol>
</cr:actions>
<cr:transformations/>
</cr:rule>
</cr:ruleset>
</privileges>
6. Security Considerations
A conference policy privileges document may contain information that
is highly sensitive. Its delivery to the conference server needs to
Khartabil & Niemi Expires April 12, 2005 [Page 14]
Internet-Draft CPCP-Privileges October 2004
happen strictly, paying special attention to integrity and
confidentiality. Reading the document is also a security concern
since the conference policy proviliges document contains sensitive
information like who is allowed to modify certain parts of a
conference policy document.
A milicious user can manipulate parts of the conference policy
privileges document giving themselves and others privileges to
manipulate the conference policy, including the dial-out list and the
ruleset. Those authorization rules carry the privileges that certain
identities have. If an unauthorized user gets access to this
document (pretending to be someone else), s/he can manipulate those
rules giving himself and other unauthorized users access to the
conference policy. Some of the things that a malicious user can do
include: denying users certain privileges, removing rules for certain
identities and giving privileges to other malicious users.
Therefore, it is very important that only authorized clients are able
to manipulate the conference policy privileges document. Any
conference policy privileges document transport protocol MUST provide
authentication, confidentiality and integrity.
7. IANA Considerations
7.1 application/privileges+xml MIME TYPE
MIME media type: application
MIME subtype name: privileges+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [5].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [5].
Security considerations: See section 10 of RFC 3023 [5] and section
Section 7 of this document.
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has been
used to support conference policy manipulation for SIP based
conferencing.
Khartabil & Niemi Expires April 12, 2005 [Page 15]
Internet-Draft CPCP-Privileges October 2004
Additional information:
Magic number: None
File extension: .cl or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Hisham Khartabil
(hisham.khartabil@nokia.com)
Intended Usage: COMMON
Author/change controller: The IETF
7.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:privileges
This section registers a new XML namespace, as per guidelines in URN
document [8].
URI: The URI for this namespace is urn:ietf:params:xml:ns:privileges.
Registrant Contact: IETF, XCON working group, Hisham Khartabil
(hisham.khartabil@nokia.com)
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Conference Policy Namespace</title>
</head>
<body>
<h1>Namespace for Conference Policy</h1>
<h2>application/conference-policy+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
Khartabil & Niemi Expires April 12, 2005 [Page 16]
Internet-Draft CPCP-Privileges October 2004
8. Acknowledgements
The authors would like to thank Hannes Tschofenig, Aki Niemi, Alan
Johnston, and the IETF XCON working group for their feedback and
suggestions.
9 Normative References
[1] Khartabil, H., Koskelainen, P. and A. Niemi, "The Conference
Policy Control Protocol (CPCP)", Internet-Draft
I-D.draft-ietf-xcon-cpcp, September 2004.
[2] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J. and J.
Rosenberg, "Common Policy", Internet-Draft
I-D.ietf-geopriv-common-policy, February 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997.
[4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000.
[5] Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[8] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[9] Koskelainen, P. and H. Khartabil, "Requirements for conference
policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in
progress), January 2004.
[10] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-03 (work in progress),
February 2004.
[11] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-02 (work in progress), February 2004.
[12] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence Lists",
Khartabil & Niemi Expires April 12, 2005 [Page 17]
Internet-Draft CPCP-Privileges October 2004
draft-ietf-simple-xcap-list-usage-02 (work in progress),
February 2004.
[13] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-01 (work in
progress), October 2003.
[14] Franks, J., "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Authors' Addresses
Hisham Khartabil
Nokia
P.O. Box 321
Helsinki FIN-00045
Finland
EMail: hisham.khartabil@nokia.com
Aki Niemi
Nokia
P.O. Box 100
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Khartabil & Niemi Expires April 12, 2005 [Page 18]
Internet-Draft CPCP-Privileges October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Khartabil & Niemi Expires April 12, 2005 [Page 19]
