draft-ietf-xcon-cpcp-00.txt   draft-ietf-xcon-cpcp-01.txt 
XCON H. Khartabil XCON H. Khartabil
Internet-Draft P. Koskelainen Internet-Draft P. Koskelainen
Expires: March 10, 2005 A. Niemi Expires: April 12, 2005 A. Niemi
Nokia Nokia
September 9, 2004 October 12, 2004
The Conference Policy Control Protocol (CPCP) The Conference Policy Control Protocol (CPCP)
draft-ietf-xcon-cpcp-00 draft-ietf-xcon-cpcp-01
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 March 10, 2005. This Internet-Draft will expire on April 12, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
The Conference Policy is defined as the complete set of rules for a The Conference Policy is defined as the complete set of rules for a
particular conference manipulated by the conference policy server. particular conference manipulated by the conference policy server.
The Conferece Policy Control Protocol (CPCP) is the protocol used by The Conferece Policy Control Protocol (CPCP) is the protocol used by
clients to manipulate the conference policy. This document describes clients to manipulate the conference policy. This document describes
the Conference Policy Control Protocol (CPCP). It specifies an the Conference Policy Control Protocol (CPCP). It specifies an
Extensible Markup Language (XML) Schema that enumerates the Extensible Markup Language (XML) Schema that enumerates the
conference policy data elements that enable a user to define a conference policy data elements that enable a user to define a
conference policy. conference policy.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Structure of a Conference Policy document . . . . . . . . . . 4 4. Structure of a Conference Policy document . . . . . . . . . . 5
4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4 4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 5
4.2 Conference Root . . . . . . . . . . . . . . . . . . . . . 4 4.2 Conference Root . . . . . . . . . . . . . . . . . . . . . 5
4.3 XML Document Description . . . . . . . . . . . . . . . . . 5 4.3 XML Document Description . . . . . . . . . . . . . . . . . 6
4.3.1 Conference Settings . . . . . . . . . . . . . . . . . 5 4.3.1 Conference Settings . . . . . . . . . . . . . . . . . 6
4.3.2 Conference Information . . . . . . . . . . . . . . . . 7 4.3.2 Conference Information . . . . . . . . . . . . . . . . 8
4.3.3 Conference Time . . . . . . . . . . . . . . . . . . . 8 4.3.3 Conference Time . . . . . . . . . . . . . . . . . . . 9
4.3.4 Conference Authorization Rules . . . . . . . . . . . . 9 4.3.4 Conference Dial-Out List . . . . . . . . . . . . . . . 10
4.3.5 Conference Dial-Out List . . . . . . . . . . . . . . . 20 4.3.5 Conference Refer List . . . . . . . . . . . . . . . . 11
4.3.6 Conference Refer List . . . . . . . . . . . . . . . . 20 4.3.6 Conference Media Streams . . . . . . . . . . . . . . . 11
4.3.7 Conference Media Streams . . . . . . . . . . . . . . . 21 4.3.7 Conference Authorization Rules . . . . . . . . . . . . 12
4.4 XML Schema Extensibility . . . . . . . . . . . . . . . . . 21 4.3.7.1 Conditions . . . . . . . . . . . . . . . . . . . . 12
4.5 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3.7.1.1 Validity . . . . . . . . . . . . . . . . . . . 13
4.3.7.1.2 Identity . . . . . . . . . . . . . . . . . . . 14
4.3.7.1.2.1 Interpreting the <id> Element . . . . . . 15
4.3.7.1.3 Sphere . . . . . . . . . . . . . . . . . . . . 15
4.3.7.1.4 Conference Policy Identity . . . . . . . . . . 15
4.3.7.1.4.1 Matching Any Identity . . . . . . . . . . 15
4.3.7.1.4.2 Matching Identities in External Lists . . 15
4.3.7.1.5 Matching Pseudonymous Identities . . . . . . . 15
4.3.7.1.6 Matching Referred Identities . . . . . . . . . 16
4.3.7.1.7 Matching Invited Identities . . . . . . . . . 16
4.3.7.1.8 Matching Identities of Former Conference
Participants . . . . . . . . . . . . . . . . . 17
4.3.7.1.9 Matching Identities Currently in the
Conference . . . . . . . . . . . . . . . . . . 17
4.3.7.1.10 Matching Key Participant Identities . . . . . 17
4.3.7.1.11 Matching Identities on the Dial-out List . . . 17
4.3.7.1.12 Matching Identities on the Refer List . . . . 17
4.3.7.1.13 Floor ID . . . . . . . . . . . . . . . . . . . 17
4.3.7.1.14 Matching Participant Passcodes . . . . . . . . 17
4.3.7.1.15 Matching Passcodes . . . . . . . . . . . . . . 18
4.3.7.2 Actions . . . . . . . . . . . . . . . . . . . . . 19
4.3.7.2.1 Conference State Events . . . . . . . . . . . 19
4.3.7.2.2 Floor Control Events . . . . . . . . . . . . . 19
4.3.7.2.3 Conference Join Handling . . . . . . . . . . . 20
4.3.7.2.4 Dynamically Referring Users . . . . . . . . . 20
4.3.7.2.5 Dynamically Inviting Users . . . . . . . . . . 20
4.3.7.2.6 Dynamically Removing Users . . . . . . . . . . 21
4.3.7.2.7 Floor Request Handling . . . . . . . . . . . . 21
4.3.7.3 Transformations . . . . . . . . . . . . . . . . . 22
4.3.7.3.1 Key Participant . . . . . . . . . . . . . . . 22
4.3.7.3.2 Floor Moderator . . . . . . . . . . . . . . . 22
4.3.7.3.3 Conference Information . . . . . . . . . . . . 22
4.3.7.3.4 Floor Holder . . . . . . . . . . . . . . . . . 22
4.3.7.3.5 Floor Requests . . . . . . . . . . . . . . . . 23
4.3.7.3.6 Providing anonymity . . . . . . . . . . . . . 23
4.4 XML Schema Extensibility . . . . . . . . . . . . . . . . . 23
4.5 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Conference Policy Manipulation and Conference Entity 5. Conference Policy Manipulation and Conference Entity
Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Overview of Operation . . . . . . . . . . . . . . . . . . 27 5.1 Overview of Operation . . . . . . . . . . . . . . . . . . 28
5.2 Use of External Lists . . . . . . . . . . . . . . . . . . 27 5.2 Use of External Lists . . . . . . . . . . . . . . . . . . 29
5.3 Communication Between Conference Entities . . . . . . . . 28 5.3 Communication Between Conference Entities . . . . . . . . 29
5.4 Manipulating Participant Lists . . . . . . . . . . . . . . 28 5.4 Manipulating Participant Lists . . . . . . . . . . . . . . 29
5.4.1 Expelling a Participant . . . . . . . . . . . . . . . 28 5.4.1 Expelling a Participant . . . . . . . . . . . . . . . 30
5.5 Re-joining a Conference . . . . . . . . . . . . . . . . . 30 5.5 Re-joining a Conference . . . . . . . . . . . . . . . . . 31
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1 A Simple Conference Policy Document . . . . . . . . . . . 30 6.1 A Simple Conference Policy Document . . . . . . . . . . . 32
6.2 A Complex Conference Policy Document . . . . . . . . . . . 31 6.2 A Complex Conference Policy Document . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 34 8.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 36
8.2 application/conference-policy+xml MIME TYPE . . . . . . . 34 8.2 application/conference-policy+xml MIME TYPE . . . . . . . 36
8.3 URN Sub-Namespace Registration for 8.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-policy . . . . . . . . . 35 urn:ietf:params:xml:ns:conference-policy . . . . . . . . . 37
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. Normative References . . . . . . . . . . . . . . . . . . . . 38
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
11.2 Informative References . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . 40
1. Introduction 1. Introduction
The SIP conferencing framework [13] defines the mechanisms for The SIP conferencing framework [13] defines the mechanisms for
multi-party centralized conferencing in a SIP environment. multi-party centralized conferencing in a SIP environment.
Existing SIP mechanisms allow users, for example, to join and leave a Existing SIP mechanisms allow users, for example, to join and leave a
conference, as described in [9]. A centralised server, called focus, conference, as described in [9]. A centralised server, called focus,
can expel and invite users, and may have proprietary access control can expel and invite users, and may have proprietary access control
lists and user privilege definitions. This document defines an XML lists and user privilege definitions. This document defines an XML
skipping to change at page 3, line 40 skipping to change at page 4, line 40
This document uses terminology from [13]. Some additional This document uses terminology from [13]. Some additional
definitions are introduced here. definitions are introduced here.
Conference authorization policy (CAP): Conference authorization Conference authorization policy (CAP): Conference authorization
policy consists of an unordered set of rules, which control the policy consists of an unordered set of rules, which control the
permissions and privileges that are given to conference permissions and privileges that are given to conference
participants. participants.
Conference Policy Server (CPS): Conference Policy Server. See [13] Conference Policy Server (CPS): Conference Policy Server. See [13]
Conference participant: Conference participant is a user who has an Conference participant: A conference participant is a user who has
on-going session (e.g. SIP dialog) with the conference focus. an on-going session (e.g. SIP dialog) with the conference focus.
Key participant: A key participant is a user whose participantion in
the conference is required for the conference to take place as
s/he can be the note taker, the person with whom a debate is
taking place, etc. A key participant may be required to be in a
conference before the conference starts and may be required for
the conference not to end.
Floor control: Floor control is a mechanism that enables Floor control: Floor control is a mechanism that enables
applications or users to gain safe and mutually exclusive or applications or users to gain safe and mutually exclusive or
non-exclusive access to the shared object or resource in a non-exclusive access to the shared object or resource in a
conference. conference.
Dial-Out List (DL): The Dial-out list (DL) is a list of users who Dial-Out List (DL): The Dial-out list (DL) is a list of users who
the focus needs to invite to the conference. the focus needs to invite to the conference.
Privileged user: A privileged user is a user that has the right to Privileged user: A privileged user is a user that has the right to
skipping to change at page 4, line 19 skipping to change at page 5, line 23
the XML document. The URI construction is specified in [10]. the XML document. The URI construction is specified in [10].
Refer List (RL): The Refer list (RL) is a list of users who the Refer List (RL): The Refer list (RL) is a list of users who the
focus needs to refer to the conference. focus needs to refer to the conference.
Sidebar: A sub-conference of a main conference. Sidebar: A sub-conference of a main conference.
4. Structure of a Conference Policy document 4. Structure of a Conference Policy document
The conference policy document is an XML [6] document that MUST be The conference policy document is an XML [6] document that MUST be
well-formed and MUST be valid. The Conference policy documents MUST well-formed and MUST be valid according to schemas, including
be based on XML 1.0 and MUST be encoded using UTF-8. This extension schemas, available to the validater and applicable to the
specification makes use of XML namespaces for identifying conference XML document. The Conference policy documents MUST be based on XML
policy documents and document fragments. The namespace URI for 1.0 and MUST be encoded using UTF-8. This specification makes use of
elements defined by this specification is a URN [3], using the XML namespaces for identifying conference policy documents and
namespace identifier 'ietf' defined by [4] and extended by [15]. document fragments. The namespace URI for elements defined by this
This URN is: specification is a URN [3], using the namespace identifier 'ietf'
defined by [4] and extended by [15]. This URN is:
urn:ietf:params:xml:ns:conference-policy urn:ietf:params:xml:ns:conference-policy
4.1 MIME Type for CPCP XML Document 4.1 MIME Type for CPCP XML Document
The MIME type for the CPCP XML document is "application/ The MIME type for the CPCP XML document is
conference-policy+xml". "application/conference-policy+xml".
4.2 Conference Root 4.2 Conference Root
A conference policy document begins with the root element tag A conference policy document begins with the root element tag
<conference>. Other elements from different namespaces MAY be <conference>. Other elements from different namespaces MAY be
present for the purposes of extensibility. Elements or attributes present for the purposes of extensibility. Elements or attributes
from unknown namespaces MUST be ignored. The conference policy is from unknown namespaces MUST be ignored. The conference policy is
build up using the following: build up using the following:
o The <settings> element: This element is mandatory and contains o The <settings> element: This element is mandatory and contains
skipping to change at page 5, line 10 skipping to change at page 6, line 16
o The <info> element: This element is optional and includes o The <info> element: This element is optional and includes
information describing the conference, that can be used, for information describing the conference, that can be used, for
example, search purposes. This information can also be used in example, search purposes. This information can also be used in
the session description when the focus is sending invitations. It the session description when the focus is sending invitations. It
can occur only once in the document. can occur only once in the document.
o The <time> element: This optional element defines conference time o The <time> element: This optional element defines conference time
information, namely elements defining start and stop times for a information, namely elements defining start and stop times for a
media mixing. media mixing.
o The <authorization> element: This optional element is the
conference authorisation rules. It contains rules for users who
can dial into the conference, users who are blocked from dialling
in, amongst others.
o The <dialout-list> element: This optional element is for the o The <dialout-list> element: This optional element is for the
dial-out list. It contains URIs for users that the focus will dial-out list. It contains URIs for users that the focus will
invite to the conference. invite to the conference.
o The <refer-list> element: This optional element is for the refer o The <refer-list> element: This optional element is for the refer
list. It contains URIs for users that the focus will refer to the list. It contains URIs for users that the focus will refer to the
conference. conference.
o The <ms> element: This optional element contains the media streams o The <ms> element: This optional element contains the media streams
to be used in the conference. to be used in the conference.
o The <ruleset> element: This optional element is the conference
authorisation rules. It contains rules for users who can dial
into the conference, users who are blocked from dialling in,
amongst others.
The elements are described in more detail in the forthcoming The elements are described in more detail in the forthcoming
sections. sections.
A user may create a new conference at the CPS by placing a new A user may create a new conference at the CPS by placing a new
conference policy document. Depending on server policy and user conference policy document. Depending on server policy and user
privileges, the CPS may accept the creation, or it may reject it. privileges, the CPS may accept the creation, or it may reject it.
A conference can be deleted permanently by removing the conference A conference can be deleted permanently by removing the conference
policy from the CPS, which consequently frees the resources. When policy from the CPS, which consequently frees the resources. When
the user deletes a conference, the CPS MUST also delete all its the user deletes a conference, the CPS MUST also delete all its
skipping to change at page 8, line 39 skipping to change at page 9, line 42
mandatory 'require-participant' attribute. This attribute has one of mandatory 'require-participant' attribute. This attribute has one of
3 values: "none", "key-participant", and "participant". For mixing 3 values: "none", "key-participant", and "participant". For mixing
start time, this attribute allows a privileged user to define when start time, this attribute allows a privileged user to define when
media mixing starts based on the latter of the mixing start time, and media mixing starts based on the latter of the mixing start time, and
the time the first participant or key participant arrives. If the the time the first participant or key participant arrives. If the
value is set to "none", mixing starts according to the mixing start value is set to "none", mixing starts according to the mixing start
time. For mixing stop time, this attribute allows a privileged user time. For mixing stop time, this attribute allows a privileged user
to define when media mixing stops based on the earlier of the mixing to define when media mixing stops based on the earlier of the mixing
stop time, and the time the last participant or key participant stop time, and the time the last participant or key participant
leaves. If the value is set to "none", mixing stops according to the leaves. If the value is set to "none", mixing stops according to the
mixing stop time. mixing stop time. If the conference policy was modified so that that
last key participant is now a normal conference participant, and the
conference requires a kep participant to continue; that conference
MUST terminate.
The following is an example that states a conference mixing will not
start before a key participant joins but the mixing will stop as soon
as the last participant (no neccesarily the last key participant)
leaves.
<time>
<occurrence>
<mixing-start-time required-participant="key-participant">
2004-12-17T09:30:00-05:00</mixing-start-time>
<mixing-stop-time required-participant="participant">
2004-12-17T12:30:00-05:00</mixing-stop-time>
</occurrence>
</time>
Users can be allowed to join a conference before the media mixing Users can be allowed to join a conference before the media mixing
time starts and after a certain time. A conference privileged user time starts and after a certain time. A conference privileged user
can indicate the time when users can join by populating the can indicate the time when users can join by populating the
<can-join-after> element. Similarly, a conference privileged user <can-join-after> element. Similarly, a conference privileged user
can define the time after which new users are not allowed to join the can define the time after which new users are not allowed to join the
conference anymore. This is done by populating the conference anymore. This is done by populating the
<must-join-before> element. <must-join-before> element.
It is possible to define the time when users or resources on the It is possible to define the time when users or resources on the
skipping to change at page 9, line 23 skipping to change at page 10, line 45
A running conference instance can be extended or stopped by modifying A running conference instance can be extended or stopped by modifying
the conference time information. Note that those conference times do the conference time information. Note that those conference times do
not guarantee resources for the conference to be available. not guarantee resources for the conference to be available.
If a conference is in progress when deleted or stopped, the focus If a conference is in progress when deleted or stopped, the focus
issues signalling requests to terminate all conference related issues signalling requests to terminate all conference related
sessions it has with participants. In SIP, the focus issues BYE sessions it has with participants. In SIP, the focus issues BYE
requests. requests.
4.3.4 Conference Authorization Rules 4.3.4 Conference Dial-Out List
The dial-out list (DL) is a list of user URIs that the focus uses to
learn who to invite to join a conference. This list can be created
at conference policy creation time or updated during the conference
lifetime so it can be used for mid-conference invites (and
mass-invites) as well.
Asking the focus to invite (add) a user into the conference is
achieved by adding that user's URI to the Dial-Out List (DL). The
CPS then triggers the focus to send the conference invitation, eg:
SIP INVITE as needed. Similarly, a user can be removed from the
Dial-out list by removing the URI from the dial-out list.
The <dialout-list> element is optional and includes zero or more
<target> elements and zero or more <external> elements. Those two
elements includes the mandatory 'uri' attribute. The use of the
<external> element is described in more detail in Section 5.2
4.3.5 Conference Refer List
The Refer List (RL) contains a list of resources that the focus needs
to refer to the conference. In SIP, this is achieved by the focus
sending a REFER request to those potential participants. In a
different paradiam, this could also mean that the focus sends an SMS
or an email to the referred user. This list can be updated during
the conference lifetime so it can be used for mid-conference refers
as well.
The Refer List differs from the Dial-out list in that the dial-out
list contains a list of resources that the focus will initiate a
session with. The resources on the refer list, on the other had, are
expected to initiate the session establishment towards the focus
themselves. It is also envisioned that difference users will have
different access rights to those lists and therefore a separation
between the two is needed.
The <refer-list> element is optional and identical to the
<dialout-list> element in Section 4.3.4.
4.3.6 Conference Media Streams
Media policy is an integral part of the conference policy. It
defines e.g. what kind of media topologies exist in the conference.
Media policy is documented in [17].This document does not define
media policy, but instead enables the user to specify the media
streams a conference has. This is used by the focus to know what
media streams to invite users with and what media streams it should
accept from dialling in users. Media can be added to or removed from
a conference by a privileged user before or during a conference
occurance. This might result in the focus modifying the session it
has with each participant. In SIP, this means re-issuing and INVITE
request modifying the session description (SDP).
The definition starts with the optional <media-streams> element.
This element lists the media streams allowed for this conference. It
can contain at most one of each media type using the <video>,
<audio>, <message> and <text> elements.
4.3.7 Conference Authorization Rules
One of the key components of conference policy is the set of One of the key components of conference policy is the set of
authorization rules that specify who is allowed to join a conference, authorization rules that specify who is allowed to join a conference,
see floors and request/grant them, subscribe to see floors and request/grant them, subscribe to
conference-information notifications and so on. The unordered list conference-information notifications and so on. The unordered list
of authorization rules together define the conference authorization of authorization rules together define the conference authorization
policy policy
The conference authorization rules are enclosed in the The conference authorization rules are enclosed in the <ruleset>
<authorization-rules> element and are formatted according to the XML element and are formatted according to the XML schema defined in the
schema defined in the common policy framework [1]. In the common policy framework [1]. In the <ruleset> element, there can be
<authorization-rules> element, there can be multiple rules, each rule multiple rules, each rule is represented by the <rule> element, each
is represented by the <rule> element, each of which consist of three of which consist of three parts: conditions, actions and
parts: conditions, actions and transformations. Conditions determine transformations. Conditions determine whether a particular rule
whether a particular rule applies to a request. Each action or applies to a request. Each action or transformation in the applied
transformation in the applied rule is a positive grant of permission rule is a positive grant of permission to the conference participant.
to the conference participant. The details of each specific element The details of each specific element and attribute is described in
and attribute is described in [1]. [1].
Asking the focus to allow certain users to join the conference is Asking the focus to allow certain users to join the conference is
achieved by modifying an existing authorization rule or creating a achieved by modifying an existing authorization rule or creating a
new one. The CPS then informs the focus of such change. new one. The CPS then informs the focus of such change.
If the conference is long-lasting, it is possible that new rules are 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 added all the time but old rules are almost never removed (some of
them are overwritten, though). This leads easily to the situation them are overwritten, though). This leads easily to the situation
that the conference policy contains many unnecessary rules which are that the conference policy contains many unnecessary rules which are
not really needed anymore. Therefore, there is a need to delete not really needed anymore. Therefore, there is a need to delete
rules. This can be achieved by removing that portion of the policy. rules. This can be achieved by removing that portion of the policy.
Conflicting rules may exist (for example, both allowed and blocked Conflicting rules may exist (for example, both allowed and blocked
action is defined for same target). The common policy directives [1] action is defined for same target). The common policy directives [1]
dictate the behaviour in such situations. dictate the behaviour in such situations.
This section outlines the new conditions, actions and transformations This section outlines the new conditions, actions and transformations
for conference authorization policy. for conference authorization policy.
4.3.4.1 Conditions 4.3.7.1 Conditions
4.3.4.1.1 Validity 4.3.7.1.1 Validity
The <validity> element, as defined in the common policy framework The <validity> element, as defined in the common policy framework
[1], expresses the rule validity period by two attributes, a starting [1], expresses the rule validity period by two attributes, a starting
and a ending time. Times are expressed in XML dateTime format. and a ending time. Times are expressed in XML dateTime format.
Expressing the lifetime of a rule implements a garbage collection Expressing the lifetime of a rule implements a garbage collection
mechanism. A rule maker might not have always access to the mechanism. A rule maker might not have always access to the
conference policy server to remove some rules which grant conference policy server to remove some rules which grant
permissions. Hence this mechanisms allows to remove or invalidate permissions. Hence this mechanisms allows to remove or invalidate
granted permissions automatically without further interaction between granted permissions automatically without further interaction between
the rule maker and the conference policy server. the rule maker and the conference policy server.
skipping to change at page 11, line 41 skipping to change at page 14, line 41
... ...
<time> <time>
<occurrence> <occurrence>
<mixing-start-time required-participant="participant"> <mixing-start-time required-participant="participant">
2004-12-17T09:30:00-05:00</mixing-start-time> 2004-12-17T09:30:00-05:00</mixing-start-time>
<mixing-stop-time required-participant="none"> <mixing-stop-time required-participant="none">
2004-12-17T12:30:00-05:00</mixing-stop-time> 2004-12-17T12:30:00-05:00</mixing-stop-time>
</occurrence> </occurrence>
</time> </time>
4.3.4.1.2 Identity 4.3.7.1.2 Identity
The <identity> element is already defined in the common policy The <identity> element is already defined in the common policy
framework [1]The presence of the <identity> element is a condition framework [1]. The presence of the <identity> element is a condition
requires any identity within it to be authenticated before a rule is requires any identity within it to be authenticated before a rule is
applied to it. This includes the <id> element (Section 4.3.4.1.2.1), applied to it. This includes the <id> element (Section 4.3.7.1.2.1),
the <any> element (Section 4.3.4.1.2.2), the <external-list> element the <any> element (Section 4.3.7.1.4.1), the <external-list> element
(Section 4.3.4.1.2.4), their exceptions, and any future extension (Section 4.3.7.1.4.2), their exceptions, and any future extension
that carries an identity. The absence of the <identity> element with that carries an identity. The absence of the <identity> element with
in a condition indicated that the rule applies to all unauthenticated in a condition indicated that the rule applies to all unauthenticated
identities. That is participants that have provided no authenticated identities. That is participants that have provided no authenticated
identity to the conference focus. identity to the conference focus.
4.3.4.1.2.1 Interpreting the <id> Element 4.3.7.1.2.1 Interpreting the <id> Element
As earlier indicated, the <identity> element is already defined in As earlier indicated, the <identity> element is already defined in
the common policy framework [1]. However, the rules for interpreting the common policy framework [1]. However, the rules for interpreting
the identities in <id> elements are left for each application to the identities in <id> elements are left for each application to
define separately. This document, however, does not define the rules define separately. This document, however, does not define the rules
for interpreting identities in <id> elements in conferencing for interpreting identities in <id> elements in conferencing
applications since those interpretation rules are signalling protocol applications since those interpretation rules are signalling protocol
specific. specific.
OPEN ISSUE: Do we need to state more than this? How are identities OPEN ISSUE: Do we need to state more than this? How are identities
derived from users that join using POTS, H.323, etc.? derived from users that join using POTS, H.323, etc.?
4.3.4.1.2.2 Matching Any Identity 4.3.7.1.3 Sphere
The <sphere> element has no meaning in the context of conference
policy and MUST be ignored if present.
4.3.7.1.4 Conference Policy Identity
4.3.7.1.4.1 Matching Any Identity
The <any> element is used to match any participant. This allows a The <any> element is used to match any participant. This allows a
conference to be open to any authenticated user. Just as for the conference to be open to any authenticated user. Just as for the
<domain> element in <identity> element, The <any> element contains a <domain> element in <identity> element, The <any> element contains a
list of <except> elements and allows to implement a simple blacklist list of <except> elements and allows to implement a simple blacklist
mechanism. The <except> element contains the identity. It differs mechanism. The <except> element contains an identity. It differs
from the <domain> element in that the domain part is needed in the from the <domain> element in that the domain part is needed in the
identity since it has not domain to refer to. identity since it has no domain to refer to.
4.3.4.1.2.3 Matching Pseudonymous Identities 4.3.7.1.4.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
<external-list> element contains a list of <except> elements and
allows to implement a simple blacklist mechanism. The <except>
element contains an identity.Section 5.2 talks about the use of this
condition in more detail.
4.3.7.1.5 Matching Pseudonymous Identities
The <pseudonymous> element is used to match participants that have The <pseudonymous> element is used to match participants that have
provided an authenticated identity to the conference focus, but have provided an authenticated identity to the conference focus, but have
requested pseudonymity in the conference itself. A user requests requested pseudonymity in the conference itself. A user requests
pseudonymity by authenticating himself to the conference focus and pseudonymity by authenticating himself to the conference focus and
providing an pseudonym in the signalling protocol (for example, using providing an pseudonym in the signalling protocol (for example, using
the From-header of a SIP reqeust). A rule allowing pseudonymous the From-header of a SIP reqeust). A rule allowing pseudonymous
users to join looks like the following: users to join looks like the following:
<rule id="4"> <rule id="4">
skipping to change at page 13, line 23 skipping to change at page 16, line 38
<id>alice@example.com</id> <id>alice@example.com</id>
</identity> </identity>
<pseudonymous> <pseudonymous>
</conditions> </conditions>
<actions> <actions>
<join-handling>allow</join-handling> <join-handling>allow</join-handling>
</actions> </actions>
<transformations/> <transformations/>
</rule> </rule>
4.3.4.1.2.4 Matching Identities in External Lists 4.3.7.1.6 Matching Referred Identities
The <external-list> element can be used to match those participants
that are part of a resource list that is created externally. Section
5.2 talks about the use of this condition in more detail.
4.3.4.1.2.5 Matching Referred Identities
The <has-been-referred> element can be used to match those The <has-been-referred> element can be used to match those
participants that the focus has referred to the conference. participants that the focus has referred to the conference.
4.3.4.1.2.6 Matching Invited Identities 4.3.7.1.7 Matching Invited Identities
The <has-been-invited> element can be used to match those The <has-been-invited> element can be used to match those
participants that the focus has invited into the conference. participants that the focus has invited into the conference.
4.3.4.1.2.7 Matching Identities of Former Conference Participants 4.3.7.1.8 Matching Identities of Former Conference Participants
The <has-been-in-conference> element can be used to match those The <has-been-in-conference> element can be used to match those
participants that have joined the conference in the past. participants that have joined the conference in the past.
4.3.4.1.2.8 Matching Identities Currently in the Conference 4.3.7.1.9 Matching Identities Currently in the Conference
The <is-in-conference> element can be used to match those The <is-in-conference> element can be used to match those
participants that are currently participating in the conference. participants that are currently participating in the conference.
4.3.4.1.2.9 Matching Key Participant Identities 4.3.7.1.10 Matching Key Participant Identities
The <key-participant> element can be used to match those participants The <key-participant> element can be used to match those participants
that are key participants of a conference. that are key participants of a conference.
4.3.4.1.2.10 Matching Identities on the Dial-out List 4.3.7.1.11 Matching Identities on the Dial-out List
The <is-on-dialout-list> element can be used to match those The <is-on-dialout-list> element can be used to match those
participants that are on the dial-out list. participants that are on the dial-out list.
4.3.4.1.2.11 Matching Identities on the Refer List 4.3.7.1.12 Matching Identities on the Refer List
The <is-on-refer-list> element can be used to match those The <is-on-refer-list> element can be used to match those
participants that are on the refer list. participants that are on the refer list.
4.3.4.1.2.12 Floor ID 4.3.7.1.13 Floor ID
The <floor-id> element can be used to assign users as floor The <floor-id> element can be used to assign users as floor
moderators. It MUST be used in conjunction with the <id> element moderators. It MUST be used in conjunction with the <id> element
that identifies the floor moderator. The <floor-id> element carries that identifies the floor moderator. The <floor-id> element carries
the floor ID of the floor that the user is a moderator of. The the floor ID of the floor that the user is a moderator of. The
transformation <is-floor-moderator> is used to assert that the user transformation <is-floor-moderator> is used to assert that the user
identified using the <id> condition is the floor moderator of the identified using the <id> condition is the floor moderator of the
floor identified in the <floor-id> condition. floor identified in the <floor-id> condition.
The <floor-id> element is also used with the <floor-request-handling> The <floor-id> element is also used with the <floor-request-handling>
element (Section 4.3.4.2.6) to set rules on who is allowed to request element (Section 4.3.7.2.7) to set rules on who is allowed to request
a floor. a floor.
4.3.4.1.2.13 Matching PIN Codes 4.3.7.1.14 Matching Participant Passcodes
The <pin> element can be used to match those participants that are The <participant-passcode> element can be used to match those
have knowledge on a PIN code for the conference. For example: participants that are have knowledge on a passcode for the
conference. For example:
<rule id="1"> <rule id="3">
<conditions> <conditions>
<pin>12345</pin> <participant-passcode/>
</conditions> </conditions>
<actions> <actions>
<join-handling>allow</join-handling> <join-handling>allow</join-handling>
</actions> </actions>
<transformations/> <transformations/>
</rule> </rule>
So the condition is the PIN. If any user knows the PIN, ignoring So the condition is the participant passcode. If any user knows the
their identity, the user is allowed to join. passcode, the user is allowed to join.
A combination of the <identity> condition and the <pin> condition A focus need not care if a user using a passcode to join is calling
creates the possibility of assigning users personal PIN codes to from a PSTN or an IP phone. For example: Using a SIP phone, a SIP
enable them to join a conference. For example: INVITE request arrives directly at the focus. The focus examines the
identity and discovers that there are no rules allowing this identity
to join. The focus also determines that there are no rules
explicitly prohibiting this identity from joining. The focus in this
case decides to challenge the identity for a passcode, if there is a
rule that allows users with a passcode knowledge to join. If no such
rule exists, the focus would not challenge for a passcode.
<rule id="2"> For PSTN users, the system can be set up for an IVR system to prompt
<conditions> the user for a passcode before forwarding the request to the focus.
<identity> The focus does not need to care if there is an IVR system or not. It
<id>358401234567</id> can apply the same procedure as above. It checks if there are any
</identity> the rules allowing or denying the identity access. In this case, the
<pin>67890</pin> identity is the GW. If no rules exist for that identity but an
</conditions> general passcode rule does, then the focus would challenge the GW/IVR
<actions> for the passcode.
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
4.3.4.1.2.14 Matching Passwords A focus can challenge for the passcode using, for example, a HTTP
Digest challenge. The username, passcode and realm need to be
assigned and distributed is a manner that is outside the scope of
this document. Mutliple passcodes can be assigned to multiple users.
The <password> element can be used to match those participants that 4.3.7.1.15 Matching Passcodes
are have knowledge on a password for the conference. For example:
In some cases, key participants are assigned a different passcode
than normal participants. The <key-participant-passcode> element can
be used to match those key participants that are have knowledge on a
key participant passcode for the conference. For example:
<rule id="3"> <rule id="3">
<conditions> <conditions>
<password>pass1</password> <key-participant-passcode/>
</conditions> </conditions>
<actions> <actions>
<join-handling>allow</join-handling> <join-handling>allow</join-handling>
</actions> </actions>
<transformations/> <transformations>
<is-key-participant/>
</transformations>
</rule> </rule>
So the condition is the password. If any user knows the password, So the condition is the key participant passcode. If any user knows
ignoring their identity, the user is allowed to join. that passcode, that user is allowed to join and is made a key
participant. Again, a focus need not care if a user using a passcode
A combination of the <identity> condition and the <password> to join is calling from a PSTN or an IP phone. Section 4.3.7.1.14
condition creates the possibility of assigning users personal has more details.
passwords to enable them to join a conference. For example:
<rule id="4"> It is important that the focus has a unique identity for each user
<conditions> joining from a PSTN phone via a gateway. It is not enough that one
<identity> identity to be assigned to all users joining from the same gateway
<id>alice@example.com</id> since key participants have more control over conference duration, if
</identity> the conference mixing times are key participant dependant. See
<password>pass2</password> Section 4.3.3 for details. It might be required that a gateway maps
</conditions> the telephone number of the PSTN phone into the IP signalling
<actions> protocol header that usually carries the asserted identity or a user.
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
4.3.4.2 Actions 4.3.7.2 Actions
4.3.4.2.1 Conference State Events 4.3.7.2.1 Conference State Events
The <allow-conference-state> element represents a boolean action. If The <allow-conference-state> element represents a boolean action. If
set to TRUE, the focus is instructed to allow the subscription to set to TRUE, the focus is instructed to allow the subscription to
conference state events, such as the SIP Event Package for Conference conference state events, such as the SIP Event Package for Conference
State [14]. If set to FALSE, the subscription to conference state State [14]. If set to FALSE, the subscription to conference state
events would be rejected. events would be rejected.
If this element is undefined it has a value of TRUE, causing the If this element is undefined it has a value of TRUE, causing the
subscription to conference state events to be accepted. subscription to conference state events to be accepted.
4.3.4.2.2 Floor Control Events 4.3.7.2.2 Floor Control Events
The <allow-floor-events> element represents a boolean action. If set The <allow-floor-events> element represents a boolean action. If set
to TRUE, the focus is instructed to accept the subscription to floor to TRUE, the focus is instructed to accept the subscription to floor
control events. If set to FALSE, the focus is instructed to reject control events. If set to FALSE, the focus is instructed to reject
the subscription. the subscription.
If this element is undefined, it has a value of FALSE, causing the If this element is undefined, it has a value of FALSE, causing the
subscription to floor control events to be rejected. subscription to floor control events to be rejected.
4.3.4.2.3 Conference Join Handling 4.3.7.2.3 Conference Join Handling
The <join-handling> element defines the actions used by the The <join-handling> element defines the actions used by the
conference focus to control conference participation. This element conference focus to control conference participation. This element
defines the action that the focus is to take when processing a defines the action that the focus is to take when processing a
particular request to join a conference. This element is an particular request to join a conference. This element is an
enumerated integer type, with defined values of: enumerated integer type, with defined values of:
block: This action instructs the focus to deny access to the block: This action instructs the focus to deny access to the
conference. This action has a value of zero and it is the lowest conference. This action has a value of zero and it is the lowest
value of the <join-handling> element. This action is the default value of the <join-handling> element. This action is the default
skipping to change at page 17, line 26 skipping to change at page 20, line 37
request and grant access to the conference within the instructions request and grant access to the conference within the instructions
specified in the transformations of this rule. This action has a specified in the transformations of this rule. This action has a
value of two. value of two.
Note that placing a value of block for this element doesn't guarantee Note that placing a value of block for this element doesn't guarantee
that a participant is blocked from joining the conference. Any other that a participant is blocked from joining the conference. Any other
rule that might evaluate to true for this participant that carried an rule that might evaluate to true for this participant that carried an
action whose value was higher than block would automatically grant action whose value was higher than block would automatically grant
confirm/allow permission to that participant. confirm/allow permission to that participant.
4.3.4.2.4 Dynamically Referring Users 4.3.7.2.4 Dynamically Referring Users
The <allow-refer-users-dynamically> element represents a boolean The <allow-refer-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the action. If set to TRUE, the identity is allowed to instruct the
focus to refer a user to the conference without modifying the focus to refer a user to the conference without modifying the
refer-list (in SIP terms, the identity is allowed to send a REFER refer-list (in SIP terms, the identity is allowed to send a REFER
request to the focus which results in the focus sending a REFER request to the focus which results in the focus sending a REFER
request to the user the referrer wishes to join the conference). If request to the user the referrer wishes to join the conference). If
set to FALSE, the refer request is rejected. set to FALSE, the refer request is rejected.
If this element is undefined it has a value of FALSE, causing the If this element is undefined it has a value of FALSE, causing the
refer to be rejected. refer to be rejected.
4.3.4.2.5 Dynamically Inviting Users 4.3.7.2.5 Dynamically Inviting Users
The <allow-invite-users-dynamically> element represents a boolean The <allow-invite-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the action. If set to TRUE, the identity is allowed to instruct the
focus to invite a user to the conference without modifying the focus to invite a user to the conference without modifying the
dial-out list (in SIP terms, the identity is allowed to send a REFER dial-out list (in SIP terms, the identity is allowed to send a REFER
request to the focus which results in the focus sending an INVITE request to the focus which results in the focus sending an INVITE
requested to the user the referrer wishes to join the conference). request to the user the referrer wishes to join the conference). If
If set to FALSE, the refer request is rejected. set to FALSE, the refer request is rejected.
If this element is undefined it has a value of FALSE, causing the If this element is undefined it has a value of FALSE, causing the
refer to be rejected. refer to be rejected.
4.3.4.2.6 Floor Request Handling 4.3.7.2.6 Dynamically Removing Users
The <allow-remove-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the
focus to remove a user from the conference without modifying the
ruleset (in SIP terms, the identity is allowed to send a REFER
request to the focus which results in the focus sending an BYE
request to the user the referrer wishes to leave the conference). If
set to FALSE, the refer request is rejected.
If this element is undefined it has a value of FALSE, causing the
refer to be rejected.
4.3.7.2.7 Floor Request Handling
The <floor-request-handling> element defines the actions used by the The <floor-request-handling> element defines the actions used by the
conference focus to control floor requests. This element defines the conference focus to control floor requests. This element defines the
action that the focus is to take when processing a particular request action that the focus is to take when processing a particular request
to a floor within a conference. This element is an enumerated to a floor within a conference. This element is an enumerated
integer type, with defined values of: integer type, with defined values of:
block: This action instructs the focus to deny the floor request. block: This action instructs the focus to deny the floor request.
This action has a value of zero and it is the lowest value of the This action has a value of zero and it is the lowest value of the
<floor-request-handling> element. This action is the default <floor-request-handling> element. This action is the default
skipping to change at page 18, line 29 skipping to change at page 22, line 5
focus then uses the defined floor algorithm to further allow of focus then uses the defined floor algorithm to further allow of
deny the floor. The algorithms used are outside the scope of this deny the floor. The algorithms used are outside the scope of this
document. document.
Note that placing a value of block for this element doesn't guarantee Note that placing a value of block for this element doesn't guarantee
that a participant is blocked from joining the conference. Any other that a participant is blocked from joining the conference. Any other
rule that might evaluate to true for this participant that carried an rule that might evaluate to true for this participant that carried an
action whose value was higher than block would automatically grant action whose value was higher than block would automatically grant
confirm/allow permission to that participant. confirm/allow permission to that participant.
4.3.4.3 Transformations 4.3.7.3 Transformations
4.3.4.3.1 Key Participant 4.3.7.3.1 Key Participant
When the <is-key-participant> element is set to TRUE, the joining When the <is-key-participant> element is set to TRUE, the joining
participant is denoted as a key participant. If set to FALSE, the participant is denoted as a key participant. If set to FALSE, the
participant is not denoted as a key participant. participant is not denoted as a key participant.
If this element is undefined, it has a value of FALSE, causing no key If this element is undefined, it has a value of FALSE, causing no key
participant status to be given to the participant. participant status to be given to the participant.
4.3.4.3.2 Floor Moderator 4.3.7.3.2 Floor Moderator
When the <is-floor-moderator> element is set to TRUE, the joining When the <is-floor-moderator> element is set to TRUE, the joining
conference participant is denoted as floor moderator, meaning that conference participant is denoted as floor moderator, meaning that
they are privileged to control the floor in the conference. If set they are privileged to control the floor in the conference. If set
to FALSE, floor moderator privileges are not given to the conference to FALSE, floor moderator privileges are not given to the conference
participant. participant.
If this element is undefined, it has a value of FALSE, causing no If this element is undefined, it has a value of FALSE, causing no
floor moderator privileges to being granted. floor moderator privileges to being granted.
4.3.4.3.3 Conference Information 4.3.7.3.3 Conference Information
The <show-conference-info> element is of type boolean transformation. The <show-conference-info> element is of type boolean transformation.
If set to TRUE, conference information is shown to the conference If set to TRUE, conference information is shown to the conference
participant. If set to FALSE, conference information is not shown to participant. If set to FALSE, conference information is not shown to
the participant. the participant.
The <show-conference-info> element controls whether information in The <show-conference-info> element controls whether information in
the <settings>, <time> and <info> elements may be made available the <settings>, <time> and <info> elements may be made available
publicly. For example, an application at a conference server might publicly. For example, an application at a conference server might
list the ongoing conferences on web page, or it may allow searching list the ongoing conferences on web page, or it may allow searching
for conferences based on the keywords listed in the <Conference-info> for conferences based on the keywords listed in the <Conference-info>
element. Not setting this transformation to any users instructs the element. Not setting this transformation to any users instructs the
application not to reveal any such information to any user. However, application not to reveal any such information to any user. However,
information in other elements, such as <dialout-list>, should not be information in other elements, such as <dialout-list>, should not be
seen by anyone else other than a privileged user, even with this seen by anyone else other than a privileged user, even with this
transformation enabled for a user. transformation enabled for a user.
If this element is undefined, it has a value of FALSE, causing no If this element is undefined, it has a value of FALSE, causing no
conference information to being shown. conference information to being shown.
4.3.4.3.4 Floor Holder 4.3.7.3.4 Floor Holder
The <show-floor-holder> element is of type boolean transformation. The <show-floor-holder> element is of type boolean transformation.
If set to TRUE, the conference participant is able to see who is If set to TRUE, the conference participant is able to see who is
currently holding the floor. If set to FALSE, the participant is not currently holding the floor. If set to FALSE, the participant is not
able to see the floor holder. able to see the floor holder.
If this element is undefined, it has a value of FALSE, causing the If this element is undefined, it has a value of FALSE, causing the
floor holder not be shown to the participant. floor holder not be shown to the participant.
4.3.4.3.5 Floor Requests 4.3.7.3.5 Floor Requests
The <show-floor-requests> element is of type boolean transformation. The <show-floor-requests> element is of type boolean transformation.
If set to TRUE, the conference participant is able to see the floor If set to TRUE, the conference participant is able to see the floor
requests. If set to FALSE, the conference participant is not able to requests. If set to FALSE, the conference participant is not able to
see floor requests. see floor requests.
If this element is undefined, it has a value of FALSE, causing the If this element is undefined, it has a value of FALSE, causing the
floor requests to not being seen by the conference participant. floor requests to not being seen by the conference participant.
4.3.4.3.6 Providing anonymity 4.3.7.3.6 Providing anonymity
A rule can be set that provides anonymity to a specific identity. In A rule can be set that provides anonymity to a specific identity. In
this case, the focus provides to the rest of the participants an this case, the focus provides to the rest of the participants an
anonymous identity for that user, for example anonymous1. This can anonymous identity for that user, for example anonymous1. This can
be achieved by using the <provide-anonymity> element. It is a be achieved by using the <provide-anonymity> element. It is a
boolean transformation. If set to TRUE, the conference participants boolean transformation. If set to TRUE, the conference participants
will see an anonymous identity for the user whose identity is present will see an anonymous identity for the user whose identity is present
in the conditions. An example of such rule follows: in the conditions. An example of such rule follows:
<rule id="4"> <rule id="4">
skipping to change at page 20, line 24 skipping to change at page 23, line 46
<join-handling>allow</join-handling> <join-handling>allow</join-handling>
</actions> </actions>
<transformations> <transformations>
<provide-anonymity> <provide-anonymity>
</transformation> </transformation>
</rule> </rule>
If this element is undefined, it has a value of FALSE, causing the If this element is undefined, it has a value of FALSE, causing the
identity to be revealed. identity to be revealed.
4.3.5 Conference Dial-Out List
The dial-out list (DL) is a list of user URIs that the focus uses to
learn who to invite to join a conference. This list can be created
at conference policy creation time or updated during the conference
lifetime so it can be used for mid-conference invites (and
mass-invites) as well.
Asking the focus to invite (add) a user into the conference is
achieved by adding that user's URI to the Dial-Out List (DL). The
CPS then triggers the focus to send the conference invitation, eg:
SIP INVITE as needed. Similarly, a user can be removed from the
Dial-out list by removing the URI from the dial-out list.
The <dialout-list> element is optional and includes zero or more
<target> elements and zero or more <external> elements. Those two
elements includes the mandatory 'uri' attribute. The use of the
<external> element is described in more detail in Section 5.2
4.3.6 Conference Refer List
The Refer List (RL) contains a list of resources that the focus needs
to refer to the conference. In SIP, this is achieved by the focus
sending a REFER request to those potential participants. This list
can be updated during the conference lifetime so it can be used for
mid-conference refers as well.
The Refer List differs from the Dial-out list in that the dial-out
list contains a list of resources that the focus will initiate a
session with. The resources on the refer list, on the other had, are
expected to initiate the session establishment towards the focus
themselves. It is also envisioned that difference users will have
different access rights to those lists and therefore a separation
between the two is needed.
The <refer-list> element is optional and identical to the
<dialout-list> element in Section 4.3.5.
4.3.7 Conference Media Streams
Media policy is an integral part of the conference policy. It
defines e.g. what kind of media topologies exist in the conference.
Media policy is documented in [20].This document does not define
media policy, but instead enables the user to specify the media
streams a conference has. This is used by the focus to know what
media streams to invite users with and what media streams it should
accept from dialling in users. Media can be added to or removed from
a conference by a privileged user before or during a conference
occurance. This might result in the focus modifying the session it
has with each participant. In SIP, this means re-issuing and INVITE
request modifying the session description (SDP).
The definition starts with the optional <media-streams> element.
This element lists the media streams allowed for this conference. It
can contain at most one of each media type using the <video>,
<audio>, <message> and <text> elements.
4.4 XML Schema Extensibility 4.4 XML Schema Extensibility
The schema as be extended at multiple places: The schema as be extended at multiple places:
o The <conference> element to enable more conference policy o The <conference> element to enable more conference policy
information to be added information to be added
o The <settings> element to allow for future conference settings to o The <settings> element to allow for future conference settings to
be defined be defined
skipping to change at page 22, line 17 skipping to change at page 24, line 30
o The <media-streams> element to allow introduction of new media o The <media-streams> element to allow introduction of new media
streams streams
o The <sidebar> element to allow introduction of new sidebar o The <sidebar> element to allow introduction of new sidebar
information information
4.5 XML Schema 4.5 XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:conference-policy" elementFormDefault="qualified"> <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-policy" xmlns:cr="urn:ietf:params:xml:ns:common-policy" xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<!-- This import brings in the XML language attribute xml:lang--> <!-- 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"/> <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"/>
<!-- The root Conference Element --> <!-- The root Conference Element -->
<xs:element name="conference"> <xs:element name="conference">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="settings" type="ConferenceSettings"/> <xs:element name="settings" type="ConferenceSettings"/>
<xs:element name="info" type="ConferenceInfo" minOccurs="0"/> <xs:element name="info" type="ConferenceInfo" minOccurs="0"/>
<xs:element name="time" type="ConferenceTime" minOccurs="0"/> <xs:element name="time" type="ConferenceTime" minOccurs="0"/>
<xs:element name="authorization-rules" type="ConferenceAuthorizationRules" minOccurs="0"/> <xs:element name="dialout-list" type="UserList" minOccurs="0"/>
<xs:element name="dailout-list" type="UserList" minOccurs="0"/>
<xs:element name="refer-list" type="UserList" minOccurs="0"/> <xs:element name="refer-list" type="UserList" minOccurs="0"/>
<xs:element name="media-streams" type="ConferenceMediaStreams" minOccurs="0"/> <xs:element name="media-streams" type="ConferenceMediaStreams" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
<xs:element ref="cr:ruleset"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<!-- Conference Settings --> <!-- Conference Settings -->
<xs:complexType name="ConferenceSettings"> <xs:complexType name="ConferenceSettings">
<xs:sequence> <xs:sequence>
<xs:element name="conference-uri" type="xs:anyURI" maxOccurs="unbounded"/> <xs:element name="conference-uri" type="xs:anyURI" maxOccurs="unbounded"/>
<xs:element name="max-participant-count" type="xs:nonNegativeInteger" minOccurs="0"/> <xs:element name="max-participant-count" type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:element name="security-level" type="SecurityLevel" default="medium" minOccurs="0"/> <xs:element name="security-level" type="SecurityLevel" default="medium" minOccurs="0"/>
<xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/> <xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/>
skipping to change at page 23, line 42 skipping to change at page 26, line 8
<xs:element name="mixing-stop-time" type="StartStopTime" minOccurs="0"/> <xs:element name="mixing-stop-time" type="StartStopTime" minOccurs="0"/>
<xs:element name="can-join-after" type="xs:dateTime" minOccurs="0"/> <xs:element name="can-join-after" type="xs:dateTime" minOccurs="0"/>
<xs:element name="must-join-before" type="xs:dateTime" minOccurs="0"/> <xs:element name="must-join-before" type="xs:dateTime" minOccurs="0"/>
<xs:element name="request-users" type="StartStopTime" minOccurs="0"/> <xs:element name="request-users" type="StartStopTime" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- Conferenece Authorisation -->
<xs:complexType name="ConferenceAuthorizationRules">
<xs:sequence>
<xs:element name="rule" type="ruleType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ruleType">
<xs:sequence>
<xs:element name="conditions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="condition" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="actions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="action" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="transformations" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="transformation" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
<xs:element name="condition" abstract="true"/>
<xs:element name="action" abstract="true"/>
<xs:element name="transformation" abstract="true"/>
<xs:element name="validity" substitutionGroup="condition">
<xs:complexType>
<xs:all>
<xs:element name="from" type="xs:dateTime"/>
<xs:element name="to" type="xs:dateTime"/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="identity" substitutionGroup="condition">
<xs:complexType>
<xs:choice>
<xs:element name="id" type="xs:string" maxOccurs="unbounded"/>
<xs:sequence>
<xs:element name="domain" type="xs:string"/>
<xs:sequence minOccurs="0">
<xs:element name="except" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
<xs:sequence>
<xs:element name="any" type="xs:string"/>
<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="pseudonymous" type="xs:string" substitutionGroup="condition"/>
<xs:element name="has-been-referred" type="xs:string" substitutionGroup="condition"/>
<xs:element name="has-been-invited" type="xs:string" substitutionGroup="condition"/>
<xs:element name="has-been-in-conference" type="xs:string" substitutionGroup="condition"/>
<xs:element name="is-in-conference" type="xs:string" substitutionGroup="condition"/>
<xs:element name="key-participant" type="xs:string" substitutionGroup="condition"/>
<xs:element name="is-on-dialout-list" type="xs:string" substitutionGroup="condition"/>
<xs:element name="is-on-refer-list" type="xs:string" substitutionGroup="condition"/>
<xs:element name="floor-id" type="xs:anyURI" substitutionGroup="condition"/>
<xs:element name="pin" type="xs:anyURI" substitutionGroup="condition"/>
<xs:element name="password" type="xs:anyURI" substitutionGroup="condition"/>
<xs:element name="allow-conference-state" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="allow-floor-events" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="join-handling" type="JoinHandling" substitutionGroup="action"/>
<xs:element name="allow-refer-users-dynamically" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="allow-invite-users-dynamically" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="floor-request-handling" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="is-key-participant" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="is-floor-moderator" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="show-conference-info" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="show-floor-holder" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="show-floor-requests" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="provide-anonymity" type="xs:boolean" substitutionGroup="transformation"/>
<!-- User List --> <!-- User List -->
<xs:complexType name="UserList"> <xs:complexType name="UserList">
<xs:sequence> <xs:sequence>
<xs:element name="target" type="Target" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="target" type="Target" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="external" type="Target" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="external" type="Target" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- Conference Media Streams --> <!-- Conference Media Streams -->
<xs:complexType name="ConferenceMediaStreams"> <xs:complexType name="ConferenceMediaStreams">
<xs:sequence> <xs:sequence>
skipping to change at page 27, line 7 skipping to change at page 27, line 26
</xs:simpleType> </xs:simpleType>
<!-- Sidebar --> <!-- Sidebar -->
<xs:complexType name="Sidebar"> <xs:complexType name="Sidebar">
<xs:sequence> <xs:sequence>
<xs:element name="uri" type="xs:anyURI" maxOccurs="unbounded"/> <xs:element name="uri" type="xs:anyURI" maxOccurs="unbounded"/>
<xs:element name="policy" type="xs:anyURI" minOccurs="0"/> <xs:element name="policy" type="xs:anyURI" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType> </xs:complexType>
<!-- Conferenece Authorisation -->
<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="pseudonymous" type="xs:string" substitutionGroup="cr:condition"/>
<xs:element name="has-been-referred" type="xs:string" substitutionGroup="cr:condition"/>
<xs:element name="has-been-invited" type="xs:string" substitutionGroup="cr:condition"/>
<xs:element name="has-been-in-conference" type="xs:string" substitutionGroup="cr:condition"/>
<xs:element name="is-in-conference" type="xs:string" substitutionGroup="cr:condition"/>
<xs:element name="key-participant" type="xs:string" substitutionGroup="cr:condition"/>
<xs:element name="is-on-dialout-list" type="xs:string" substitutionGroup="cr:condition"/>
<xs:element name="is-on-refer-list" type="xs:string" substitutionGroup="cr:condition"/>
<xs:element name="floor-id" type="xs:anyURI" substitutionGroup="cr:condition"/>
<xs:element name="participant-passcode" substitutionGroup="cr:condition"/>
<xs:element name="key-participant-passcode" substitutionGroup="cr:condition"/>
<xs:element name="allow-conference-state" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-floor-events" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="join-handling" type="JoinHandling" substitutionGroup="cr:action"/>
<xs:element name="allow-refer-users-dynamically" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-invite-users-dynamically" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-remove-users-dynamically" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="floor-request-handling" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="is-key-participant" type="xs:boolean" substitutionGroup="cr:transformation"/>
<xs:element name="is-floor-moderator" type="xs:boolean" substitutionGroup="cr:transformation"/>
<xs:element name="show-conference-info" type="xs:boolean" substitutionGroup="cr:transformation"/>
<xs:element name="show-floor-holder" type="xs:boolean" substitutionGroup="cr:transformation"/>
<xs:element name="show-floor-requests" type="xs:boolean" substitutionGroup="cr:transformation"/>
<xs:element name="provide-anonymity" type="xs:boolean" substitutionGroup="cr:transformation"/>
</xs:schema> </xs:schema>
5. Conference Policy Manipulation and Conference Entity Behaviour 5. Conference Policy Manipulation and Conference Entity Behaviour
5.1 Overview of Operation 5.1 Overview of Operation
This document assumes that the user knows the location of conference This document assumes that the user knows the location of conference
policy serve, the details of that discovery are beyond the scope of policy serve, the details of that discovery are beyond the scope of
this document. this document.
skipping to change at page 27, line 32 skipping to change at page 28, line 48
Some assumptions about the conferencing architecture are made. Some assumptions about the conferencing architecture are made.
Clients always connect to the conference policy server (CPS) when Clients always connect to the conference policy server (CPS) when
they perform manipulation operations. It is assumed that the CPS they perform manipulation operations. It is assumed that the CPS
informs other conferencing entities, such as focus, the floor control informs other conferencing entities, such as focus, the floor control
server and the mixer directly or via the focus. For example, if user server and the mixer directly or via the focus. For example, if user
A wants to expel user B from an ongoing conference, user A must first A wants to expel user B from an ongoing conference, user A must first
manipulate the conference policy data. The CPS then communicates manipulate the conference policy data. The CPS then communicates
that change to the focus to perform the operation. that change to the focus to perform the operation.
User privileges are defined in [19] User privileges are defined in [16]
5.2 Use of External Lists 5.2 Use of External Lists
External lists MAY be used in a conference policy. They can be used External lists MAY be used in a conference policy. They can be used
in the dial-out list, the refer-list and the authorization policy. in the dial-out list, the refer-list and the authorization policy.
An external list is a list of resources created by means outside the An external list is a list of resources created by means outside the
scope of this document. scope of this document.
A privileged user of the conference policy uses an external list by A privileged user of the conference policy uses an external list by
placing its URI in an conference policy element that is dedicated to placing its URI in an conference policy element that is dedicated to
carrying external list URIs. The external list URI is the URI used carrying external list URIs. The external list URI is the URI used
to manipulate the list and not the URI used to signal to the list. to manipulate the list and not the URI used to signal to the list.
There are three such elements documented in this memo: the There are three such elements documented in this memo: the
<external-list> element in the authorization rules (Section <external-list> element in the authorization rules (Section
4.3.4.1.2.4) and the <external> element in both, the dialout list 4.3.7.1.4.2) and the <external> element in both, the dialout list
(Section 4.3.5) and the refer list (Section 4.3.6). At the time the (Section 4.3.4) and the refer list (Section 4.3.5). At the time the
focus needs to activate the policy surrounding the URI, the focus focus needs to activate the policy surrounding the URI, the focus
fetches the URIs for the members of the external list using the list fetches the URIs for the members of the external list using the list
URI. For example, a conference creator creates a conference and URI. For example, a conference creator creates a conference and
places the URI of an external list in the dial-out list. At some places the URI of an external list in the dial-out list. At some
point, the focus needs to invite using on the dial-out list to join point, the focus needs to invite using on the dial-out list to join
the conference. It is at that moment that the focus retrieves the the conference. It is at that moment that the focus retrieves the
members of the external list. It then sends INVITE (in SIP terms) to members of the external list. It then sends INVITE (in SIP terms) to
the members of that external list. This results in all participants the members of that external list. This results in all participants
connected to one focus. connected to one focus.
skipping to change at page 31, line 6 skipping to change at page 32, line 14
6. Examples 6. Examples
6.1 A Simple Conference Policy Document 6.1 A Simple Conference Policy Document
The simplist of a conference policy document contains the conference The simplist of a conference policy document contains the conference
URI, a dial-out list, and the media. An example looks like URI, a dial-out list, and the media. An example looks like
this: this:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cr="urn:ietf:params:xml:ns:common-policy">
<settings> <settings>
<conference-uri>sip:myconference@example.com</conference-uri> <conference-uri>sip:myconference@example.com</conference-uri>
</settings> </settings>
<dailout-list> <dialout-list>
<target uri="sip:bob@example.com"/> <target uri="sip:bob@example.com"/>
<target uri="sip:alice@example.com"/> <target uri="sip:alice@example.com"/>
<target uri="sip:john@example.com"/> <target uri="sip:john@example.com"/>
<target uri="sip:robert@example.com"/> <target uri="sip:robert@example.com"/>
</dailout-list> </dialout-list>
<media-streams> <media-streams>
<audio/> <audio/>
</media-streams> </media-streams>
<cr:ruleset/>
</conference> </conference>
6.2 A Complex Conference Policy Document 6.2 A Complex Conference Policy Document
Alice creates a conference with the follows policy: Alice creates a conference with the follows policy:
o Conference URIs are suggested to be sip:myconference@example.com o Conference URIs are suggested to be sip:myconference@example.com
and tel:+3581234567. and tel:+3581234567.
o Maximum number of participants in the conference is 10. o Maximum number of participants in the conference is 10.
skipping to change at page 32, line 4 skipping to change at page 33, line 18
join half an hour before media mixing ends. join half an hour before media mixing ends.
o Users are requested to join a conference (invited and referred) 5 o Users are requested to join a conference (invited and referred) 5
minutes before the conference starts and no participant nor minutes before the conference starts and no participant nor
key-participant is needed for this action to take place. key-participant is needed for this action to take place.
o Everyone at the domain example.com is allowed to join and can o Everyone at the domain example.com is allowed to join and can
subscribe to the conference state event package. subscribe to the conference state event package.
o Alice is a key participant o Alice is a key participant
o Alice will be invited to join the conference while Sarah will be o Alice will be invited to join the conference while Sarah will be
referred to the conference. referred to the conference.
o Two media are made available in the conference:audio and video. o Two media are made available in the conference:audio and video.
The resulting CPCP document looks like The resulting CPCP document looks like
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cr="urn:ietf:params:xml:ns:common-policy">
<settings> <settings>
<conference-uri>sip:myconference@example.com</conference-uri> <conference-uri>sip:myconference@example.com</conference-uri>
<max-participant-count>10</max-participant-count> <max-participant-count>10</max-participant-count>
<allow-sidebars>true</allow-sidebars> <allow-sidebars>true</allow-sidebars>
</settings> </settings>
<info xml:lang="en-us"> <info xml:lang="en-us">
<subject>What's happening tonight</subject> <subject>What's happening tonight</subject>
<display-name>Party Goer's</display-name> <display-name>Party Goer's</display-name>
<free-text>John and Peter will join the conference soon</free-text> <free-text>John and Peter will join the conference soon</free-text>
<keywords>party nightclub beer</keywords> <keywords>party nightclub beer</keywords>
skipping to change at page 32, line 39 skipping to change at page 34, line 11
</info> </info>
<time> <time>
<occurrence> <occurrence>
<mixing-start-time required-participant="participant">2004-12-17T09:30:00-05:00</mixing-start-time> <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> <mixing-stop-time required-participant="none">2004-12-17T12:30:00-05:00</mixing-stop-time>
<can-join-after>2001-12-17T09:25:00-05:00</can-join-after> <can-join-after>2001-12-17T09:25:00-05:00</can-join-after>
<must-join-before>2004-12-17T12:00:00-05:00</must-join-before> <must-join-before>2004-12-17T12:00:00-05:00</must-join-before>
<request-users required-participant="none">2001-12-17T09:30:00-05:00</request-users> <request-users required-participant="none">2001-12-17T09:30:00-05:00</request-users>
</occurrence> </occurrence>
</time> </time>
<authorization-rules> <dialout-list>
<rule id="1">
<conditions>
<identity>
<domain>example.com</domain>
</identity>
</conditions>
<actions>
<allow-conference-state>true</allow-conference-state>
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
<rule id="2">
<conditions>
<identity>
<id>alice@example.com</id>
</identity>
</conditions>
<actions/>
<transformations>
<is-key-participant>true</is-key-participant>
</transformations>
</rule>
</authorization-rules>
<dailout-list>
<target uri="sip:bob@example.com"/> <target uri="sip:bob@example.com"/>
</dailout-list> </dialout-list>
<refer-list> <refer-list>
<target uri="sip:sarah@example.com"/> <target uri="sip:sarah@example.com"/>
</refer-list> </refer-list>
<media-streams> <media-streams>
<video/> <video/>
<audio/> <audio/>
</media-streams> </media-streams>
<cr:ruleset>
<cr:rule id="1">
<cr:conditions>
<cr:identity>
<cr:domain>example.com</cr:domain>
</cr:identity>
</cr:conditions>
<cr:actions>
<allow-conference-state>true</allow-conference-state>
<join-handling>allow</join-handling>
</cr:actions>
<cr:transformations/>
</cr:rule>
<cr:rule id="2">
<cr:conditions>
<cr:identity>
<cr:id>alice@example.com</cr:id>
</cr:identity>
</cr:conditions>
<cr:actions/>
<cr:transformations>
<is-key-participant>true</is-key-participant>
</cr:transformations>
</cr:rule>
</cr:ruleset>
</conference> </conference>
7. Security Considerations 7. Security Considerations
A conference document may contain information that is highly A conference policy document may contain information that is highly
sensitive. Its delivery to the conference server needs to happen sensitive. Its delivery to the conference server needs to happen
strictly, paying special attention to integrity and confidentiality. strictly, paying special attention to integrity and confidentiality.
Reading the document is also a security concern since the conference Reading the document is also a security concern since the conference
policy contains sensitive information like the topic of the policy contains sensitive information like the topic of the
conference, who is allowed to join and the URIs of the users that can conference, who is allowed to join and the URIs of the users that can
participate. participate.
Manipulations of the conference policy have similar security issues. Manipulations of the conference policy have similar security issues.
Users with relevant privileges can manipulate parts of the conference Users with relevant privileges can manipulate parts of the conference
policy giving themselves and others privileges to manipulate the policy. A user impersonating another may make changes to a
conference policy, including the dial-out list and the security level conference policy. This can happen because the conference policy may
settings for a conference. This can happen because the conference have a companion conference policy provileges document that carries
policy itself carries the identities and the authorization rules that the identities and the authorization rules that apply to those
apply to those identities. Those authorization rules carry the identities. Those authorization rules carry the privileges that
privileges that certain identities have. If an unauthorized user certain identities have. If an unauthorized user gets access to the
gets access to this document (pretending to be someone else), s/he conference policy document (pretending to be someone else), s/he can
can manipulate those rules giving himself and other unauthorized manipulate parts of the conference policy under a false identity.
users access to the conference policy. S/he can also manipulate Some of the things that a malicious user can do include: giving
other parts of the conference policy under a false identity. Some of himself floor moderation, removing users from lists, removing rules
the things that a malicious user can do include: denying users for certain identities, changing the media streams and changing
certain privileges, giving himself floor moderation, removing users
from lists, removing rules for certain identities, giving privileges
to other malicious users, changing the media streams and changing
conference time. Therefore, it is very important that only conference time. Therefore, it is very important that only
authorized clients are able to manipulate the conference policy. Any authorized clients are able to manipulate the conference policy. Any
conference policy transport protocol MUST provide authentication, conference policy transport protocol MUST provide authentication,
confidentiality and integrity. confidentiality and integrity.
In the case that XCAP is used to create and manipulate a conference Passcodes are generated and distributed by means outside the scope of
policy, the XCAP base specification mandates that all XCAP servers this document. The distribution mechanism MUST be secure. If
MUST implement HTTP Authentication: Basic and Digest Access distributed via email, it is recommented that the emails are signed
Authentication [16]. Furthermore, XCAP servers MUST implement HTTP and ecrypted.
over TLS [17]. It is recommended that administrators of XCAP servers
use an HTTPS URI as the XCAP root services URI, so that the digest External lists are have also potential of abuse. A focus bringing in
client authentication occurs over TLS. By using these means, XCAP identities to a conference using an external list MUST make sure that
client and server can ensure the confidentiality and integrity of the the list is created an maintained in a secure manner. It is NOT
XCAP created conference policy document and its manipulation RECOMMENDED for a focus to use external lists that are not within its
operations, and that only authorized clients are allowed to perform trust domain.
them.
A focus accepting a user requesting pseudonymity into a conference
may result in a user impersonating another. The imporsonation cannot
be detectable by the focus and may cause other users that rely of a
user interface providing names of participants to be misinformed. Of
course the focus does not rely on the pseudonym to authenticate a
user. A conference creator needs to be careful when creating such
rules allowing pseudonymity. A safer rule to have is for the
conference policy itself to provide the transformation
<provide-pseudonymity>. this, however, requires the user to ask the
creator or a privileged user, out of band, to provide such rule that
gives that user pseudonymity.
8. IANA Considerations 8. IANA Considerations
8.1 XCAP Application Usage ID 8.1 XCAP Application Usage ID
This section registers a new XCAP Application Usage ID (AUID) This section registers a new XCAP Application Usage ID (AUID)
according to the IANA procedures defined in.. according to the IANA procedures defined in..
Name of the AUID: conference-policy Name of the AUID: conference-policy
Description: Conference policy application manipulates conference Description: Conference policy application manipulates conference
skipping to change at page 36, line 34 skipping to change at page 37, line 49
Jose Costa-Requena Jose Costa-Requena
Simo Veikkolainen Simo Veikkolainen
Teemu Jalava Teemu Jalava
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Markus Isomaki, Adam Roach, Eunsook The authors would like to thank Markus Isomaki, Adam Roach, Eunsook
Kim, Roni Evan, Alan Johnston, Hannes Tschofenig and the IETF XCON Kim, Roni Evan, Alan Johnston, Hannes Tschofenig, Cullen Jennings,
working group for their feedback and suggestions. Rohan Mahy and the IETF XCON working group for their feedback and
suggestions.
11. References
11.1 Normative References 11 Normative References
[1] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J. and J. [1] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J. and J.
Rosenberg, "Common Policy", Internet-Draft Rosenberg, "Common Policy", Internet-Draft
I-D.ietf-geopriv-common-policy, February 2004. I-D.ietf-geopriv-common-policy, February 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997. Levels", RFC 2119, BCD 14, March 1997.
[3] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Moats, R., "URN Syntax", RFC 2141, May 1997.
skipping to change at page 38, line 5 skipping to change at page 39, line 19
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-01 (work in draft-ietf-sipping-conferencing-framework-01 (work in
progress), October 2003. progress), October 2003.
[14] Rosenberg, J., Shulzrinne, H. and O. Levin, "A Session [14] Rosenberg, J., Shulzrinne, H. and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State", Initiation Protocol (SIP) Event Package for Conference State",
draft-ietf-sipping-conference-package-03, February 2004. draft-ietf-sipping-conference-package-03, February 2004.
[15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[16] Franks, J., "HTTP Authentication: Basic and Digest Access [16] Khartabil, H. and A. Niemi, "Privileges for Manipulating a
Authentication", RFC 2617, June 1999.
[17] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
11.2 Informative References
[18] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars",
draft-rosen-xcon-conf-sidebars-00 (work in progress), July
2004.
[19] Khartabil, H. and A. Niemi, "Privileges for Manipulating a
Conference Policy", Conference Policy",
draft-ietf-xcon-conference-policy-privileges-00 (work in draft-ietf-xcon-conference-policy-privileges-00 (work in
progress), September 2004. progress), September 2004.
[20] Jennings, C. and B. Rosen, "Media Mixer Control for XCON", [17] Jennings, C. and B. Rosen, "Media Mixer Control for XCON",
draft-jennings-xcon-media-control-00 (work in progress), draft-jennings-xcon-media-control-00 (work in progress),
February 2004. February 2004.
[21] Handly, M., Eriksson, G., Jacobson, V. and C. Perkins, [18] Rosen, B. and A. Johnson, "SIP Conferencing: Sub-conferences
"Grouping of Media Lines in SDP", draft-ietf-mmusic-sdp-new-18 and Sidebars", draft-rosen-xcon-conf-sidebars-01 (work in
(work in progress), June 2004. progress), July 2004.
Authors' Addresses Authors' Addresses
Hisham Khartabil Hisham Khartabil
Nokia Nokia
P.O. Box 321 P.O. Box 321
Helsinki FIN-00045 Helsinki FIN-00045
Finland Finland
EMail: hisham.khartabil@nokia.com EMail: hisham.khartabil@nokia.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/