[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02
XCON P. Koskelainen
Internet-Draft H. Khartabil
Expires: April 20, 2004 Nokia
October 21, 2003
An Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) Usage for Conference Policy Manipulation
draft-koskelainen-xcon-xcap-cpcp-usage-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes conference policy data elements and the
mechanisms to manipulate them at a server via Conference Policy
Control Protocol (CPCP). Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) is used to implement CPCP. This
document specifies an XML Schema and XCAP application usage that are
needed to implement CPCP.
Koskelainen & Khartabil Expires April 20, 2004 [Page 1]
Internet-Draft XCAP CPCP October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Application Unique ID . . . . . . . . . . . . . . . . . . . 6
5. Computed Data . . . . . . . . . . . . . . . . . . . . . . . 7
6. Overview of Operation . . . . . . . . . . . . . . . . . . . 8
7. Conference Creation and Termination . . . . . . . . . . . . 9
8. User Additions and Expels . . . . . . . . . . . . . . . . . 10
9. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 11
10. Structure of a Conference Policy document . . . . . . . . . 12
11. Structure of XML Document . . . . . . . . . . . . . . . . . 14
11.1 <Conference-settings> element . . . . . . . . . . . . . . . 14
11.2 <Conference-info> element . . . . . . . . . . . . . . . . . 14
11.3 <Conference-time> element . . . . . . . . . . . . . . . . . 15
11.4 <PCL> (Privilege Control List) element . . . . . . . . . . . 16
11.5 <SC> (Security Control) element . . . . . . . . . . . . . . 17
11.6 <DL> (Dial-Out List) element . . . . . . . . . . . . . . . . 18
11.7 <ACL> (Access Control List) element . . . . . . . . . . . . 19
11.8 <Floor-control> element . . . . . . . . . . . . . . . . . . 21
11.9 <Media-Policy> element . . . . . . . . . . . . . . . . . . . 21
12. Additional Constraints . . . . . . . . . . . . . . . . . . . 22
13. Authorization Policies . . . . . . . . . . . . . . . . . . . 23
14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 24
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . 34
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
17.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . . 35
17.2 application/conference-policy+xml mime TYPE . . . . . . . . 35
17.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-policy . . . . . . . . . . 36
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
Normative References . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . 41
Koskelainen & Khartabil Expires April 20, 2004 [Page 2]
Internet-Draft XCAP CPCP October 2003
1. Introduction
SIP conferencing framework [10] defines the mechanisms for
multi-party centralized conferencing in SIP environment. Existing SIP
mechanisms allow users e.g. to join and leave a conference.
Centralized server (called focus) can expel and invite users, and may
have proprietary access control lists and user privilege definitions.
However, in many cases it is useful to have standardized conference
policy elements (such as access control lists) and the standardized
protocol means to manipulate them as defined in conference policy
control protocol requirements [7] document. This document provides
both standardized conference policy elements and XCAP [8] application
usage to manipulate them.
Other mechanisms, such as web page or voice response system can also
be used to manipulate conference policy data.
XCAP is a HTTP 1.1 based protocol that allows clients to read, write,
modify and delete application elements at a server. One application
area which has already adopted XCAP is the manipulation of presence
lists [9].
XCAP has many advantages to be used for conference policy control
protocol. First, it is very simple which is important e.g. in
wireless environments. It is already in use for presence list
manipulation and it is expected that clients supports both
applications. Now they can use same protocol for these purposes.
Koskelainen & Khartabil Expires April 20, 2004 [Page 3]
Internet-Draft XCAP CPCP October 2003
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Koskelainen & Khartabil Expires April 20, 2004 [Page 4]
Internet-Draft XCAP CPCP October 2003
3. Terminology
This document uses terminology from [10]. Some additional definitions
are introduced here.
ACL
Access control list (ACL) defines users who can join to a
conference. Users may have allow, blocked or pending status in
the list. Each conference has its own ACL.
CPS
Conference Policy Server. See [10]
Conference participant
Conference participant is a user who has on-going session (e.g.
SIP dialog) with the conference focus.
Floor control
Floor control is a mechanism that enables applications or users
to gain safe and mutually exclusive or non-exclusive access to
the shared object or resource in a conference.
Dial-Out List (DL)
Dial-out list (DL) is a list of users who the focus needs to
invite to the conference.
PCL
Privilege control control (PCL) defines privileges
(manipulation rights) for a user. Each user in a conference may
have different list of privileges and each conference has its
own PCL.
Koskelainen & Khartabil Expires April 20, 2004 [Page 5]
Internet-Draft XCAP CPCP October 2003
4. Application Unique ID
XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or a vendor tree. This
specification defines the "conference-policy" AUID within the IETF
tree, via the IANA registration in Section 17.
Koskelainen & Khartabil Expires April 20, 2004 [Page 6]
Internet-Draft XCAP CPCP October 2003
5. Computed Data
Conference server must fill the conference URI and return it in the
response when the conference is created, if the conference URI was
not proposed by the client.
Koskelainen & Khartabil Expires April 20, 2004 [Page 7]
Internet-Draft XCAP CPCP October 2003
6. Overview of Operation
This document assumes that the user knows the location (URI) of
conference policy server, the details of that discovery are beyond
the scope of this document.
CPCP is implemented as an XCAP application usage, similarly to
presence list manipulation which is also using XCAP.
CPCP allows clients to manipulate the conference policy at conference
policy server (CPS). CPS is able to inform the focus about changes in
conference policy, if necessary. For example, if new users are added
to the dial-out list, then conference policy server informs the focus
which makes the invitations as requested.
Some assumptions about the conferencing architecture are made.
Clients always connect to the conference policy server (CPS) when
they perform XCAP operations. It is assumed that CPS informs other
conferencing entities, such as focus, floor control server and mixer
directly or via focus. For example, when user expels another user via
XCAP based CPCP, then user must first manipulate policy data in CPS
which then asks the focus to perform the operation. The communication
between different (logical) conferencing elements is beyond the scope
of this document. It can be expected that in most cases CPS includes
also those logical functions.
Conference factory applications may also use CPCP to create the
conference, receive the conference URI, then redirect the conference
creator to the conference URI.
Koskelainen & Khartabil Expires April 20, 2004 [Page 8]
Internet-Draft XCAP CPCP October 2003
7. Conference Creation and Termination
Conference is identified by a conference URI which is hosted by the
server (CPS).
A user may create a new conference at the CPS by using HTTP POST.
Depending on server policy and user privileges, CPS may accept the
creation.
Conference (and its resources) can be deleted permanently using HTTP
DELETE. When the user deletes a conference, CPS MUST also delete all
its subconferences ("sidebars") at a server. Conference sidebars are
separate (independent) URIs at the server.
Current conference instance can be stopped by modifying the
conference time information. This leaves conference ACLs and
privileges intact but stops the conference (i.e. expels all users and
stops media).
Koskelainen & Khartabil Expires April 20, 2004 [Page 9]
Internet-Draft XCAP CPCP October 2003
8. User Additions and Expels
User with sufficient privileges is allowed to perform user management
operations, such as adding a new user to the conference or expelling
a user from the conference. These commands are sent to the conference
policy server. After ensuring that the manipulation command came from
a privileged user, conference policy server asks the focus to perform
the indicated operation, such as SIP INVITE, BYE or REFER.
Invite operation is achieved with HTTP POST. This modifies the
Dial-Out List and then CPS triggers the focus to send the SIP
INVITE(s) as needed. Expel operation uses POST as well, as the user
is put to ACL list with Expelled action. Similarly to an Invite
operation, this trigger CPS to inform the focus about the need to
issue a SIP BYE. This means that user is expelled from current
conference, not allowed to dial-in later and not allowed to be
invited by the focus either (in dial-out case).
Koskelainen & Khartabil Expires April 20, 2004 [Page 10]
Internet-Draft XCAP CPCP October 2003
9. Naming Conventions
There are no naming conventions that need to be defined for this
application usage.
Koskelainen & Khartabil Expires April 20, 2004 [Page 11]
Internet-Draft XCAP CPCP October 2003
10. Structure of a Conference Policy document
Conference policy document is an XML [5] document that MUST be
well-formed and MUST be valid. Conference policy documents MUST be
based on XML 1.0 and MUST be encoded using UTF-8. This specification
makes use of XML namespaces for identifying conference policy
documents and document fragments. The namespace URI for elements
defined by this specification is a URN [2], using the namespace
identifier 'ietf' defined by [3] and extended by [11]. This URN is:
urn:ietf:params:xml:ns:conference-policy
A conference policy document begins with the root element tag
``conference-policy''. Other elements from different namespaces MAY
be present for the purposes of extensibility; elements or attributes
from unknown namespaces MUST be ignored. Conference-policy element
includes following elements:
Conference-settings: This mandatory element includes conference
URI and maximum number of participants. It can occur only once in the document.
Conference-info: This mandatory element includes informational
attributes describing the conference, e.g. for search purposes and to be
included into dial-out session descriptions. It can occur only once in the document.
Conference-time: This optional element includes information
related to conference duration.
ACL: This is optional element for access control list.
PCL: This is optional element for privilege control list.
DL: This is optional element for dial-out list.
SC: This is optional element for security control.
Conference-media-policy: This is mandatory element for conference
media policy.
Conference-floor-policy: This is optional element for
conference media policy.
There is a need for different privileges to exist where users can
modify certain parts of the XML document. This specification does not
specify such privileges and relies on other XCAP usage documents to
define those privileges. If no such XCAP usage document exists, the
base XCAP document defines the default privileges so that only the
creator of the document is the sole user of write access.
This specification, however, makes ready the CPCP XML document to
allow an external usage document to define which parts of such an XML
document a user can modify (which parts of an XML document a user has
read/write access to) by dividing the CPCP XML document into section
each with a separate namespace. It is envisioned that the XCAP usage
document for read/write access of another XCAP XML document uses
Koskelainen & Khartabil Expires April 20, 2004 [Page 12]
Internet-Draft XCAP CPCP October 2003
namespaces as the key to allow/disallow users from reading and/or
modifying that XCAP usage document.
The elements are described in more detail in forthcoming sections.
Koskelainen & Khartabil Expires April 20, 2004 [Page 13]
Internet-Draft XCAP CPCP October 2003
11. Structure of XML Document
11.1 <Conference-settings> element
Conference is identified by the conference URI, which is allocated by
the conference policy server and returned to the client. It is also
possible that client proposes a new name by itself (e.g.
sip:discussion-on-dogs@example.com) as it may be useful to have
human-friendly name in some cases. Server still decides whether it
gives the name proposed by the client. Conference URI can be SIP,
SIPS, or TEL URI. There must be one SIP URI for a conference. Other
URIs are optional. Conference policy server creates the focus for the
conference when the conference instance starts.
<Conference-URI> is a mandatory element and it cannot be changed
during the conference lifetime. It can occur only once in a document.
This is in its own XML namespace, so it is separated from other
elements and hence relevant modification rights (privileges) can be
given more easily to other namespaces.
Conference may be deleted so that conference URI and policy are
deleted permanently (using HTTP DELETE). Current conference instance
may also be inactivated temporarily, e.g. so that conference URI and
policy remain at the server but conference is no longer active (by
modifying conference inactive time).
<Max-participant-count> element includes the number of maximum number
of participants allowed in the conference. When
<Max-participant-count> participants are in the conference, new users
are not allowed to join anymore.
11.2 <Conference-info> element
Optional <Conference-info> element has its own namespace and it can
occur only once in a document. It includes informative conference
paramaters which may be helpful describing the purpose of conference,
e.g. for search purposes or providing contact information for the
host.
Each conference has an optional <Subject> element, which describes
the current topic in a conference. The optional <Display-name>
element is the display name of the conference, which usually does not
change over time.
<Free-text> and <Keywords> are optional elements. They provide
additional textual information about the conference. This information
can be made available to the conference participants or to everyone
Koskelainen & Khartabil Expires April 20, 2004 [Page 14]
Internet-Draft XCAP CPCP October 2003
interested by means not specified here. Examples of usage could be
searching for a conference based on some keywords, providing
additional information to tentative conference participants etc.
Optional <Web-page> element gives additional information about the
conference.
Optional <Host-info> element contains several elements. It gives
additional information about the user who is hosting the conference.
This information can be be included into SDP fields in SIP INVITEs
sent by the focus. <SIP-URI> element is mandatory, while <TEL-URI>,
<Web-page>, and <E-mail> are optional. Note that the conference host
is not necessarily the same as the conference moderator.
11.3 <Conference-time> element
OPEN ISSUE: Do we need times, maybe just relative time and whether it
can be extended or not. If there is separate scheduling application
for future conference reservations, how it is controlled?
The information related to conference time and lifetime is contained
in the <Conference-time> element. The conference may occur only once
for a limited period of time (i.e. it has a limited lifetime), the
conference may be non-bounded (i.e. it does not have a specified end
time), or the conference may be permanent. Bounded conferences may be
repeated after some time interval (e.g. on weekly basis).
<Conference-Time> has its own XML namespace. It contains one or more
<Conference-occurrences each defining the time information of a
single conference occurrence. Multiple <Conference-occurrence>
elements MAY be used if a conference is active at multiple
irregularly spaced times; each additional <Conference-occurrence>
element contains time information for a specific occurrence.
In order to avoid clock synchronizing problems between the client and
the server, new CURRENT_TIME macro is defined. It allows client to
order the change to take place immediately.
For each occurrence, the <Start-time> and <Stop-time> specify start
and stop times for when a conference is active. For example, for a
conference that is to be repeated once on a different time, one
<Conference-occurrence> could define the conference to be active at
10am on Monday until 11am on Monday, while the second
<Conference-occurence> defines the conference to active at 11am on
Tuesday until 1pm on Tuesday.
If the conference is active at regular times, a <Repeat> element
should be used in addition to and following <Start-time> and
<Stop-time> elements - in which case the <Start-time> and <Stop-time>
Koskelainen & Khartabil Expires April 20, 2004 [Page 15]
Internet-Draft XCAP CPCP October 2003
elements specify the start and stop times of the repeat sequence.
If the <Stop-time> is set to zero, then the session is not bounded,
though it will not become active until after the <Start-time>. If
the <Start-time> is also zero, the session is regarded as permanent.
<Repeat> element specifies repeat times for a conference. For
example, if a conference is active at 10am on Monday and 11am on
Tuesday for one hour each week for three months, then the
<Start-time> would be 10am on the first Monday, the "Interval"
attribute would contain a 1 week , the "Active-duration" attribute
would contain 1 hour, and the "offsets" attribute would contain zero
and 25 hours. The corresponding <Stop-time> would be the end of the
last session three months later.
In this example, the information is contained within a single
<Conference-occurrence> element.
By default all repeat attributes are in seconds.
<Conference-time> element contains also an optional <inactive>
element. If the <Inactive> element is present, it MUST contain
<Inactive-start-time> and <Inactive-stop-time> elements. Those three
elements indicate the time that the conference is inactive,
overriding any conference occurrences. If the <inactive> element was
placed while a conference is in progress, the focus is notified of
such a change. The focus in turn terminates all dialogs for that
conference. In SIP, the focus terminates the dialogs by sending a BYE
request to every participant. Any conference occurrence must not
start until the <Inactive-stop-time> of the <Inactive> element has
lapsed.
11.4 <PCL> (Privilege Control List) element
Advanced privilege models can be applied in conferencing context
(e.g. who is allowed to modify ACL, who is allowed to expel users
etc). This document defines only one privilege and leaves the
definition of additional privileges (e.g. who can modify ACL) for
separate documents.
The only privilege defined in this document is
RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE. It defines which users are
allowed to subscribe to the event and be notified.
Each user (possibly wildcarded) may or may not have this privilege.
Further documents may define additional privileges.
ACL-like Privilege Control List (PCL) is introduced as a policy data
Koskelainen & Khartabil Expires April 20, 2004 [Page 16]
Internet-Draft XCAP CPCP October 2003
element. It includes target URI (possibly wildcarded) followed by the
list of privileges.
Example PCL may look like this:
sip:bob@company.com: RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE
sip:*@example.com: RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE
11.5 <SC> (Security Control) element
The conference security encompasses three aspects: controlling the
visibility of a conference, securing the SIP messages, and performing
authentication for individual users.
The mandatory <Visibility> element may have one of two values:
visible or invisible. The <Visibility> element controls whether
information in the <Conference-URI>, <Conference-time> and
<Conference-info> elements may be made available publicly. For
example, an application at a conference server might list the ongoing
conferences on web page, or it may allow searching for conferences
based on the keywords listed in the <Conference-info> element.
Setting <Visibility> to "invisible" instructs the application not to
reveal any such information. However, information in other elements,
such as <ACL>, should not be seen by anyone else than the policy
creator even with <Visibility> set to "visible".
We define two mechanisms for securing the signalling dialogs between
users and the conference policy server: TLS and S/MIME.
TLS is used to provide transport layer security on a hop-by-hop
basis. According to SIP [6], using SIPS URI scheme in a request
signifies that TLS must be used to secure each hop over which the
request is forwarded until the request reaches the SIP entity
responsible for the domain portion of the Request-URI.
When the mandatory <Security-mechanism> in the conference policy has
a value "TLS=true" (thus implying the use of SIPS URI scheme), it is
required that TLS is used end-to-end. In other words, TLS must be
used also on the last hop between the entity responsible for the
domain portion of the Request-URI and the conference policy server.
If end-to-end confidentiality of entire SIP messages is not required
in the conference policy, but it is required that the message bodies
within SIP are encrypted, the <Security-Policy> element must have a
value "S/MIME=true".
TLS and S/MIME may be required independent of each other. In other
words, it may be required to use neither, one, or both depending on
Koskelainen & Khartabil Expires April 20, 2004 [Page 17]
Internet-Draft XCAP CPCP October 2003
the settings of these parameters.
The conference creator defines the visibility of and optionally the
authentication policy for the participants. This is done with the
<SC-target> element.
Each <SC-target-URI> inside the <SC-target> element identifies a user
or a set of users (<SC-target-URI> may be wildcarded) for which the
visibility and authentication mechanism apply.
The <Visibility> element defines whether the participant is visible
to other users.
If the value of this is "invisible", information about a
participant's membership or membership changes must not be included
in the conference event package notifications.
The authentication policy defined in the optional <Authorization-
mechanism> element defines how the participants should be
authenticated. The only defined authorization mechanism in this
document is HTTP Digest. The value of the <Authorization-mechanism>
element is either "Digest" indicating HTTP Digest authentication, or
"none" indicating that no authentication is required.
The password associated with each user in the Digest authentication
is included in the optional <Password> attribute. This attribute is
ignored if authentication is set to "none".
11.6 <DL> (Dial-Out List) element
The purpose of a dial-out list (DL) in a conference is to trigger the
focus to invite users in (e.g. due to charging reasons). This list
can be updated during the conference lifetime so it can be used for
mid-conference invites (and mass-invites) as well.
DL has its own XML namespace. It includes list of users (wildcards
not allowed) and list of parameters for each user. Focus does not
update the DL, so the existing DL users remain in the DL until they
are removed (using DELETE).
The <DL> element includes a mandatory <DL-target> element. The
<DL-target> element includes four elements for each user in the list:
- The mandatory <DL-target-URI> element. This elements carries the
URI of the user to be invited.
- The optional <Delay> element. It indicates how long a focus should
wait, after a conference occurrence start, before it invites a user to
join the conference.
Koskelainen & Khartabil Expires April 20, 2004 [Page 18]
Internet-Draft XCAP CPCP October 2003
- The optional <Repetitions> element. It defines how many attempts,
from the initial invitation, a focus should try to invite a user,
if the previous attempt was unsuccessful.
Repetion value of zero (0) means that invitation attempts are unbound.
- The optional <Repetition-interval> element. It defines between the
delay between each call attempt to that user.
Example DL may be something like this:
sip:bob@example.com: 30, 5-minutes
tel:tim@example2.com: 3, 1-minutes
Two operations can be performed for DL: Add new entry (URI) using
HTTP POST, and Delete current entry using HTTP DELETE. The latter
means that the user is removed from the DL and not called anymore.
11.7 <ACL> (Access Control List) element
The purpose of Access Control List (ACL) is to control who can join
the conference. Conference has one ACL consisting the target and the
action (<Access-type> parameter) for the target. The target is user
URI (or wildcarded user URI). Action is one of Allowed/Blocked/
Pending/Expelled. Allowed means that the target is allowed to join
the conference. Blocked means the opposite and pending means that the
target is put on hold while further processing - such as consulting
the moderator - takes places. Expelled means that user is expelled
from current conference and is not allowed to join or be dialled-out
(even if dial-out list includes user's name).
Example ACL would look like this:
sip:bob@example.com: allowed
sip:*@example.com: blocked
sip:*@company.com: pending
ACL must have default rule for those targets that no matching rule is
found (i.e. "pending" action for *@*).
ACL has its own XML namespace.
Sip: and sips: schemes are treated equally for the same person as ACL
identifies users, not transport methods or authentication
requirements.
"Most-specific expression wins" policy is used if overlapping rules
are found. Basically, this means that user specific rule is searched
first and if it is not found, then most specific wildcard rule is
utilized.
Koskelainen & Khartabil Expires April 20, 2004 [Page 19]
Internet-Draft XCAP CPCP October 2003
Wildcard are allowed in ACL as follows. The domain part is allowed to
be wildcard only if the username is a wildcard. Wildcard in domain
part must be immediately after @-sign. Wildcards can also be used to
to create default access policies, e.g. "*@*" are blocked.
Examples of allowed wildcards are sip:*@example.com, *@*.com, *@*.
Following examples are not allowed: sip:bob@example.*, sip:bob@*.com,
sip:*@example.*.com.
The use of wildcarding has been restricted to avoid ambiguous entries
in the access control list.
Following operations exist for ACL:
Allow(list of targets)
Block(list of targets)
Pending(list of targets)
Expel permanently(list of targets)
Delete(target)
First three commands create a new (or change existing) rule for the
list of targets (user URIs or wildcarded user URIs). They can also
remove unnecessary rules, e.g. if bob@example.com and tom@example.com
are already blocked when new rule defining that *@example.com is
blocked is performed, user specific rules can be safely removed.
HTTP POST is used for Allow/Block/Pending/Expel operations and HTTP
DELETE is used for delete operation. HTTP PUT is used to modify ACL
for the target who already exists in ACL.
Delete copes with (potential) ACL size problem. If the conference is
long-lasting it is possible that new rules are added all the time but
old rules are almost never removed (some of them are rewritten,
though). This leads easily to the situation in which the ACL includes
huge amount of unnecessary rules which are not really needed anymore.
Therefore, there should be a mechanism to delete ACL rule. This can
be achieved with HTTP DELETE. Conference focus may send a
notification which warns that the size of ACL has increased local
limit.
New rule always overrides the old rule. It is server's responsibility
to ensure this. This guarantees that conflicting rules do not exist
(e.g. both allowed and blocked action is defined for same target) and
the order in which ACL is searched is irrelevant.
Blocking user also expels user from the current conference.
Koskelainen & Khartabil Expires April 20, 2004 [Page 20]
Internet-Draft XCAP CPCP October 2003
It is also possible to ask the focus to send REFERs to users so they
can themselves dial in the conference. A Boolean attribute exists in
the <ACL-target-URI> that indicates to the server that the creator of
the conference wishes the focus to send REFER requests to the
identified potential participants when a conference occurrence has
started.
11.8 <Floor-control> element
Floor control in a conference is performed using Floor Control
Protocol (FCP). CPCP only controls via privileges who are allowed to
manipulate floor policy (e.g. create and delete floors). FCP can then
be used to create floor, and assign and de-assign floor moderator for
a given floor. For example, in a typical conference the conference
creator (moderator) first creates a floor for audio plane (using FCP)
and then names one user - possibly himself - (using FCP) to act as a
floor moderator governing the access to the floor. Note that FCP does
not create media streams (just the virtual floor attached to media),
as media streams are created using CPCP.
When the floor has been created and floor moderator has been
assigned, the floor moderator gets notifications from the focus and
is able to accept or deny floor requests (using FCP) from the
conference users. The details of FCP are beyond the scope of this
draft.
User with sufficient privileges (the creator) can create the floors
and assign floor moderator using FCP.
This element has its own XML namespace.
11.9 <Media-Policy> element
Media policy is integral part of the conference policy. It defines
e.g. what kind of media topologies exist in the conference. The
details of media manipulation are defined elsewhere
(draft-mahy-sipping-media-policy-control-00.txt). User with
sufficient privileges is allowed to create, modify and delete media
policy (e.g. add new media sessions).
This element has its own XML namespace.
Koskelainen & Khartabil Expires April 20, 2004 [Page 21]
Internet-Draft XCAP CPCP October 2003
12. Additional Constraints
None.
Koskelainen & Khartabil Expires April 20, 2004 [Page 22]
Internet-Draft XCAP CPCP October 2003
13. Authorization Policies
As stated in [8], only the creator of the conference policy may
access and manipulate this document in any way, using CPCP. If the
conference is "visible", then conference information mentioned in
11.3 may be accessed publicly by means outside the scope of this
document. For example, some information about the conference may be
available for search engines, or some parts of conference policy may
be shown on a web page.
Koskelainen & Khartabil Expires April 20, 2004 [Page 23]
Internet-Draft XCAP CPCP October 2003
14. XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-policy"
xmlns:conference-settings="urn:ietf:params:xml:ns:conference-settings"
xmlns:conference-info="urn:ietf:params:xml:ns:conference-info"
xmlns:conference-time="urn:ietf:params:xml:ns:conference-time"
xmlns:conference-acl="urn:ietf:params:xml:ns:conference-acl"
xmlns:conference-pcl="urn:ietf:params:xml:ns:conference-pcl"
xmlns:conference-dl="urn:ietf:params:xml:ns:conference-dl"
xmlns:conference-sc="urn:ietf:params:xml:ns:conference-sc"
xmlns:conference-mp="urn:ietf:params:xml:ns:conference-mp"
xmlns:conference-fp="urn:ietf:params:xml:ns:conference-fp"
elementFormDefault="qualified">
<xs:import namespace="urn:ietf:params:xml:ns:conference-settings"
schemaLocation="conference-settings.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="conference-info.xsd"/>
<xs:import namespace ="urn:ietf:params:xml:ns:conference-time"
schemaLocation = "conference-time.xsd"/>
<xs:import namespace ="urn:ietf:params:xml:ns:conference-acl"
schemaLocation = "conference-acl.xsd"/>
<xs:import namespace ="urn:ietf:params:xml:ns:conference-pcl"
schemaLocation = "conference-pcl.xsd"/>
<xs:import namespace ="urn:ietf:params:xml:ns:conference-dl"
schemaLocation = "conference-dl.xsd"/>
<xs:import namespace ="urn:ietf:params:xml:ns:conference-sc"
schemaLocation = "conference-sc.xsd"/>
<xs:import namespace ="urn:ietf:params:xml:ns:conference-mp"
schemaLocation = "conference-mp.xsd"/>
<xs:import namespace ="urn:ietf:params:xml:ns:conference-fp"
schemaLocation = "conference-fp.xsd"/>
<xs:element name="Conference">
<xs:complexType>
<xs:sequence>
<xs:element name="Conference-settings" type="conference-settings:Conference-settings" minOccurs="1"/>
<xs:element name="Conference-info" type="conference-info:Conference-info" minOccurs="1"/>
<xs:element name="Conference-time" type="conference-time:Conference-time" minOccurs="1"/>
<xs:element name="ACL" type="conference-acl:Conference-ACL" minOccurs="0"/>
<xs:element name="PCL" type="conference-pcl:Conference-PCL" minOccurs="0"/>
<xs:element name="DL" type="conference-dl:Conference-DL" minOccurs="0"/>
Koskelainen & Khartabil Expires April 20, 2004 [Page 24]
Internet-Draft XCAP CPCP October 2003
<xs:element name="SC" type="conference-sc:Conference-SC" minOccurs="0"/>
<!--xs:element name="Conference-media-policy" type="conference-mp:Conference-media-policy"/-->
<!--xs:element name="Conference-floor-policy" type="conference-fp:Conference-floor-policy"/-->
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-settings"
xmlns="urn:ietf:params:xml:ns:conference-settings"
elementFormDefault="qualified">
<xs:complexType name="Conference-settings">
<xs:sequence>
<xs:element name="Conference-uri" minOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="SIP-URI" type="xs:anyURI" minOccurs="1"/>
<xs:element name="TEL-URI" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Max-participant-count" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-info"
elementFormDefault="qualified">
<!-- Conference Info component of the Conference -->
<xs:complexType name="Conference-info">
<xs:sequence>
<xs:element name="Subject" type="xs:string"/>
<xs:element name="Display-name" type="xs:string"/>
<xs:element name="Free-text" type="xs:string"/>
<xs:element name="Keywords">
<xs:simpleType>
<xs:list itemType="xs:string"/>
</xs:simpleType>
Koskelainen & Khartabil Expires April 20, 2004 [Page 25]
Internet-Draft XCAP CPCP October 2003
</xs:element>
<xs:element name="Web-page" type="xs:anyURI"/>
<xs:element name="Host-info">
<xs:complexType>
<xs:sequence>
<xs:element name="SIP-URI" type="xs:anyURI" minOccurs="1"/>
<xs:element name="TEL-URI" type="xs:anyURI"/>
<xs:element name="E-mail" type="xs:anyURI"/>
<xs:element name="Web-page" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-time"
elementFormDefault="qualified">
<!-- Conference time component of the Conference -->
<xs:complexType name="Conference-time">
<xs:sequence>
<xs:element name="Conference-occurrence">
<xs:complexType>
<xs:sequence>
<xs:element name="Start-time" type="xs:dateTime"/>
<xs:element name="Repeat">
<xs:complexType>
<xs:attribute name="Interval" type="xs:nonNegativeInteger"/>
<xs:attribute name="Active-duration" type="xs:nonNegativeInteger"/>
<xs:attribute name="Offsets">
<xs:simpleType>
<xs:list itemType="xs:nonNegativeInteger"/>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="Stop-time" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Inactive" minOccurs="0">
<xs:complexType>
Koskelainen & Khartabil Expires April 20, 2004 [Page 26]
Internet-Draft XCAP CPCP October 2003
<xs:sequence>
<xs:element name="Inactive-start-time" type="xs:dateTime"/>
<xs:element name="Inactive-stop-time" type="xs:dateTime"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-acl"
elementFormDefault="qualified">
<!-- ACL component of the Conference -->
<xs:complexType name="Conference-ACL">
<xs:sequence>
<xs:element name="ACL-target-uri" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="Refer" type="xs:boolean" default="false"/>
<xs:attribute name="Access-type" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Allowed"/>
<xs:enumeration value="Blocked"/>
<xs:enumeration value="Pending"/>
<xs:enumeration value="Expelled"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
Koskelainen & Khartabil Expires April 20, 2004 [Page 27]
Internet-Draft XCAP CPCP October 2003
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-pcl"
elementFormDefault="qualified">
<!-- Privilege Control List (PCL) -->
<xs:complexType name="Conference-PCL">
<xs:sequence>
<xs:element name="PCL-target" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="PCL-target-uri" type="xs:anyURI" minOccurs="1"/>
<xs:element name="Privileges">
<xs:simpleType>
<xs:list>
<!-- Define the privileges as data type with all possible values -->
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-dl"
elementFormDefault="qualified">
<!-- Dial-Out List (DL) -->
<xs:complexType name="Conference-DL">
<xs:sequence>
<xs:element name="DL-target" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DL-target-uri" type="xs:anyURI" minOccurs="1"/>
Koskelainen & Khartabil Expires April 20, 2004 [Page 28]
Internet-Draft XCAP CPCP October 2003
<xs:element name="Delay" type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:element name="Repetitions" type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:element name="Repetition-interval" type="xs:nonNegativeInteger" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-sc"
elementFormDefault="qualified">
<!-- Security Control (SC) -->
<xs:complexType name="Conference-SC">
<xs:sequence>
<xs:element name="Visibility" minOccurs="1">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Visible"/>
<xs:enumeration value="Invisible"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Security-mechanism">
<xs:complexType>
<xs:attribute name="TLS" type="xs:boolean" default="false"/>
<xs:attribute name="S-MIME" type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="SC-target" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="SC-target-uri" type="xs:anyURI" minOccurs="1"/>
<xs:element name="Visibility" minOccurs="1">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Visible"/>
<xs:enumeration value="Invisible"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Authorization-mechanism" minOccurs="1">
<xs:simpleType>
Koskelainen & Khartabil Expires April 20, 2004 [Page 29]
Internet-Draft XCAP CPCP October 2003
<xs:restriction base="xs:string">
<xs:enumeration value="Digest"/>
<xs:enumeration value="None"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
<xs:attribute name="Password" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-mp"
elementFormDefault="qualified">
<xs:element name="Conference-media-policy">
<xs:annotation>
<xs:documentation>
This element will be completed once the meida policy
defines their specific schema
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-fp"
elementFormDefault="qualified">
<xs:element name="Conference-floor-policy">
<xs:annotation>
<xs:documentation>
This element will be completed once the floor policy
creates their specific schema
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:schema>
Koskelainen & Khartabil Expires April 20, 2004 [Page 30]
Internet-Draft XCAP CPCP October 2003
15. Examples
The following is an example of a document compliant to the schema:
Below is an example how to create a conference:
1. Creating a Conference
Alice creates a conference as follows:
PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml HTTP/1.1
Content-Type:application/conference-policy+xml
<?xml version="1.0" encoding="UTF-8"?>
<Conference xmlns="urn:ietf:params:xml:ns:conference-policy"
xmlns:conference-sc="urn:ietf:params:xml:ns:conference-sc"
xmlns:conference-dl="urn:ietf:params:xml:ns:conference-dl"
xmlns:conference-pcl="urn:ietf:params:xml:ns:conference-pcl"
xmlns:conference-acl="urn:ietf:params:xml:ns:conference-acl"
xmlns:conference-time="urn:ietf:params:xml:ns:conference-time"
xmlns:conference-info="urn:ietf:params:xml:ns:conference-info"
xmlns:conference-settings="urn:ietf:params:xml:ns:conference-settings">
<conference-settings:Conference-settings>
<conference-uri:Conference-URI>
<SIP-URI></SIP-URI>
<TEL-URI></TEL-URI>
</conference--uri:Conference-URI>
<Max-participant-count>50<Max-participant-count>
<conference-settings:Conference-settings>
<conference-info:Conference-info>
<Subject>What's happening tonight</Subject>
<Display-name>Party Goer's</Display-name>
<Free-text>John and Peter will join the conference soon</Free-text>
<Keywords>party nightclub beer</Keywords>
<Host-info>
<SIP-URI>sip:Alice@example.com</SIP-URI>
<TEL-URI>tel:+358401111111</TEL-URI>
<E-mail>mailto:Alice@example.com</E-mail>
<Web-page>http://www.example.com/users/Alice</Web-page>
</Host-info>
</conference-info:Conference-info>
<conference--time:Conference-time>
<Conference-occurrence>
<Start-time>2003-06-16T10:00:00Z</Start-time>
<Repeat interval="604800" Active-duration="3600" offsets="0 90000"/>
<Stop-time>2003-09-16T12:00:00Z</Stop-time>
</Conference-occurrence>
Koskelainen & Khartabil Expires April 20, 2004 [Page 31]
Internet-Draft XCAP CPCP October 2003
</conference-time:Conference-time>
<conference-acl:ACL>
<ACL-target-URI Access-type="Allowed">sip:*@example.com</ACL-target-URI>
<ACL-target-URI Access-type="Blocked">sip:*@*</ACL-target-URI>
</conference-acl:ACL>
<conference-pcl:PCL>
<PCL-target>
<PCL-target-URI>sip:Alice@example.com</PCL-target-URI>
<Privileges>RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE</Privileges>
</PCL-target>
<PCL-target>
</conference-pcl:PCL>
<conference-dl:DL>
<DL-target>
<DL-target-URI>sip:alice@operator.com</DL-target-URI>
<Delay>0</Delay>
<Repetitions>3</Repetitions>
<Repetition-interval>300</Repetition-interval>
</DL-target>
<DL-target>
<DL-target-URI>sip:sarah@operator.com</DL-target-URI>
<Delay>0</Delay>
<Repetitions>3</Repetitions>
<Repetition-interval>300</Repetition-interval>
</DL-target>
</conference-dl:DL>
<conference-sc:SC>
<Visibility>visible</Visibility>
<Security-mechanism TLS="false" S-MIME="true"/>
<SC-target>
<SC-target-URI>sip:*@example.com</SC-target-URI>
<Visibility>visible</Visibility>
<Authorization-mechanism password="1a2b3c4d">Digest<Authorization-mechanism>
</SC-target>
</conference-sc:SC>
<Conference-floor-policy>
</Conference-floor-policy>
<Conference-media-policy>
</Conference-media-policy>
</Conference>
At exactly 2003-06-16T10:00:00Z, the conference server creates a focus and
sends SIP INVITE requests to Alice and Sarah. After the focus is created,
SIP INVITE requests can be accepted from anyone at domain example.com.
Any attempts to join the conference by users in other domains are rejected.
2. Expelling a User
Koskelainen & Khartabil Expires April 20, 2004 [Page 32]
Internet-Draft XCAP CPCP October 2003
Continuing with the above example: aftar the conference has started,
Alice decides to expel Bob who has joined the conference. So she adds him to
the ACL list with Access-type of value "Blocked".
OPEN ISSUE: Should there be a attribute defining how long someone
should be expelled for?
The XCAP request looks like:
POST http://xcap.example.com/services/conferences/users/Alice/conference.xml?
Conference/ACL/ACL-target-URI HTTP/1.1
Content-Type:text/plain
<ACL-target-URI Access-type="Explelled">sip:bob@example.com</ACL-target-URI>
At this point, the focus sends a SIP BYE request to Bob ending Bob's participation
in the conference. This also guarantees that Bob cannot rejoin the conference since
he is expilictly expelled until his URI is removed from the ACL Expelled list.
Any attempt Bob makes in rejoining the conference will fail.
3. Allowing An Expelled Participant To Join Again
Continuing with the example above, Alice now decides to allow Bob to join
again after a period of time. She does so by removing his entry in the
ACL that identifies him as "Expelled".
DELETE http://xcap.example.com/services/conferences/users/Alice/conference.xml?
Conference/ACL/ACL-target-URI/ACL-target-URI="sip:bob@example.com" HTTP/1.1
Bob can now rejoin the conference by sending a SIP INVITE request.
4. Removing A Conference
Alice now decides she no longer wants this conference to exist and therefore
deletes the conference:
DELETE http://xcap.example.com/services/conferences/users/Alice/conference.xml
As a result of this action, the focus sends SIP BYE requests to all current
participants in the conference. The conference server terminates the focus thereafter.
Koskelainen & Khartabil Expires April 20, 2004 [Page 33]
Internet-Draft XCAP CPCP October 2003
16. Security Considerations
See section Section 11.5.
Koskelainen & Khartabil Expires April 20, 2004 [Page 34]
Internet-Draft XCAP CPCP October 2003
17. IANA Considerations
17.1 XCAP Application Usage ID
This section registers a new XCAP Application Usage ID (AUID)
according to the IANA procedures defined in..
Name of the AUID: conference-policy
Description: Conference policy application manipulates conference
policy at a server.
17.2 application/conference-policy+xml mime TYPE
MIME media type: application
MIME subtype name: conference-policy+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter applicatioN/xml as
specified in RFC 3023 [6].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [6].
Security considerations: See section 10 of RFC 3023 [6] and section
Section 17 of this document.
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has been
used to support conference policy manipulation for SIP based
conferencing.
Additional information:
Magic number: None
File extension: .cl or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Petri Koskelainen
(petri.koskelainen@nokia.com)
Koskelainen & Khartabil Expires April 20, 2004 [Page 35]
Internet-Draft XCAP CPCP October 2003
Intended Usage: COMMON
Author/change controller: The IETF
17.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-policy
This section registers a new XML namespace, as per guidelines in URN
document [11].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-policy.
Registrant Contact: IETF, XCON working group, Petri Koskelainen
(petri.koskelainen@nokia.com)
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Conference Policy Namespace</title>
</head>
<body>
<h1>Namespace for Conference Policy</h1>
<h2>application/conference-policy+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
Koskelainen & Khartabil Expires April 20, 2004 [Page 36]
Internet-Draft XCAP CPCP October 2003
18. Contributors
Jose Costa-Requena
Simo Veikkolainen
Teemu Jalava
Koskelainen & Khartabil Expires April 20, 2004 [Page 37]
Internet-Draft XCAP CPCP October 2003
19. Acknowledgements
The authors would like to thank Markus Isomäki, Eunsook Kim and IETF
conferencing design team for their feedback.
Koskelainen & Khartabil Expires April 20, 2004 [Page 38]
Internet-Draft XCAP CPCP October 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[4] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC
3261, June 2002.
[5] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000.
[6] Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[7] Koskelainen, P., "Requirements for conference policy control
protocol", draft-koskelainen-xcon-cpcp-req-01 (work in
progress), October 2003.
[8] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-rosenberg-simple-xcap-00 (work in progress), May 2003.
[9] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence Lists",
draft-draft-rosenberg-simple-xcap-list-usage-00 (work in
progress), May 2003.
[10] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-rosenberg-sipping-conferencing-framework-01 (work in
progress), February 2003.
[11] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003.
Koskelainen & Khartabil Expires April 20, 2004 [Page 39]
Internet-Draft XCAP CPCP October 2003
Authors' Addresses
Petri Koskelainen
Nokia
P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721
Finland
EMail: petri.koskelainen@nokia.com
Hisham Khartabil
Nokia
P.O. Box 321
Helsinki FIN-00045
Finland
EMail: hisham.khartabil@nokia.com
Koskelainen & Khartabil Expires April 20, 2004 [Page 40]
Internet-Draft XCAP CPCP October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Koskelainen & Khartabil Expires April 20, 2004 [Page 41]
Internet-Draft XCAP CPCP October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Koskelainen & Khartabil Expires April 20, 2004 [Page 42]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/