[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/