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 element . . . . . . . . . . . . . . . 14 11.2 element . . . . . . . . . . . . . . . . . 14 11.3 element . . . . . . . . . . . . . . . . . 15 11.4 (Privilege Control List) element . . . . . . . . . . . 16 11.5 (Security Control) element . . . . . . . . . . . . . . 17 11.6
(Dial-Out List) element . . . . . . . . . . . . . . . . 18 11.7 (Access Control List) element . . . . . . . . . . . . 19 11.8 element . . . . . . . . . . . . . . . . . . 21 11.9 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 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. 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). element includes the number of maximum number of participants allowed in the conference. When participants are in the conference, new users are not allowed to join anymore. 11.2 element Optional 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 element, which describes the current topic in a conference. The optional element is the display name of the conference, which usually does not change over time. and 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 element gives additional information about the conference. Optional 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. element is mandatory, while , , and are optional. Note that the conference host is not necessarily the same as the conference moderator. 11.3 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 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). has its own XML namespace. It contains one or more elements MAY be used if a conference is active at multiple irregularly spaced times; each additional 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 and 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 could define the conference to be active at 10am on Monday until 11am on Monday, while the second defines the conference to active at 11am on Tuesday until 1pm on Tuesday. If the conference is active at regular times, a element should be used in addition to and following and elements - in which case the and 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 is set to zero, then the session is not bounded, though it will not become active until after the . If the is also zero, the session is regarded as permanent. 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 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 would be the end of the last session three months later. In this example, the information is contained within a single element. By default all repeat attributes are in seconds. element contains also an optional element. If the element is present, it MUST contain and elements. Those three elements indicate the time that the conference is inactive, overriding any conference occurrences. If the 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 of the element has lapsed. 11.4 (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 (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 element may have one of two values: “visible” or “invisible”. The element controls whether information in the , and 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 element. Setting to "invisible" instructs the application not to reveal any such information. However, information in other elements, such as , should not be seen by anyone else than the policy creator even with 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 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 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 element. Each inside the element identifies a user or a set of users ( may be wildcarded) for which the visibility and authentication mechanism apply. The 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 element defines how the participants should be authenticated. The only defined authorization mechanism in this document is HTTP Digest. The value of the 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 attribute. This attribute is ignored if authentication is set to "none". 11.6
(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
element includes a mandatory element. The element includes four elements for each user in the list: - The mandatory element. This elements carries the URI of the user to be invited. - The optional 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 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 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 (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 ( 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 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 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 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 Koskelainen & Khartabil Expires April 20, 2004 [Page 24] Internet-Draft XCAP CPCP October 2003 Koskelainen & Khartabil Expires April 20, 2004 [Page 25] Internet-Draft XCAP CPCP October 2003 Koskelainen & Khartabil Expires April 20, 2004 [Page 26] Internet-Draft XCAP CPCP October 2003 Koskelainen & Khartabil Expires April 20, 2004 [Page 27] Internet-Draft XCAP CPCP October 2003 Koskelainen & Khartabil Expires April 20, 2004 [Page 28] Internet-Draft XCAP CPCP October 2003 Koskelainen & Khartabil Expires April 20, 2004 [Page 29] Internet-Draft XCAP CPCP October 2003 This element will be completed once the meida policy defines their specific schema This element will be completed once the floor policy creates their specific 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 50 What's happening tonight Party Goer's John and Peter will join the conference soon party nightclub beer sip:Alice@example.com tel:+358401111111 mailto:Alice@example.com http://www.example.com/users/Alice 2003-06-16T10:00:00Z 2003-09-16T12:00:00Z Koskelainen & Khartabil Expires April 20, 2004 [Page 31] Internet-Draft XCAP CPCP October 2003 sip:*@example.com sip:*@* sip:Alice@example.com RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE sip:alice@operator.com 0 3 300 sip:sarah@operator.com 0 3 300 visible sip:*@example.com visible Digest 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 sip:bob@example.com 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 Conference Policy Namespace

Namespace for Conference Policy

application/conference-policy+xml

See RFCXXXX.

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]