Transport P. Koskelainen
Internet-Draft H. Khartabil
Expires: December 19, 2003 Nokia
June 20, 2003
An Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) Usage for Conference Policy Manipulation
draft-koskelainen-xcon-xcap-cpcp-usage-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 December 19, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes conference policy data elements and the
mechanisms to manipulate them at a server via Conference Policy
Control Protocol (CPCP). Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) is used to implement CPCP. This
document specifies an XML Schema and XCAP application usage that are
needed to implement CPCP.
Koskelainen & Khartabil Expires December 19, 2003 [Page 1]
Internet-Draft XCAP CPCP June 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Application Unique ID . . . . . . . . . . . . . . . . . . . 6
5. Computed Data . . . . . . . . . . . . . . . . . . . . . . . 7
6. Overview of Operation . . . . . . . . . . . . . . . . . . . 8
7. Conference Creation and Termination . . . . . . . . . . . . 9
8. User Additions and Expels . . . . . . . . . . . . . . . . . 10
9. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 11
10. Structure of a Conference Policy document . . . . . . . . . 12
11. Structure of XML Document . . . . . . . . . . . . . . . . . 13
11.1 <Conference-URI> element . . . . . . . . . . . . . . . . . . 13
11.2 <Conference-info> element . . . . . . . . . . . . . . . . . 13
11.3 <Conference-time> element . . . . . . . . . . . . . . . . . 14
11.4 <PCL> (Privilege Control List) element . . . . . . . . . . . 15
11.5 <SC> (Security Control) element . . . . . . . . . . . . . . 16
11.6 <DL> (Dial-Out List) element . . . . . . . . . . . . . . . . 18
11.7 <ACL> (Access Control List) element . . . . . . . . . . . . 18
11.8 <Floor-control> element . . . . . . . . . . . . . . . . . . 20
11.9 <Media-Policy> element . . . . . . . . . . . . . . . . . . . 20
12. Additional Constraints . . . . . . . . . . . . . . . . . . . 21
13. Authorization Policies . . . . . . . . . . . . . . . . . . . 22
14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 23
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 28
16. Security Considerations . . . . . . . . . . . . . . . . . . 31
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
17.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . . 32
17.2 application/conference-policy+xml mime TYPE . . . . . . . . 32
17.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-policy . . . . . . . . . . 33
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
Normative References . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . 38
Koskelainen & Khartabil Expires December 19, 2003 [Page 2]
Internet-Draft XCAP CPCP June 2003
1. Introduction
SIP conferencing framework [10] defines the mechanisms for
multi-party centralized conferencing in SIP environment. Existing SIP
mechanisms allow users e.g. to join and leave a conference.
Centralized server (called focus) can expel and invite users, and
have proprietary access control lists and privilege definitions.
However, in many cases it is useful to have standardized conference
policy elements (such as access control lists) and the standardized
protocol means to manipulate them as defined in conference policy
control protocol requirements [7] (CPCP) document. This document
provides both standardized conference policy elements and XCAP usage
to manipulate them.
Other mechanisms, such as web page or voice response system can also
be used to manipulate conference policy data. However, these
solutions are not appropriate due to lack of interoperability. This
document provides an XCAP [8] application usage to solve these
issues.
XCAP is a HTTP 1.1 based protocol that allows clients to read, write,
modify and delete application elements at a server. One application
area which has already adopted XCAP is the manipulation of presence
lists [9].
XCAP has many advantages to be used for conference policy control
protocol. First, it is very simple which is important e.g. in
wireless environments. It is already in use for presence list
manipulation and it is expected that clients supports both
applications. Now they can use same protocol for these purposes.
Koskelainen & Khartabil Expires December 19, 2003 [Page 3]
Internet-Draft XCAP CPCP June 2003
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.
Koskelainen & Khartabil Expires December 19, 2003 [Page 4]
Internet-Draft XCAP CPCP June 2003
3. Terminology
ACL
Access control list (ACL) defines users who can join to a
conference. Users may have allow, blocked or pending status in
the list. Each conference has its own ACL.
CPS
Conference Policy Server. See [10]
Conference participant
Conference participant is a user who has on-going session (e.g.
SIP dialog) with the conference focus.
Floor control
Floor control is a mechanism that enables applications or users
to gain safe and mutually exclusive or non-exclusive access to
the shared object or resource in a conference.
Dial-Out List (DL)
Dial-out list (DL) is a list of users who the focus needs to
invite to the conference.
PCL
Privilege control control (PCL) defines privileges for a user.
Each user in a conference may have different list of privileges
and each conference has its own PCL.
Koskelainen & Khartabil Expires December 19, 2003 [Page 5]
Internet-Draft XCAP CPCP June 2003
4. Application Unique ID
XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or a vendor tree. This
specification defines the "conference-policy" AUID within the IETF
tree, via the IANA registration in Section 17.
Koskelainen & Khartabil Expires December 19, 2003 [Page 6]
Internet-Draft XCAP CPCP June 2003
5. Computed Data
Conference server must fill the conference URI and return it in the
response when the conference is created, if the conference URI was
not proposed by the client.
Koskelainen & Khartabil Expires December 19, 2003 [Page 7]
Internet-Draft XCAP CPCP June 2003
6. Overview of Operation
This document assumes that the user knows the location (URI) of
conference policy server, the details of that discovery are beyond
the scope of this document.
CPCP is implemented as an XCAP application usage, similarly to
presence list manipulation which is also using XCAP.
CPCP allows clients to manipulate the conference policy at conference
policy server (CPS). CPS is able to inform the focus, if necessary.
For example, if new users are added to the dial-out list, then
conference policy server informs the focus which makes the invites as
requested.
Some assumptions about the conferencing architecture are made.
Clients always connect to the conference policy server (CPS) when
they perform XCAP operations. It is assumed that CPS informs other
conferencing entities, such as focus, floor control server and mixer
directly or via focus. For example, when user expels another user via
XCAP based CPCP, then it must first manipulate policy data in CPS
which then asks the focus to perform the operation. The communication
between different (logical) conferencing elements are beyond the
scope of this document. It can be expected that in most cases CPS
performs also those logical functions.
OPEN ISSUE: Does focus ever need to update conference policy? (maybe
in some cases)
Conference factory applications may also use CPCP to create the
conference, receive the conference URI, then redirect the conference
creator to the conference URI.
Ad-hoc conferences may also became CPCP-controlled. In this case, the
creator of the original ad-hoc conference (the one who sent initial
INVITE) has all privileges.
OPEN ISSUE: Is this needed? (ad-hoc conf becames CPCP-controlled)
Koskelainen & Khartabil Expires December 19, 2003 [Page 8]
Internet-Draft XCAP CPCP June 2003
7. Conference Creation and Termination
Conference is identied by a conference URI which is hosted by the
server (CPS).
A user may create a new conference at the CPS by using HTTP POST.
Depending on server policy and user privileges, CPS may accept the
creation.
Conference (and its resources) can be deleted permanently using HTTP
DELETE. When the user deletes a conference, CPS MUST also delete all
its subconferences ("sidebars") at a server.
Conference sidebars are separate (independent) URIs at the server.
Koskelainen & Khartabil Expires December 19, 2003 [Page 9]
Internet-Draft XCAP CPCP June 2003
8. User Additions and Expels
User with sufficient privileges (users with
RIGHT_TO_DO_USER_MANAGEMENT privilege) is allowed to perform user
management operations, such as adding (deleting) user to (from) the
conference. These commands are sent to the conference policy server.
After ensuring that the manipulation command came from the privileged
user, conference policy server asks the focus to perform the
indicated operation (SIP INVITE or SIP BYE).
Invite operation is achieved with HTTP POST. This modifies Dial-Out
List and CPS triggers the focus to send the SIP INVITE(s) as needed.
Expel operation uses POST as well, as user is put to ACL list with
Blocked action. Similarly to Invite, this trigger CPS to inform the
focus about the need to issue a SIP BYE.
Koskelainen & Khartabil Expires December 19, 2003 [Page 10]
Internet-Draft XCAP CPCP June 2003
9. Naming Conventions
There are no naming conventions that need to be defined for this
application usage.
Koskelainen & Khartabil Expires December 19, 2003 [Page 11]
Internet-Draft XCAP CPCP June 2003
10. Structure of a Conference Policy document
Conference policy document is an XML [5] document that MUST be
well-formed and SHOULD be valid. Conference policy 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
documents and document fragments. The namespace URI for elements
defined by this specification is a URN [2], using the namespace
identifier 'ietf' defined by [3] and extended by [11]. This URN is:
urn:ietf:params:xml:ns:conference-policy
A conference policy document begins with the root element tag
``conference-policy''. It consists of one mandatory element
"conference." Other elements from different namespaces MAY be present
for the purposes of extensibility; elements or attributes from
unknown namespaces MUST be ignored. Conference element includes
following sub-elements:
Conference-info: This mandatory sub-element includes informational attributes
describing the conference, e.g. for search purposes and to be included
into dial-out session descriptions.
Conference-time: This mandatory sub-element includes information related
to conference duration.
ACL: This is mandatory sub-element for access control list.
PCL: This is mandatory sub-element for privilege control list.
DL: This is mandatory sub-element for dial-out list.
SC: This is mandatory sub-element for security control.
Conference-media-policy: This is mandatory sub-element for conference media policy.
The attributes are described in more detail in forthcoming sections.
Koskelainen & Khartabil Expires December 19, 2003 [Page 12]
Internet-Draft XCAP CPCP June 2003
11. Structure of XML Document
11.1 <Conference-URI> element
Conference is identified by the conference URI, which is allocated by
the conference policy server and returned to the client. It is also
possible that client proposes a new name by itself (e.g.
sip:discussion-on-dogs@example.com) as it may be useful to have
human-friendly name in some cases. Server still decides whether it
gives the name proposed by the client. Conference URI can be SIP,
SIPS, or TEL URI. Conference policy server creates the focus for the
conference when the conference instance starts.
<Conference-URI> is a mandatory element and it cannot be changed
during the conference lifetime.
Conference may be deleted so that conference URI and policy are
deleted permanently (using HTTP DELETE). Conference instance may also
be terminated temporarily, e.g. so that conference URI and policy
remain at the server but conference is no longer active (modifying
conference end-time).
11.2 <Conference-info> element
<Conference-Info> element includes informative conference paramaters
which may be helpful describing the purpose of conference, e.g. for
search purposes or providing contact information for the host.
Each conference has an optional <Subject> element, which describes
the current topic in a conference. The optional <Display-Name>
element is the display name of the conference, which usually does not
change over time.
<Free-Text> and <Keywords> are optional elements. They provide
additional textual information about the conference. This information
can be made available to the conference participants or to everyone
interested by means not specified here. Examples of usage could be
searching for a conference based on some keywords, providing
additional information to tentative conference participants etc.
Optional <Host-Info> element contains several sub-elements. It gives
additional information about the user who is hosting the conference.
This information can be be included into SDP fields in SIP INVITEs
sent by the focus. <SIP-uri> element is mandatory, while <TEL-uri>,
<Web-page> and <E-mail> are optional. Note that the conference host
is not necessarily the same as the conference moderator.
Koskelainen & Khartabil Expires December 19, 2003 [Page 13]
Internet-Draft XCAP CPCP June 2003
11.3 <Conference-time> element
OPEN ISSUE: Do we need times, maybe just relative time and whether it
can be extended or not. If there is separate scheduling application
for future conference reservations, how it is controlled?
The information related to conference time and lifetime is contained
in the <Conference-Time> element. The conference may occur only once
for a limited period of time (i.e. it has a limited lifetime), the
conference may be non-bounded (i.e. it does not have a specified end
time), or the conference may be permanent. Bounded conferences may be
repeated after some time interval (e.g. on weekly basis).
<Conference-Time> contains one or more <Conference-Occurrences each
defining the time information of a single conference occurrence.
Multiple <Conference-Occurrence> elements MAY be used if a conference
is active at multiple irregularly spaced times; each additional
<Conference-Occurrence> element contains time information for a
specific occurrence.
For each occurrence, the <Start-time> and <Stop-time> specify start
and stop times for when a conference is active. For example, for a
conference that is to be repeated once on a different time, one
<Conference-Occurrence> could define the conference to be active at
10am on Monday until 11am on Monday, while the second
<Conference-Occurence> defines the conference to active at 11am on
Tuesday until 1pm on Tuesday.
If the conference is active at regular times, a <Repeat> element
should be used in addition to and following <Start-time> and
<Stop-time> elements - in which case the <Start-time> and <Stop-time>
elements specify the start and stop times of the repeat sequence.
If the <Stop-time> is set to zero, then the session is not bounded,
though it will not become active until after the <Start-time>. If
the <Start-time> is also zero, the session is regarded as permanent.
<Repeat-interval> element specifies repeat times for a conference.
For example, if a conference is active at 10am on Monday and 11am on
Tuesday for one hour each week for three months, then the
<Start-time> would be 10am on the first Monday, the <Repeat-interval>
would be 1 week, the <Active-duration> would be 1 hour, and the
offsets <Offsets-from-start-time> would be zero and 25 hours. The
corresponding <Stop-time> would be the end of the last session three
months later. In this example, the information is contained within a
single <Conference-Occurrence element>.
By default all repeat attributes are in seconds.
Koskelainen & Khartabil Expires December 19, 2003 [Page 14]
Internet-Draft XCAP CPCP June 2003
11.4 <PCL> (Privilege Control List) element
Many kind of operations can be performed in a conference so there
must be a mechanism that controls who are allowed to perform which
operation. In the simplest case, one user - often called as a
moderator - has the right to perform any operation available. In
other cases, it may be useful to define e.g. that some users are
allowed to expel users but not perform any other operations.
Therefore, conferencing framework supports the idea of privileges.
Privilege is a temporary user right to perform an operation.
Conference may have at least the following privileges:
RIGHT_TO_CREATE_CONFERENCE
RIGHT_TO_TERMINATE_CONFERENCE
RIGHT_TO_MANIPULATE_GENERAL_PARAMETERS
RIGHT_TO_DO_USER_MANAGEMENT
RIGHT_TO_MANIPULATE_MEDIA_POLICY
RIGHT_TO_CONNECT_DISCONNECT_STREAMS
RIGHT_TO_MANIPULATE_SIDEBAR
RIGHT_TO_MANIPULATE_OWN_MEDIA_POLICY
RIGHT_TO_MANIPULATE_PRIVILEGES
RIGHT_TO_MANIPULATE_FLOOR_POLICY
Explanations:
RIGHT_TO_CREATE_CONFERENCE: Users with this privilege can create a
new conference at a server.
RIGHT_TO_TERMINATE_CONFERENCE: Users who have this privilege may
terminate (delete) current conference by using CPCP.
RIGHT_TO_MANIPULATE_GENERAL_PARAMETERS: Users who have this privilege
can manipulate general parameters, e.g. conference time, Subject etc.
RIGHT_TO_DO_USER_MANAGEMENT: Users who have this privilege are
allowed to ask the focus to invite and expel users.
RIGHT_TO_MANIPULATE_MEDIA_POLICY: Users who have this privilege may
manipulate the media part of conference policy by using CPCP.
RIGHT_TO_MANIPULATE_OWN_MEDIA_POLICY: User who have this privilege is
allowed to manipulate his or her own media policy.
RIGHT_TO_MANIPULATE_PRIVILEGES: Users who have this privilege may
give (or take away) a privilege to another user by using CPCP. After
Koskelainen & Khartabil Expires December 19, 2003 [Page 15]
Internet-Draft XCAP CPCP June 2003
succesful completion of this command, conference policy has the new
information. It is up to the conference focus to send a notification
and inform the user who got the new privilege.
RIGHT_TO_MANIPULATE_FLOOR_POLICY: Users who have this privilege are
allowed to create floors and assign floor moderators (using floor
control protocol) for all media sessions within the conference.
Initial privileges are defined when the conference is originally
created. Privileges may be handed over to other users and they can be
taken away. Also users outside of conference may hold a privilege.
Problematic situations might be possible, such as nobody in a
conference has any privileges. These kind of situations are
impossible to completely avoid. However, as a backup mechanism, the
conference creator or at least one user has always the
RIGHT_TO_GIVE_PRIVILEGE privilege. Moreover, conference service (or
server) may have server-specific backup rules, e.g. server
administrator may be manually involved, if necessary.
It is necessary to control the information which users have
privileges. Therefore, ACL-like Privilege Control List (PCL) is
introduced as a policy data element. It includes target URI (possibly
wildcarded) followed by the list of privileges.
Example PCL looks like this:
sip:bob@example.com: RIGHT_TO_EXPEL, RIGHT_TO_MANIPULATE_FLOOR_POLICY
sip:*@example.com: RIGHT_TO_EXPEL
sip:alice@company.com: RIGHT_TO_TERMINATE_CONFERENCE
User can fetch the PCL from the conference policy server by using
HTTP GET as it is part of conference policy.
New privileges can be added to a user by using a HTTP POST operation
for a given subtree and privilege can be taken away using HTTP
DELETE. These commands can be succesfully performed only by those
users who themselves have the required privilege
(RIGHT_TO_MANIPULATE_PRIVILEGES).
11.5 <SC> (Security Control) element
The conference security encompasses three aspects: controlling the
visibility of a conference, securing the SIP messages, and performing
authentication for individual users.
The mandatory <Visibility> element controls whether the conference is
visible to others than users participating in a conference. This
element may have two values: "Visible" and "Invisible". If
Koskelainen & Khartabil Expires December 19, 2003 [Page 16]
Internet-Draft XCAP CPCP June 2003
<Visibility> is set to "Invisible" then the conference policy server
should not reveal any information about the conference to others than
partipants.
We define two mechanisms for securing the signalling dialogs between
users and the conference policy server: TLS and S/MIME.
TLS is used to provide transport layer security on a hop-by-hop
basis. According to SIP [6], using SIPS URI scheme in a request
signifies that TLS must be used to secure each hop over which the
request is forwarded until the request reaches the SIP entity
responsible for the domain portion of the Request-URI.
When the mandatory <Security-Mechanism> in the conference policy has
a value "TLS=true" (thus implying the use of SIPS URI scheme), it is
required that TLS is used end-to-end. In other words, TLS must be
used also on the last hop between the entity responsible for the
domain portion of the Request-URI and the conference policy server.
If end-to-end confidentiality of entire SIP messages is not required
in the conference policy, but it is required that the message bodies
within SIP are encrypted, the <Security-Policy> element must have a
value "S/MIME=true".
TLS and S/MIME may be required independent of each other. In other
words, it may be requred to use neither, one, or both depending on
the settings of these parameters.
The conference creator may optionally define the authentication
policy for individual participants. Mechanisms used for this are
defined in the <Authorization-mechanism> element. The only defined
authorization mechanism in this document is HTTP Digest.
The value of the <Authorization-mechanism> element may be either
"Digest" indicating HTTP Digest authentication, or "none" indicating
that no authentication is required. The password associated with each
user in the Digest authentication is included in the optional
<Password> attribute. This attribute is ignored if authentication is
set to "none".
Each target URI in the SC list is also associated with a <Visibility>
element that defines whether the participant is visible to other
users. The relationship of this attribute and the the <Visibility>
element affecting the whole conference is as follows:
- Conference visible, participant visible: participant is visible to everyone
- Conference visible, participant invisible: participant is invisible to everyone
Koskelainen & Khartabil Expires December 19, 2003 [Page 17]
Internet-Draft XCAP CPCP June 2003
- Conference invisible, participant visible: participant is visible to the conference
participants
- Conference invisible, participant invisible: participant is invisible to everyone
11.6 <DL> (Dial-Out List) element
The purpose of a dial-out list (DL) in a conference is to trigger the
focus to invite users in (e.g. due to charging reasons). This list
can be updated during the conference lifetime so it can be used for
mid-conference invites (and mass-invites) as well.
DL includes list of users (wildcards not allowed) and list of
parameters for each user. Focus does not update the DL, so the
existing DL users remain in the DL until they are removed (using
DELETE).
DL includes two parameters for each user in the list: the repeat time
(how many times user is called), and the interval between the call
attempts. Repeat time zero (0) means that call attempts are tried
indefinitely.
OPEN ISSUE: Are repeat/interval parameters needed? (or just let the
server to decide?)
Example DCL looks like:
sip:bob@example.com: 30, 5-minutes
tel:tim@example2.com: 3, 1-minutes
Two operations can be performed for DL: Add new entry (URI) using
HTTP POST, and Delete current entry using HTTP DELETE. The latter
means that the user is removed from the DL and not called anymore.
11.7 <ACL> (Access Control List) element
The purpose of Access Control List (ACL) is to control who can join
the conference. Conference has one ACL consisting the target and the
action for the target. The target is user URI (or wildcarded user
URI). Action is one of Allowed/Blocked/Pending. Allowed means that
the target is allowed to join the conference. Blocked means the
opposite and pending means that the target is put on hold while
further processing - such as consulting the moderator - takes places.
Example ACL would look like this:
sip:bob@example.com: allowed
sip:*@example.com: blocked
sip:*@company.com: pending
Koskelainen & Khartabil Expires December 19, 2003 [Page 18]
Internet-Draft XCAP CPCP June 2003
ACL must have default rule for those targets that no matching rule is
found (i.e. "pending" action for those targets not found in the
list).
Wildcards can be used for whole user part only, not parts of it. For
example, "sip:*@example.com" is a valid target while
"sip:b*@example.com" is not.
Sip: and sips: schemes are treated equally for the same person as ACL
identifies users, not transport methods or authentication
requirements.
"Most specific expression wins" policy is used if overlapping rules
are found. Basically, this means that user specific rule is searched
first and if it is not found, then most specific wildcard rule is
utilized.
OPEN ISSUE: What kind of wildcard policy for domain part? Must be
limited somehow in order to prevent too complicated and overlapping
rules. Proposal: Don't allow it at all, or allow it only immediately
after "@"-sign. For example, "sip:bob@*.com" is a valid target while
"sip:bob@example.*" is not. A: Don't Allow wildcards in domain part.
Following operations exist for ACL:
Allow(list of targets)
Block(list of targets)
Pending(list of targets)
Delete(target)
First three commands create a new (or change existing) rule for the
list of targets (user URIs or wildcarded user URIs). They can also
remove unnecessary rules, e.g. if bob@example.com and tom@example.com
are already blocked when new rule defining that *@example.com is
blocked is performed, user specific rules can be safely removed.
HTTP POST is used for Allow/Block/Pending operations and HTTP DELETE
is used for the last operation. HTTP PUT is used to modify ACL for
the target who already exists in ACL.
Delete copes with (potential) ACL size problem. 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 rewritten,
though). This leads easily to the situation in which the ACL includes
huge amount of unnecessary rules which are not really needed anymore.
Therefore, there should be a mechanism to delete ACL. Conference
focus may send a notification which warns that the size of ACL has
increased local limit.
Koskelainen & Khartabil Expires December 19, 2003 [Page 19]
Internet-Draft XCAP CPCP June 2003
New rule always overrides the old rule. It is server's responsibility
to ensure this. This guarantees that conflicting rules do not exist
(e.g. both allowed and blocked action is defined for same target) and
the order in which ACL is searched is irrelevant.
Blocking user also expels user from the current conference.
11.8 <Floor-control> element
Floor control in a conference is performed using Floor Control
Protocol (FCP). CPCP only controls via privileges who are allowed to
manipulate floor policy (e.g. create and delete floors). FCP can then
be used to create floor, and assign and de-assign floor moderator for
a given floor. For example, in a typical conference the conference
creator (moderator) first creates a floor for audio plane (using FCP)
and then names one user - possibly himself - (using FCP) to act as a
floor moderator governing the access to the floor. Note that FCP does
not create media streams (just the virtual floor attached to media),
as media streams are created using CPCP.
When the floor has been created and floor moderator has been
assigned, the floor moderator gets notifications from the focus and
is able to accept or deny floor requests (using FCP) from the
conference users. The details of FCP are beyond the scope of this
draft.
User with privilege RIGHT_TO_MANIPULATE_FLOOR_POLICY can create the
floors and assign floor moderator using FCP.
11.9 <Media-Policy> element
Media policy is integral part of the conference policy. It defines
e.g. what kind of media topologies exist in the conference. The
details of media manipulation are defined elsewhere
(draft-mahy-sipping-media-policy-control-00.txt). User with
sufficient privileges (RIGHT_TO_MANIPULATE_MEDIA_POLICY) is allowed
to create, modify and delete media policy (e.g. add new media
sessions).
Koskelainen & Khartabil Expires December 19, 2003 [Page 20]
Internet-Draft XCAP CPCP June 2003
12. Additional Constraints
None.
Koskelainen & Khartabil Expires December 19, 2003 [Page 21]
Internet-Draft XCAP CPCP June 2003
13. Authorization Policies
If the conference is "visible" (as defined in conference policy) then
anybody can read the policy using HTTP GET. The policy may also be
available for search engines etc. If the conference is "invisible",
then only current participants and users with special privilege (e.g.
RIGHT_TO_DO_USER_MANAGEMENT) can read the policy.
OPEN ISSUE: Do we need new privilege which defines whether user is
allowed to read conference policy? (probably no, current privileges
are ok)
OPEN ISSUE: Do we need to define that e.g. ACL is not shown in
visible conferences
OPEN ISSUE: Who can subscribe to the event package? (if visible, then
anybody; if invisible, then only current participants and users with
special privilege?)
User with sufficient privileges can modify the relevant parts of the
document. For example, user with privilege
RIGHT_TO_MANIPULATE_FLOOR_POLICY can modify floor policy part of the
conference policy.
Koskelainen & Khartabil Expires December 19, 2003 [Page 22]
Internet-Draft XCAP CPCP June 2003
14. XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-policy"
xmlns="http://www.ietf.org"
elementFormDefault="qualified">
<! Define the visibility as data type with two possible values>
<xsd:simpleType name="Visibility-type"/>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="visible"/>
<xsd:enumeration value="invisible"/>
</xsd:restriction>
</xsd:simpleType>
<! Define the privileges as data type with all possible values>
<xsd:simpleType name="Privileges-values"/>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="RIGHT_TO_EXPEL_USER"/>
<xsd:enumeration value="RIGHT_TO_TERMINATE_CONFERENCE"/>
<xsd:enumeration value="RIGHT_TO_DO_USER_MANAGEMENT"/>
<xsd:enumeration value="RIGHT_TO_MANIPULATE_MEDIA_POLICY"/>
<xsd:enumeration value="RIGHT_TO_GIVE_PRIVILEGE"/>
<xsd:enumeration value="RIGHT_TO_TAKE_PRIVILEGE_AWAY"/>
<xsd:enumeration value="RIGHT_TO_MANIPULATE_FLOOR_POLICY"/>
</xsd:restriction>
</xsd:simpleType>
<! Define the privileges as list in order to include many in >
<! same declaration>
<xsd:simpleType name="Privilege-type">
<xsd:list itemType="Privileges-values"/>
</xsd:simpleType>
<! Define the list of keywords>
<xsd:simpleType name="Keyword-type">
<xsd:list itemType="xsd:string"/>
</xsd:simpleType>
<! Define the list of Offsets values>
<xsd:simpleType name="Offset-type">
<xsd:list itemType="xsd:nonNegativeInteger"/>
Koskelainen & Khartabil Expires December 19, 2003 [Page 23]
Internet-Draft XCAP CPCP June 2003
</xsd:simpleType>
<! Define the types of Access modes>
<xsd:simpleType name="Access-mode">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Allowed"/>
<xsd:enumeration value="Blocked"/>
<xsd:enumeration value="Pending"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="Conference">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Conference-URI" use="required"/>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SIP-URI" type="xsd:anyURI"
use="required"/>
<xsd:element name="TEL-URI"
type="xsd:anyURI"/>
<xsd:sequence>
</xsd:complexType>
<xsd:element ref="Conference-info" use="required"/>
<xsd:element ref="Conference-time" use="required"/>
<xsd:element ref="ACL" use="required"/>
<xsd:element ref="PCL" use="required"/>
<xsd:element ref="DL" use="required"/>
<xsd:element ref="SC" use="required"/>
<xsd:element ref="Conference-floor-policy"
use="required"/>
<xsd:element ref="Conference-media-policy"
use="required"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Conference-info">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Subject" type="xsd:string"/>
<xsd:element name="Display-name" type="xsd:string"/>
<xsd:element name="Free-text" type="xsd:string"/>
<xsd:element name="Keywords" type="Keyword-type"/>
<xsd:element name="Host-info">
<xsd:complexType>
<xsd:sequence>
Koskelainen & Khartabil Expires December 19, 2003 [Page 24]
Internet-Draft XCAP CPCP June 2003
<xsd:element name="SIP-URI"
type="xsd:anyURI" use="required"/>
<xsd:element name="TEL-URI"
type="xsd:anyURI"/>
<xsd:element name="E-mail"
type="xsd:anyURI"/>
<xsd:element name="Web-page"
type="xsd:anyURI"/>
<xsd:sequence>
<xsd:sequence>
<xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Conference-time">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Conference-occurrence"/>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Start-time"
type="xsd:dateTime"/>
<xsd:element name="Repeat"/>
<xsd:complexType>
<xsd:attribute name="Interval"
type="xsd:nonNegativeInteger"/>
<xsd:attribute name="Active-duration"
type="xsd:nonNegativeInteger"/>
<xsd:attribute name="Offsets"
type="Offset-type"/>
</xsd:complexType>
<xsd:element name="Stop-time"
type="xsd:dateTime"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<! Access Control List (ACL)>
<xsd:element name="ACL">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ACL-target-URI" type="xsd:anyURI"
Koskelainen & Khartabil Expires December 19, 2003 [Page 25]
Internet-Draft XCAP CPCP June 2003
use="required" minOccurs="1" maxOccurs="unbounded"/>
<xsd:complexType>
<xsd:attribute name="Access-type"
type="Access-mode"/>
</xsd:complexType>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<! Privilege Control List (PCL)>
<xsd:element name="PCL">
<xsd:element name="PCL-target" minOccurs="1"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PCL-target-URI" type="xsd:anyURI"
use="required"/>
<xsd:element name="Privileges"
type="Privilege-type"/>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:element>
<! Dial-Out List (DL)>
<xsd:element name="DL">
<xsd:element name="DL-target" minOccurs="1"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="DL-target-URI"
type="xsd:anyURI" use="required"/>
<xsd:element name="Delay"
type="xsd:nonNegativeInteger" use="required"/>
<xsd:element name="Repetitions"
type="xsd:nonNegativeInteger" use="required"/>
<xsd:element name="Repetition-interval"
type="xsd:nonNegativeInteger" use="required"/>
</xsd:sequence>
</xsd:complexType>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:element>
Koskelainen & Khartabil Expires December 19, 2003 [Page 26]
Internet-Draft XCAP CPCP June 2003
<! Security Control (SC)>
<xsd:element name="SC">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Visibility" type="Visibility-type"
use="required"/>
<xsd:element name="Security-mechanism">
<xsd:complexType>
<xsd:attribute value="TLS"
type="xsd:boolean" default="false"/>
<xsd:attribute value="S-MIME"
type="xsd:boolean" default="false"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="SC-target" minOccurs="1"
maxOccurs="unbounded"/>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SC-target-URI"
type="xsd:anyURI" use="required"/>
<xsd:element name="Visibility"
type="Visibility-type" use="required"/>
<xsd:element name="Authorization-mechanism">
<xsd:complexType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Digest"/>
<xsd:enumeration value="None"/>
</xsd:restriction>
<xsd:attribute name="Password"
type="xsd:string"/>
</xsd:complexType>
</xsd:sequence>
</xsd:complexType>
<xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Koskelainen & Khartabil Expires December 19, 2003 [Page 27]
Internet-Draft XCAP CPCP June 2003
15. Examples
The following is an example of a document compliant to the schema:
Below is an example how to create a conference:
Example 1. Creating a Conference
Alice creates a conference as follows:
PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml HTTP/1.1
Content-Type:application/conference-policy+xml
<?xml version="1.0" encoding="UTF-8"?>
<Conference xmlns="urn:ietf:params:xml:ns:conference-policy">
<Conference-URI>
<SIP-URI></SIP-URI>
<TEL-URI></TEL-URI>
</Conference-URI>
<Conference-info>
<Subject>What's happening tonight</Subject>
<Display-name>Party Goer's</Display-name>
<Free-text>John and Peter will join the conference soon</Free-text>
<Keywords>party nightclub beer</Keywords>
<Host-info>
<SIP-URI>sip:Alice@example.com</SIP-URI>
<TEL-URI>tel:+358401111111</TEL-URI>
<E-mail>mailto:Alice@example.com</E-mail>
<Web-page>http://www.example.com/users/Alice</Web-page>
</Host-info>
</Conference-info>
<Conference-time>
<Conference-occurrence>
<Start-time>2003-06-16T10:00:00Z</Start-time>
<Repeat interval="604800" Active-duration="3600" offsets="0 90000"/>
<Stop-time>2003-09-16T12:00:00Z</Stop-time>
</Conference-occurrence>
</Conference-time>
<ACL>
<ACL-target-URI Access-type="Allowed">sip:*@example.com</ACL-target-URI>
<ACL-target-URI Access-type="Blocked">sip:*@*</ACL-target-URI>
</ACL>
<PCL>
<PCL-target>
<PCL-target-URI>sip:Alice@example.com</PCL-target-URI>
<Privileges>RIGHT_TO_EXPEL_USER RIGHT_TO_TERMINATE_CONFERENCE RIGHT_TO_DO_USER_MANAGEMENT
RIGHT_TO_MANIPULATE_MEDIA_POLICY RIGHT_TO_GIVE_PRIVILEGE
Koskelainen & Khartabil Expires December 19, 2003 [Page 28]
Internet-Draft XCAP CPCP June 2003
RIGHT_TO_TAKE_PRIVILEGE_AWAY RIGHT_TO_MANIPULATE_FLOOR_POLICY</Privileges>
</PCL-target>
<PCL-target>
<PCL-target-URI>sip:*@example.com</PCL-target-URI>
<Privileges>RIGHT_TO_EXPEL_USER RIGHT_TO_DO_USER_MANAGEMENT</Privileges>
</PCL-target>
<PCL-target>
<PCL-target-URI>sip:*@*</PCL-target-URI>
<Privileges>RIGHT_TO_EXPEL_USER</Privileges>
</PCL-target>
</PCL>
<DL>
<DL-target>
<DL-target-URI>sip:alice@operator.com</DL-target-URI>
<Delay>0</Delay>
<Repetitions>3</Repetitions>
<Repetition-interval>300</Repetition-interval>
</DL-target>
<DL-target>
<DL-target-URI>sip:sarah@operator.com</DL-target-URI>
<Delay>0</Delay>
<Repetitions>3</Repetitions>
<Repetition-interval>300</Repetition-interval>
</DL-target>
</DL>
<SC>
<Visibility>visible</Visibility>
<Security-mechanism TLS="false" S-MIME="true"/>
<SC-target>
<SC-target-URI>sip:*@example.com</SC-target-URI>
<Visibility>visible</Visibility>
<Authorization-mechanism password="1a2b3c4d">Digest<Athorization-mechanism>
</SC-target>
</SC>
<Conference-floor-policy>
</Conference-floor-policy>
<Conference-media-policy>
</Conference-media-policy>
</Conference>
At exactly 2003-06-16T10:00:00Z, the conference server creates a focus and sends
SIP INVITE requests to Alice and Sarah. After the focus is created, SIP INVITE
requests can be accepted from anyone at domain example.com. Any attempts to join
the conference by users in other domains are rejected.
Example 2. Expelling a User
Continuing with the above example: aftar the conference has started, Alice decides
Koskelainen & Khartabil Expires December 19, 2003 [Page 29]
Internet-Draft XCAP CPCP June 2003
to expel Bob who has joined the conference. So she adds him to the ACL list with
Access-type of value "Blocked".
OPEN ISSUE: Should there be a attribute defining how long someone should be
expelled for?
The XCAP request looks like:
POST http://xcap.example.com/services/conferences/users/Alice/conference.xml?
Conference/ACL/ACL-target-URI HTTP/1.1
Content-Type:text/plain
<ACL-target-URI Access-type="Blocked">sip:bob@example.com</ACL-target-URI>
At this point, the focus sends a SIP BYE request to Bob ending Bob's participation
in the conference. This also guarantees that Bob cannot rejoin the conference since
he is expilictly blocked until his URI is removed from the ACL blocked list.
Any attempt Bob makes in rejoining the conference will fail.
Example 3. Allowing An Expelled Participant To Join Again
Continuing with the example above, Alice now decides to allow Bob to join again
after a period of time. She does so by removing his entry in the ACL that identifies
him as "Blocked
DELETE http://xcap.example.com/services/conferences/users/Alice/conference.xml?
Conference/ACL/ACL-target-URI/ACL-target-URI="sip:bob@example.com" HTTP/1.1
Bob can now rejoin the conference by sending a SIP INVITE request.
Example 4. Removing A Conference
Alice now decides she no longer wants this conference to exist and therefore
deletes the conference:
DELETE http://xcap.example.com/services/conferences/users/Alice/conference.xml
As a result of this action, the focus sends SIP BYE requests to all current
participants in the conference. The conference server terminates the focus
thereafter.
Koskelainen & Khartabil Expires December 19, 2003 [Page 30]
Internet-Draft XCAP CPCP June 2003
16. Security Considerations
See section Section 11.5.
Koskelainen & Khartabil Expires December 19, 2003 [Page 31]
Internet-Draft XCAP CPCP June 2003
17. IANA Considerations
17.1 XCAP Application Usage ID
This section registers a new XCAP Application Usage ID (AUID)
according to the IANA procedures defined in..
Name of the AUID: conference-policy
Description: Conference policy application manipulates conference
policy at a server.
17.2 application/conference-policy+xml mime TYPE
MIME media type: application
MIME subtype name: conference-policy+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter applicatioN/xml as
specified in RFC 3023 [6].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [6].
Security considerations: See section 10 of RFC 3023 [6] and section
Section 17 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.
Additional information:
Magic number: None
File extension: .cl or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Petri Koskelainen
(petri.koskelainen@nokia.com)
Koskelainen & Khartabil Expires December 19, 2003 [Page 32]
Internet-Draft XCAP CPCP June 2003
Intended Usage: COMMON
Author/change controller: The IETF
17.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-policy
This section registers a new XML namespace, as per guidelines in URN
document [11].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-policy.
Registrant Contact: IETF, XCON working group, Petri Koskelainen
(petri.koskelainen@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
Koskelainen & Khartabil Expires December 19, 2003 [Page 33]
Internet-Draft XCAP CPCP June 2003
18. Contributors
Jose Costa-Requana
Simo Veikkolainen
Teemu Jalava
Koskelainen & Khartabil Expires December 19, 2003 [Page 34]
Internet-Draft XCAP CPCP June 2003
19. Acknowledgements
The authors would like to thank Markus Isom„ki and IETF conferencing
design team for their feedback.
Koskelainen & Khartabil Expires December 19, 2003 [Page 35]
Internet-Draft XCAP CPCP June 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[4] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC
3261, June 2002.
[5] 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.
[6] Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[7] Koskelainen, P., "Requirements for conference policy control
protocol", draft-koskelainen-xcon-cpcp-req-00 (work in
progress), June 2003.
[8] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-rosenberg-simple-xcap-00 (work in progress), May 2003.
[9] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence Lists",
draft-draft-rosenberg-simple-xcap-list-usage-00 (work in
progress), May 2003.
[10] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-rosenberg-sipping-conferencing-framework-01 (work in
progress), February 2003.
[11] Mealling, M., "Forward Error Correction (FEC) Building Block",
draft-mealling-iana-xmlns-registry-04 (work in progress), July
2002.
Koskelainen & Khartabil Expires December 19, 2003 [Page 36]
Internet-Draft XCAP CPCP June 2003
Authors' Addresses
Petri Koskelainen
Nokia
P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721
Finland
EMail: petri.koskelainen@nokia.com
Hisham Khartabil
Nokia
P.O. Box 321
Helsinki FIN-00045
Finland
EMail: hisham.khartabil@nokia.com
Koskelainen & Khartabil Expires December 19, 2003 [Page 37]
Internet-Draft XCAP CPCP June 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Koskelainen & Khartabil Expires December 19, 2003 [Page 38]
Internet-Draft XCAP CPCP June 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Koskelainen & Khartabil Expires December 19, 2003 [Page 39]