idnits 2.17.1 

draft-ietf-xcon-cpcp-01.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 1812.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1789.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1796.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1802.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement. 

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

  ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission
     of drafts without verbatim RFC 3978 boilerplate is not accepted.

     The following non-3978 patterns matched text found in the document. 
     That text should be removed or replaced:

        This document is an Internet-Draft and is subject to all provisions of
        Section 3 of RFC 3667.

        By submitting this Internet-Draft, each author represents that any
        applicable patent or other IPR claims of which he or she is aware
        have been or will be disclosed, and any of which he or she
        becomes aware will be disclosed, in accordance with Section 6 of
        BCP 79.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 48 instances of too long lines in the document, the longest
     one being 173 characters in excess of 72.

  ** There are 336 instances of lines with control characters in the document.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == Line 558 has weird spacing: '...ined in  the c...'

  == Line 888 has weird spacing: '...allowed  to in...'

  == Line 901 has weird spacing: '...allowed  to in...'

  == Line 914 has weird spacing: '...allowed  to in...'

  == Line 1055 has weird spacing: '...o allow  exten...'

  == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
     does not include the phrase in its RFC 2119 key words list.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 12, 2004) is 7137 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: '5' is defined on line 1695, but no explicit reference
     was found in the text

  == Unused Reference: '8' is defined on line 1706, but no explicit reference
     was found in the text

  == Unused Reference: '11' is defined on line 1719, but no explicit
     reference was found in the text

  == Unused Reference: '12' is defined on line 1724, but no explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141)

  ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '4')

  -- Possible downref: Non-RFC (?) normative reference: ref. '6'

  ** Obsolete normative reference: RFC 3023 (ref. '7') (Obsoleted by RFC 7303)

  -- No information found for draft-ietf-xcon-cpcp-req - is the name correct?

  -- Possible downref: Normative reference to a draft: ref. '8' 

  == Outdated reference: A later version (-07) exists of
     draft-ietf-sipping-cc-conferencing-03

  == Outdated reference: A later version (-12) exists of
     draft-ietf-simple-xcap-02

  == Outdated reference: A later version (-05) exists of
     draft-ietf-simple-xcap-list-usage-02

  == Outdated reference: A later version (-03) exists of
     draft-ietf-simple-xcap-package-01

  -- Possible downref: Normative reference to a draft: ref. '12' 

  == Outdated reference: A later version (-05) exists of
     draft-ietf-sipping-conferencing-framework-01

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-sipping-conferencing-framework (ref. '13')

  == Outdated reference: A later version (-12) exists of
     draft-ietf-sipping-conference-package-03

  == Outdated reference: A later version (-01) exists of
     draft-ietf-xcon-conference-policy-privileges-00

  -- Possible downref: Normative reference to a draft: ref. '16' 

  == Outdated reference: A later version (-03) exists of
     draft-jennings-xcon-media-control-00

  -- Possible downref: Normative reference to a draft: ref. '17' 

  -- Possible downref: Normative reference to a draft: ref. '18' 


     Summary: 11 errors (**), 0 flaws (~~), 20 warnings (==), 14 comments
     (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	XCON                                                        H. Khartabil
2	Internet-Draft                                            P. Koskelainen
3	Expires: April 12, 2005                                         A. Niemi
4	                                                                   Nokia
5	                                                        October 12, 2004

7	             The Conference Policy Control Protocol (CPCP)
8	                        draft-ietf-xcon-cpcp-01

10	Status of this Memo

12	   This document is an Internet-Draft and is subject to all provisions
13	   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
14	   author represents that any applicable patent or other IPR claims of
15	   which he or she is aware have been or will be disclosed, and any of
16	   which he or she become aware will be disclosed, in accordance with
17	   RFC 3668.

19	   Internet-Drafts are working documents of the Internet Engineering
20	   Task Force (IETF), its areas, and its working groups.  Note that
21	   other groups may also distribute working documents as
22	   Internet-Drafts.

24	   Internet-Drafts are draft documents valid for a maximum of six months
25	   and may be updated, replaced, or obsoleted by other documents at any
26	   time.  It is inappropriate to use Internet-Drafts as reference
27	   material or to cite them other than as "work in progress."

29	   The list of current Internet-Drafts can be accessed at
30	   http://www.ietf.org/ietf/1id-abstracts.txt.

32	   The list of Internet-Draft Shadow Directories can be accessed at
33	   http://www.ietf.org/shadow.html.

35	   This Internet-Draft will expire on April 12, 2005.

37	Copyright Notice

39	   Copyright (C) The Internet Society (2004).

41	Abstract

43	   The Conference Policy is defined as the complete set of rules for a
44	   particular conference manipulated by the conference policy server.
45	   The Conferece Policy Control Protocol (CPCP) is the protocol used by
46	   clients to manipulate the conference policy.  This document describes
47	   the Conference Policy Control Protocol (CPCP).  It specifies an
48	   Extensible Markup Language (XML) Schema that enumerates the
49	   conference policy data elements that enable a user to define a
50	   conference policy.

52	Table of Contents

54	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
55	   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
56	   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
57	   4.  Structure of a Conference Policy document  . . . . . . . . . .  5
58	     4.1   MIME Type for CPCP XML Document  . . . . . . . . . . . . .  5
59	     4.2   Conference Root  . . . . . . . . . . . . . . . . . . . . .  5
60	     4.3   XML Document Description . . . . . . . . . . . . . . . . .  6
61	       4.3.1   Conference Settings  . . . . . . . . . . . . . . . . .  6
62	       4.3.2   Conference Information . . . . . . . . . . . . . . . .  8
63	       4.3.3   Conference Time  . . . . . . . . . . . . . . . . . . .  9
64	       4.3.4   Conference Dial-Out List . . . . . . . . . . . . . . . 10
65	       4.3.5   Conference Refer List  . . . . . . . . . . . . . . . . 11
66	       4.3.6   Conference Media Streams . . . . . . . . . . . . . . . 11
67	       4.3.7   Conference Authorization Rules . . . . . . . . . . . . 12
68	         4.3.7.1   Conditions . . . . . . . . . . . . . . . . . . . . 12
69	           4.3.7.1.1   Validity . . . . . . . . . . . . . . . . . . . 13
70	           4.3.7.1.2   Identity . . . . . . . . . . . . . . . . . . . 14
71	             4.3.7.1.2.1   Interpreting the <id> Element  . . . . . . 15
72	           4.3.7.1.3   Sphere . . . . . . . . . . . . . . . . . . . . 15
73	           4.3.7.1.4   Conference Policy Identity . . . . . . . . . . 15
74	             4.3.7.1.4.1   Matching Any Identity  . . . . . . . . . . 15
75	             4.3.7.1.4.2   Matching Identities in External Lists  . . 15
76	           4.3.7.1.5   Matching Pseudonymous Identities . . . . . . . 15
77	           4.3.7.1.6   Matching Referred Identities . . . . . . . . . 16
78	           4.3.7.1.7   Matching Invited Identities  . . . . . . . . . 16
79	           4.3.7.1.8   Matching Identities of Former Conference
80	                       Participants . . . . . . . . . . . . . . . . . 17
81	           4.3.7.1.9   Matching Identities Currently in the
82	                       Conference . . . . . . . . . . . . . . . . . . 17
83	           4.3.7.1.10  Matching Key Participant Identities  . . . . . 17
84	           4.3.7.1.11  Matching Identities on the Dial-out List . . . 17
85	           4.3.7.1.12  Matching Identities on the Refer List  . . . . 17
86	           4.3.7.1.13  Floor ID . . . . . . . . . . . . . . . . . . . 17
87	           4.3.7.1.14  Matching Participant Passcodes . . . . . . . . 17
88	           4.3.7.1.15  Matching Passcodes . . . . . . . . . . . . . . 18
89	         4.3.7.2   Actions  . . . . . . . . . . . . . . . . . . . . . 19
90	           4.3.7.2.1   Conference State Events  . . . . . . . . . . . 19
91	           4.3.7.2.2   Floor Control Events . . . . . . . . . . . . . 19
92	           4.3.7.2.3   Conference Join Handling . . . . . . . . . . . 20
93	           4.3.7.2.4   Dynamically Referring Users  . . . . . . . . . 20
94	           4.3.7.2.5   Dynamically Inviting Users . . . . . . . . . . 20
95	           4.3.7.2.6   Dynamically Removing Users . . . . . . . . . . 21
96	           4.3.7.2.7   Floor Request Handling . . . . . . . . . . . . 21

98	         4.3.7.3   Transformations  . . . . . . . . . . . . . . . . . 22
99	           4.3.7.3.1   Key Participant  . . . . . . . . . . . . . . . 22
100	           4.3.7.3.2   Floor Moderator  . . . . . . . . . . . . . . . 22
101	           4.3.7.3.3   Conference Information . . . . . . . . . . . . 22
102	           4.3.7.3.4   Floor Holder . . . . . . . . . . . . . . . . . 22
103	           4.3.7.3.5   Floor Requests . . . . . . . . . . . . . . . . 23
104	           4.3.7.3.6   Providing anonymity  . . . . . . . . . . . . . 23
105	     4.4   XML Schema Extensibility . . . . . . . . . . . . . . . . . 23
106	     4.5   XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 24
107	   5.  Conference Policy Manipulation and Conference Entity
108	       Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
109	     5.1   Overview of Operation  . . . . . . . . . . . . . . . . . . 28
110	     5.2   Use of External Lists  . . . . . . . . . . . . . . . . . . 29
111	     5.3   Communication Between Conference Entities  . . . . . . . . 29
112	     5.4   Manipulating Participant Lists . . . . . . . . . . . . . . 29
113	       5.4.1   Expelling a Participant  . . . . . . . . . . . . . . . 30
114	     5.5   Re-joining a Conference  . . . . . . . . . . . . . . . . . 31
115	   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
116	     6.1   A Simple Conference Policy Document  . . . . . . . . . . . 32
117	     6.2   A Complex Conference Policy Document . . . . . . . . . . . 32
118	   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
119	   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36
120	     8.1   XCAP Application Usage ID  . . . . . . . . . . . . . . . . 36
121	     8.2   application/conference-policy+xml MIME TYPE  . . . . . . . 36
122	     8.3   URN Sub-Namespace Registration for
123	           urn:ietf:params:xml:ns:conference-policy . . . . . . . . . 37
124	   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
125	   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
126	   11.   Normative References . . . . . . . . . . . . . . . . . . . . 38
127	       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
128	       Intellectual Property and Copyright Statements . . . . . . . . 41

130	1.  Introduction

132	   The SIP conferencing framework [13] defines the mechanisms for
133	   multi-party centralized conferencing in a SIP environment.

135	   Existing SIP mechanisms allow users, for example, to join and leave a
136	   conference, as described in [9].  A centralised server, called focus,
137	   can expel and invite users, and may have proprietary access control
138	   lists and user privilege definitions.  This document defines an XML
139	   Schema in Section 4 that enumerates the conference policy data
140	   elements that enable a user to define a conference policy.  This
141	   policy document may be given to a focus using a number of transports
142	   that are outside the scope of this document.

144	   A focus conforming to this specification MUST support the XML object
145	   defined in Section 4.

147	2.  Conventions Used in This Document

149	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
151	   document are to be interpreted as described in RFC 2119 [2].

153	3.  Terminology

155	   This document uses terminology from [13].  Some additional
156	   definitions are introduced here.

158	   Conference authorization policy (CAP):  Conference authorization
159	      policy consists of an unordered set of rules, which control the
160	      permissions and privileges that are given to conference
161	      participants.

163	   Conference Policy Server (CPS):  Conference Policy Server.  See [13]

165	   Conference participant:  A conference participant is a user who has
166	      an on-going session (e.g.  SIP dialog) with the conference focus.

168	   Key participant:  A key participant is a user whose participantion in
169	      the conference is required for the conference to take place as
170	      s/he can be the note taker, the person with whom a debate is
171	      taking place, etc.  A key participant may be required to be in a
172	      conference before the conference starts and may be required for
173	      the conference not to end.

175	   Floor control:  Floor control is a mechanism that enables
176	      applications or users to gain safe and mutually exclusive or
177	      non-exclusive access to the shared object or resource in a
178	      conference.

180	   Dial-Out List (DL):  The Dial-out list (DL) is a list of users who
181	      the focus needs to invite to the conference.

183	   Privileged user:  A privileged user is a user that has the right to
184	      manipulate parts or all of the conference policy XML document.

186	   Conference Policy URI:  The URI of conference policy.  It identifies
187	      the XML document.  The URI construction is specified in [10].

189	   Refer List (RL):  The Refer list (RL) is a list of users who the
190	      focus needs to refer to the conference.

192	   Sidebar:  A sub-conference of a main conference.

194	4.  Structure of a Conference Policy document

196	   The conference policy document is an XML [6] document that MUST be
197	   well-formed and MUST be valid according to schemas, including
198	   extension schemas, available to the validater and applicable to the
199	   XML document.  The Conference policy documents MUST be based on XML
200	   1.0 and MUST be encoded using UTF-8.  This specification makes use of
201	   XML namespaces for identifying conference policy documents and
202	   document fragments.  The namespace URI for elements defined by this
203	   specification is a URN [3], using the namespace identifier 'ietf'
204	   defined by [4] and extended by [15].  This URN is:

206	      urn:ietf:params:xml:ns:conference-policy

208	4.1  MIME Type for CPCP XML Document

210	   The MIME type for the CPCP XML document is
211	   "application/conference-policy+xml".

213	4.2  Conference Root

215	   A conference policy document begins with the root element tag
216	   <conference>.  Other elements from different namespaces MAY be
217	   present for the purposes of extensibility.  Elements or attributes
218	   from unknown namespaces MUST be ignored.  The conference policy is
219	   build up using the following:

221	   o  The <settings> element: This element is mandatory and contains
222	      various conference settings.  It contains the conference URI(s),
223	      the maximum number of participants, the conference security level,
224	      and sidebar settings.  It can occur only once in the document.

226	   o  The <info> element: This element is optional and includes
227	      information describing the conference, that can be used, for
228	      example, search purposes.  This information can also be used in
229	      the session description when the focus is sending invitations.  It
230	      can occur only once in the document.

232	   o  The <time> element: This optional element defines conference time
233	      information, namely elements defining start and stop times for a
234	      media mixing.

236	   o  The <dialout-list> element: This optional element is for the
237	      dial-out list.  It contains URIs for users that the focus will
238	      invite to the conference.

240	   o  The <refer-list> element: This optional element is for the refer
241	      list.  It contains URIs for users that the focus will refer to the
242	      conference.

244	   o  The <ms> element: This optional element contains the media streams
245	      to be used in the conference.

247	   o  The <ruleset> element: This optional element is the conference
248	      authorisation rules.  It contains rules for users who can dial
249	      into the conference, users who are blocked from dialling in,
250	      amongst others.

252	   The elements are described in more detail in the forthcoming
253	   sections.

255	   A user may create a new conference at the CPS by placing a new
256	   conference policy document.  Depending on server policy and user
257	   privileges, the CPS may accept the creation, or it may reject it.

259	   A conference can be deleted permanently by removing the conference
260	   policy from the CPS, which consequently frees the resources.  When
261	   the user deletes a conference, the CPS MUST also delete all its
262	   sub-conferences ("sidebars") at a server.  Conference sidebars have
263	   unique URIs at the server.  Sidebars are created in [18].

265	4.3  XML Document Description

267	4.3.1  Conference Settings

269	   The <settings> element contains 2 sub-elements; the <conference-uri>
270	   element and the <max-participant-count> element.

272	   <conference-uri> is a mandatory element.  It can occur more than once
273	   to accommodate multiple signaling protocols.  Once a conference URI
274	   is set, it MUST NOT be changed or removed for the duration of the
275	   conference.  Only one URI per protocol MUST be set.  URIs can be
276	   added at any time.

278	   <max-participant-count> is an optional element.  It carries the
279	   maximum number of participants allowed in the conference.  When the
280	   maximum number of participants threshold is reached, no new users are
281	   not allowed to join until the number of participants decreases again.
282	   If using SIP, the server can reject a request to join (INVITE) with
283	   a "480 Temporarily Unavailable" response.  Alternatively, the sever
284	   may implement a waiting queue.

286	   <security-level> is an optional element.  It describes the security
287	   level that the creator of the conference wishes to have for the
288	   conference being created, including signalling and media.  There are
289	   4 security levels defined: none, low, medium, and high with medium
290	   being the default value if this element is absent.  Those levels are
291	   loosly defined here.  The interpretation of those levels and the
292	   security protocols applied is left as a local policy of the focus.  A
293	   focus may interpret those levels as follows:

295	   none:  No security is required for the signalling nor the media

297	   low:  Signalling and media integrity is required

299	   medium:  Signalling and media confidentiality is required

301	   high:  Signalling and media integrity and confidentiality are
302	      required

304	   <allow-sidebars> is an optional element with a boolean value
305	   indicating if sidebars are allowed in this conference or not.  The
306	   default value, if omitted, is "true" indicating that sidebars are
307	   allowed.

309	   <sidebar> is an element identifying a side bar.  Multiple <sidebar>
310	   elements can occur indicating multiple sidebars.  No <sidebar>
311	   elements appearing in a conference policy indicates that there are no
312	   sidebars currently for this conference.  A <sidebar> element contains
313	   a mandatory 'id' attribute that uniquely identifies the sidebar.  It
314	   also contains an <uri> element that hold the sidebar URI.  It can
315	   occur more than once to accommodate multiple signaling protocols.
316	   Once a sidebar URI is set, it MUST NOT be changed or removed for the
317	   duration of the conference.  Only one URI per protocol MUST be set.
318	   URIs can be added at any time.

320	   A sidebar MAY have its own policy.  This policy is created exactly in
321	   the same manner as any other conference.  The <policy> element in the
322	   <sidebar> element points to such policy.  If the <policy> element is
323	   omitted, the sidebar inherits the policy of the conference it is a
324	   sidebar of.

326	   A conference is identified by one or more conference URIs, one for
327	   each call signaling protocol that is supported.  There must be at
328	   least one URI for a conference.  Conference URIs can be proposed by
329	   the creator of the conference policy, as it may be useful to have
330	   human-friendly name in some cases, or can be assigned by the CPS.  If
331	   the creator has proposed a conference URI, the server needs to decide
332	   whether to accept the name proposed by the client or not.  It does
333	   this determination by examining if the conference URI already exists
334	   or not.  If it exists, the CPS rejects the request to create the
335	   conference with that conference URI.  Similarly, the CPS rejects the
336	   request to create a conference with a conference URI for a signalling
337	   protocol it does not support.

339	   A Conference URI can be SIP, SIPS, TEL, or any supported URI scheme.
340	   The CPS MAY assign multiple conference URIs to a conference, one for
341	   each call signaling protocol that it supports.

343	   Sidebar URIs are subject to the same behaviour.

345	4.3.2  Conference Information

347	   The <info> element includes informative conference parameters which
348	   may be helpful describing the purpose of a conference, e.g.  for
349	   search purposes or for providing host contact information.  The
350	   <info> element has a special attribute 'xml:lang' to specify the
351	   language used in the contents of this element as defined Section 2.12
352	   of [6].

354	   Each conference has an optional <subject> element, which describes
355	   the current topic in a conference.  The optional <display-name>
356	   element is the display name of the conference, which usually does not
357	   change over time.

359	   <free-text> and <keywords> are optional elements.  They provide
360	   additional textual information about the conference.  This
361	   information can be made available to potential conference
362	   participants by means outside the scope of this document.  Examples
363	   of usage could be searching for a conference based on some keywords.

365	   The optional <web-page> element points to a URI where additional
366	   information about the conference can be found.

368	   The optional <host-info> element contains the <uri>, <e-mail> and
369	   <web-page> elements.  They give additional information about the user
370	   hosting the conference.  This information can, for example, be
371	   included into the SDP fields of the SIP INVITE requests sent by the
372	   focus.  The <uri> element is optional and can occur more than once.

374	4.3.3  Conference Time

376	   The information related to conference time and lifetime is contained
377	   in the <time> element.  The conference may occur for a limited period
378	   of time (i.e.  bounded), or the conference may be unbounded (i.e.  it
379	   does not have a specified end time).  Bounded conferences may occur
380	   multiple times(e.g.  on weekly basis).

382	   The <time> element contains one or more <occurrence> elements each
383	   defining the time information of a single conference occurrence.
384	   Multiple <occurrence> elements MAY be used if a conference is active
385	   at multiple times; each additional <occurrence> element contains time
386	   information for a specific occurrence.

388	   For each occurrence, the <mixing-start-time> element specifies when
389	   conference media mixing starts.  the <mixing-stop-time> element
390	   specifies the time a conference media mixing stops.  If the
391	   <mixing-start-time> element is not present, it indicates that the
392	   conference media mixing starts immediately.  If the
393	   <mixing-stop-time> element is not present, it indicates that the
394	   conference occurrence is not bounded, i.e.  permanent unitl the
395	   conference policy is removed from the server.

397	   <mixing-start-time> and <mixing-stop-time> elements both have the
398	   mandatory 'require-participant' attribute.  This attribute has one of
399	   3 values: "none", "key-participant", and "participant".  For mixing
400	   start time, this attribute allows a privileged user to define when
401	   media mixing starts based on the latter of the mixing start time, and
402	   the time the first participant or key participant arrives.  If the
403	   value is set to "none", mixing starts according to the mixing start
404	   time.  For mixing stop time, this attribute allows a privileged user
405	   to define when media mixing stops based on the earlier of the mixing
406	   stop time, and the time the last participant or key participant
407	   leaves.  If the value is set to "none", mixing stops according to the
408	   mixing stop time.  If the conference policy was modified so that that
409	   last key participant is now a normal conference participant, and the
410	   conference requires a kep participant to continue; that conference
411	   MUST terminate.

413	   The following is an example that states a conference mixing will not
414	   start before a key participant joins but the mixing will stop as soon
415	   as the last participant (no neccesarily the last key participant)
416	   leaves.

418	   	<time>
419	   	  <occurrence>
420	   	    <mixing-start-time required-participant="key-participant">
421	   	    		2004-12-17T09:30:00-05:00</mixing-start-time>
422	   	<mixing-stop-time required-participant="participant">
423	   			2004-12-17T12:30:00-05:00</mixing-stop-time>
424	   	</occurrence>
425	   	</time>

427	   Users can be allowed to join a conference before the media mixing
428	   time starts and after a certain time.  A conference privileged user
429	   can indicate the time when users can join by populating the
430	   <can-join-after> element.  Similarly, a conference privileged user
431	   can define the time after which new users are not allowed to join the
432	   conference anymore.  This is done by populating the
433	   <must-join-before> element.

435	   It is possible to define the time when users or resources on the
436	   dial-out list and on the refer-list are requested to join the
437	   conference by using the <request-users> element.  It is also possible
438	   to define that the users and resources on the dial-out list and the
439	   refer-list are requested to join the conference only after the first
440	   a participant or key participant has joined.  This is achieved with
441	   the 'require-participant' attribute.  A value of "none" indicates
442	   that the focus sends the requests immediately after the specified
443	   time has lapsed.

445	   The absence of this conference time information indicates that a
446	   conference starts immediately and terminates when the conference
447	   policy is removed.

449	   A running conference instance can be extended or stopped by modifying
450	   the conference time information.  Note that those conference times do
451	   not guarantee resources for the conference to be available.

453	   If a conference is in progress when deleted or stopped, the focus
454	   issues signalling requests to terminate all conference related
455	   sessions it has with participants.  In SIP, the focus issues BYE
456	   requests.

458	4.3.4  Conference Dial-Out List

460	   The dial-out list (DL) is a list of user URIs that the focus uses to
461	   learn who to invite to join a conference.  This list can be created
462	   at conference policy creation time or updated during the conference
463	   lifetime so it can be used for mid-conference invites (and
464	   mass-invites) as well.

466	   Asking the focus to invite (add) a user into the conference is
467	   achieved by adding that user's URI to the Dial-Out List (DL).  The
468	   CPS then triggers the focus to send the conference invitation, eg:
469	   SIP INVITE as needed.  Similarly, a user can be removed from the
470	   Dial-out list by removing the URI from the dial-out list.

472	   The <dialout-list> element is optional and includes zero or more
473	   <target> elements and zero or more <external> elements.  Those two
474	   elements includes the mandatory 'uri' attribute.  The use of the
475	   <external> element is described in more detail in Section 5.2

477	4.3.5  Conference Refer List

479	   The Refer List (RL) contains a list of resources that the focus needs
480	   to refer to the conference.  In SIP, this is achieved by the focus
481	   sending a REFER request to those potential participants.  In a
482	   different paradiam, this could also mean that the focus sends an SMS
483	   or an email to the referred user.  This list can be updated during
484	   the conference lifetime so it can be used for mid-conference refers
485	   as well.

487	   The Refer List differs from the Dial-out list in that the dial-out
488	   list contains a list of resources that the focus will initiate a
489	   session with.  The resources on the refer list, on the other had, are
490	   expected to initiate the session establishment towards the focus
491	   themselves.  It is also envisioned that difference users will have
492	   different access rights to those lists and therefore a separation
493	   between the two is needed.

495	   The <refer-list> element is optional and identical to the
496	   <dialout-list> element in Section 4.3.4.

498	4.3.6  Conference Media Streams

500	   Media policy is an integral part of the conference policy.  It
501	   defines e.g.  what kind of media topologies exist in the conference.
502	   Media policy is documented in [17].This document does not define
503	   media policy, but instead enables the user to specify the media
504	   streams a conference has.  This is used by the focus to know what
505	   media streams to invite users with and what media streams it should
506	   accept from dialling in users.  Media can be added to or removed from
507	   a conference by a privileged user before or during a conference
508	   occurance.  This might result in the focus modifying the session it
509	   has with each participant.  In SIP, this means re-issuing and INVITE
510	   request modifying the session description (SDP).

512	   The definition starts with the optional <media-streams> element.
513	   This element lists the media streams allowed for this conference.  It
514	   can contain at most one of each media type using the <video>,
515	   <audio>, <message> and <text> elements.

517	4.3.7  Conference Authorization Rules

519	   One of the key components of conference policy is the set of
520	   authorization rules that specify who is allowed to join a conference,
521	   see floors and request/grant them, subscribe to
522	   conference-information notifications and so on.  The unordered list
523	   of authorization rules together define the conference authorization
524	   policy

526	   The conference authorization rules are enclosed in the <ruleset>
527	   element and are formatted according to the XML schema defined in the
528	   common policy framework [1].  In the <ruleset> element, there can be
529	   multiple rules, each rule is represented by the <rule> element, each
530	   of which consist of three parts: conditions, actions and
531	   transformations.  Conditions determine whether a particular rule
532	   applies to a request.  Each action or transformation in the applied
533	   rule is a positive grant of permission to the conference participant.
534	   The details of each specific element and attribute is described in
535	   [1].

537	   Asking the focus to allow certain users to join the conference is
538	   achieved by modifying an existing authorization rule or creating a
539	   new one.  The CPS then informs the focus of such change.

541	   If the conference is long-lasting, it is possible that new rules are
542	   added all the time but old rules are almost never removed (some of
543	   them are overwritten, though).  This leads easily to the situation
544	   that the conference policy contains many unnecessary rules which are
545	   not really needed anymore.  Therefore, there is a need to delete
546	   rules.  This can be achieved by removing that portion of the policy.

548	   Conflicting rules may exist (for example, both allowed and blocked
549	   action is defined for same target).  The common policy directives [1]
550	   dictate the behaviour in such situations.

552	   This section outlines the new conditions, actions and transformations
553	   for conference authorization policy.

555	4.3.7.1  Conditions
556	4.3.7.1.1  Validity

558	   The <validity> element, as defined in  the common policy framework
559	   [1], expresses the rule validity period by two attributes, a starting
560	   and a ending time.  Times are expressed in XML dateTime format.
561	   Expressing the lifetime of a rule implements a garbage collection
562	   mechanism.  A rule maker might not have always access to the
563	   conference policy server to remove some rules which grant
564	   permissions.  Hence this mechanisms allows to remove or invalidate
565	   granted permissions automatically without further interaction between
566	   the rule maker and the conference policy server.

568	   To give a real life example, there are often meetings where
569	   management are allowed to join the first half of the conference and
570	   engineers are only allowed to join the conference during the second
571	   half of that meeting to report technical findings, etc.  Two rules
572	   can be set in this scenario, the first rules allows the managers to
573	   join the conference without specifying a validity contraint.  The
574	   second rule allows engineers to join an hour into the conference.
575	   The following example demostrates this.  The meeting starts at 9:30
576	   and ends at 12:30.  The manager can join at any time while the
577	   engineer cannot only join before 10:30 (Note that the example is
578	   simplified for clarity).

580	     <rule id="1">
581	       <conditions>
582	         <identity>
583	           <id>manager@example.com</id>
584	         </identity>
585	       </conditions>
586	       <actions>
587	         <join-handling>allow</join-handling>
588	       </actions>
589	       <transformations/>
590	     </rule>
591	     <rule id="2">
592	       <conditions>
593	         <validity>
594	           <from>2004-12-17T10:30:00-05:00</from>
595	           <to>2004-12-17T12:30:00-05:00</to>
596	         </validity>
597	         <identity>
598	           <id>engineeer@example.com</id>
599	         </identity>
600	       </conditions>
601	       <actions>
602	         <join-handling>allow</join-handling>
603	       </actions>
604	       <transformations/>
605	     </rule>
606	     ...
607	     <time>
608	       <occurrence>
609	         <mixing-start-time required-participant="participant">
610	           2004-12-17T09:30:00-05:00</mixing-start-time>
611	         <mixing-stop-time required-participant="none">
612	           2004-12-17T12:30:00-05:00</mixing-stop-time>
613	       </occurrence>
614	     </time>

616	4.3.7.1.2  Identity

618	   The <identity> element is already defined in the common policy
619	   framework [1].  The presence of the <identity> element is a condition
620	   requires any identity within it to be authenticated before a rule is
621	   applied to it.  This includes the <id> element (Section 4.3.7.1.2.1),
622	   the <any> element (Section 4.3.7.1.4.1), the <external-list> element
623	   (Section 4.3.7.1.4.2), their exceptions, and any future extension
624	   that carries an identity.  The absence of the <identity> element with
625	   in a condition indicated that the rule applies to all unauthenticated
626	   identities.  That is participants that have provided no authenticated
627	   identity to the conference focus.

629	4.3.7.1.2.1  Interpreting the <id> Element

631	   As earlier indicated, the <identity> element is already defined in
632	   the common policy framework [1].  However, the rules for interpreting
633	   the identities in <id> elements are left for each application to
634	   define separately.  This document, however, does not define the rules
635	   for interpreting identities in <id> elements in conferencing
636	   applications since those interpretation rules are signalling protocol
637	   specific.

639	      OPEN ISSUE: Do we need to state more than this? How are identities
640	      derived from users that join using POTS, H.323, etc.?

642	4.3.7.1.3  Sphere

644	   The <sphere> element has no meaning in the context of conference
645	   policy and MUST be ignored if present.

647	4.3.7.1.4  Conference Policy Identity

649	4.3.7.1.4.1  Matching Any Identity

651	   The <any> element is used to match any participant.  This allows a
652	   conference to be open to any authenticated user.  Just as for the
653	   <domain> element in <identity> element, The <any> element contains a
654	   list of <except> elements and allows to implement a simple blacklist
655	   mechanism.  The <except> element contains an identity.  It differs
656	   from the <domain> element in that the domain part is needed in the
657	   identity since it has no domain to refer to.

659	4.3.7.1.4.2  Matching Identities in External Lists

661	   The <external-list> element can be used to match those participants
662	   that are part of a resource list that is created externally.  The
663	   <external-list> element contains a list of <except> elements and
664	   allows to implement a simple blacklist mechanism.  The <except>
665	   element contains an identity.Section 5.2 talks about the use of this
666	   condition in more detail.

668	4.3.7.1.5  Matching Pseudonymous Identities

670	   The <pseudonymous> element is used to match participants that have
671	   provided an authenticated identity to the conference focus, but have
672	   requested pseudonymity in the conference itself.  A user requests
673	   pseudonymity by authenticating himself to the conference focus and
674	   providing an pseudonym in the signalling protocol (for example, using
675	   the From-header of a SIP reqeust).  A rule allowing pseudonymous
676	   users to join looks like the following:

678	   	<rule id="4">
679	     		<conditions>
680	     			<pseudonymous>
681	   	</conditions>
682	     		<actions>
683	     			<join-handling>allow</join-handling>
684	     		</actions>
685	     		<transformations/>
686	     	</rule>

688	   The <pseudonymous> element can be combined with the <identity>
689	   element to provide the focus with a rule on what to do when a
690	   specific identity is authenticated and that identity is requesting
691	   pseudonymity through the signalling protocol.  An example of such a
692	   rule follows:

694	   	<rule id="4">
695	   	 <conditions>
696	   	   <identity>
697	   	     <id>alice@example.com</id>
698	   	   </identity>
699	   	   <pseudonymous>
700	   	 </conditions>
701	   	 <actions>
702	   	   <join-handling>allow</join-handling>
703	   	 </actions>
704	   	 <transformations/>
705	   	</rule>

707	4.3.7.1.6  Matching Referred Identities

709	   The <has-been-referred> element can be used to match those
710	   participants that the focus has referred to the conference.

712	4.3.7.1.7  Matching Invited Identities

714	   The <has-been-invited> element can be used to match those
715	   participants that the focus has invited into the conference.

717	4.3.7.1.8  Matching Identities of Former Conference Participants

719	   The <has-been-in-conference> element can be used to match those
720	   participants that have joined the conference in the past.

722	4.3.7.1.9  Matching Identities Currently in the Conference

724	   The <is-in-conference> element can be used to match those
725	   participants that are currently participating in the conference.

727	4.3.7.1.10  Matching Key Participant Identities

729	   The <key-participant> element can be used to match those participants
730	   that are key participants of a conference.

732	4.3.7.1.11  Matching Identities on the Dial-out List

734	   The <is-on-dialout-list> element can be used to match those
735	   participants that are on the dial-out list.

737	4.3.7.1.12  Matching Identities on the Refer List

739	   The <is-on-refer-list> element can be used to match those
740	   participants that are on the refer list.

742	4.3.7.1.13  Floor ID

744	   The <floor-id> element can be used to assign users as floor
745	   moderators.  It MUST be used in conjunction with the <id> element
746	   that identifies the floor moderator.  The <floor-id> element carries
747	   the floor ID of the floor that the user is a moderator of.  The
748	   transformation <is-floor-moderator> is used to assert that the user
749	   identified using the <id> condition is the floor moderator of the
750	   floor identified in the <floor-id> condition.

752	   The <floor-id> element is also used with the <floor-request-handling>
753	   element (Section 4.3.7.2.7) to set rules on who is allowed to request
754	   a floor.

756	4.3.7.1.14  Matching Participant Passcodes

758	   The <participant-passcode> element can be used to match those
759	   participants that are have knowledge on a passcode for the
760	   conference.  For example:

762	   	<rule id="3">
763	   		<conditions>
764	   			<participant-passcode/>
765	   		</conditions>
766	   		<actions>
767	   			<join-handling>allow</join-handling>
768	   		</actions>
769	   		<transformations/>
770	   	</rule>

772	   So the condition is the participant passcode.  If any user knows the
773	   passcode, the user is allowed to join.

775	   A focus need not care if a user using a passcode to join is calling
776	   from a PSTN or an IP phone.  For example: Using a SIP phone, a SIP
777	   INVITE request arrives directly at the focus.  The focus examines the
778	   identity and discovers that there are no rules allowing this identity
779	   to join.  The focus also determines that there are no rules
780	   explicitly prohibiting this identity from joining.  The focus in this
781	   case decides to challenge the identity for a passcode, if there is a
782	   rule that allows users with a passcode knowledge to join.  If no such
783	   rule exists, the focus would not challenge for a passcode.

785	   For PSTN users, the system can be set up for an IVR system to prompt
786	   the user for a passcode before forwarding the request to the focus.
787	   The focus does not need to care if there is an IVR system or not.  It
788	   can apply the same procedure as above.  It checks if there are any
789	   the rules allowing or denying the identity access.  In this case, the
790	   identity is the GW.  If no rules exist for that identity but an
791	   general passcode rule does, then the focus would challenge the GW/IVR
792	   for the passcode.

794	   A focus can challenge for the passcode using, for example, a HTTP
795	   Digest challenge.  The username, passcode and realm need to be
796	   assigned and distributed is a manner that is outside the scope of
797	   this document.  Mutliple passcodes can be assigned to multiple users.

799	4.3.7.1.15  Matching Passcodes

801	   In some cases, key participants are assigned a different passcode
802	   than normal participants.  The <key-participant-passcode> element can
803	   be used to match those key participants that are have knowledge on a
804	   key participant passcode for the conference.  For example:

806	   	<rule id="3">
807	   		<conditions>
808	   			<key-participant-passcode/>
809	   		</conditions>
810	   		<actions>
811	   			<join-handling>allow</join-handling>
812	   		</actions>
813	   		<transformations>
814	   			<is-key-participant/>
815	   		</transformations>
816	   	</rule>

818	   So the condition is the key participant passcode.  If any user knows
819	   that passcode, that user is allowed to join and is made a key
820	   participant.  Again, a focus need not care if a user using a passcode
821	   to join is calling from a PSTN or an IP phone.  Section 4.3.7.1.14
822	   has more details.

824	   It is important that the focus has a unique identity for each user
825	   joining from a PSTN phone via a gateway.  It is not enough that one
826	   identity to be assigned to all users joining from the same gateway
827	   since key participants have more control over conference duration, if
828	   the conference mixing times are key participant dependant.  See
829	   Section 4.3.3 for details.  It might be required that a gateway maps
830	   the telephone number of the PSTN phone into the IP signalling
831	   protocol header that usually carries the asserted identity or a user.

833	4.3.7.2  Actions

835	4.3.7.2.1  Conference State Events

837	   The <allow-conference-state> element represents a boolean action.  If
838	   set to TRUE, the focus is instructed to allow the subscription to
839	   conference state events, such as the SIP Event Package for Conference
840	   State [14].  If set to FALSE, the subscription to conference state
841	   events would be rejected.

843	   If this element is undefined it has a value of TRUE, causing the
844	   subscription to conference state events to be accepted.

846	4.3.7.2.2  Floor Control Events

848	   The <allow-floor-events> element represents a boolean action.  If set
849	   to TRUE, the focus is instructed to accept the subscription to floor
850	   control events.  If set to FALSE, the focus is instructed to reject
851	   the subscription.

853	   If this element is undefined, it has a value of FALSE, causing the
854	   subscription to floor control events to be rejected.

856	4.3.7.2.3  Conference Join Handling

858	   The <join-handling> element defines the actions used by the
859	   conference focus to control conference participation.  This element
860	   defines the action that the focus is to take when processing a
861	   particular request to join a conference.  This element is an
862	   enumerated integer type, with defined values of:

864	   block:  This action instructs the focus to deny access to the
865	      conference.  This action has a value of zero and it is the lowest
866	      value of the <join-handling> element.  This action is the default
867	      action taken in the absence of any other actions.

869	   confirm:  This action instructs the focus to place the participant on
870	      a pending list (e.g., by parking the call on a music-on-hold
871	      server), awaiting moderator input for further actions.  This
872	      action has a value of one.

874	   allow:  This action instructs the focus to accept the conference join
875	      request and grant access to the conference within the instructions
876	      specified in the transformations of this rule.  This action has a
877	      value of two.

879	   Note that placing a value of block for this element doesn't guarantee
880	   that a participant is blocked from joining the conference.  Any other
881	   rule that might evaluate to true for this participant that carried an
882	   action whose value was higher than block would automatically grant
883	   confirm/allow permission to that participant.

885	4.3.7.2.4  Dynamically Referring Users

887	   The <allow-refer-users-dynamically> element represents a boolean
888	   action.  If set to TRUE, the identity is allowed  to instruct the
889	   focus to refer a user to the conference without modifying the
890	   refer-list (in SIP terms, the identity is allowed to send a REFER
891	   request to the focus which results in the focus sending a REFER
892	   request to the user the referrer wishes to join the conference).  If
893	   set to FALSE, the refer request is rejected.

895	   If this element is undefined it has a value of FALSE, causing the
896	   refer to be rejected.

898	4.3.7.2.5  Dynamically Inviting Users

900	   The <allow-invite-users-dynamically> element represents a boolean
901	   action.  If set to TRUE, the identity is allowed  to instruct the
902	   focus to invite a user to the conference without modifying the
903	   dial-out list (in SIP terms, the identity is allowed to send a REFER
904	   request to the focus which results in the focus sending an INVITE
905	   request to the user the referrer wishes to join the conference).  If
906	   set to FALSE, the refer request is rejected.

908	   If this element is undefined it has a value of FALSE, causing the
909	   refer to be rejected.

911	4.3.7.2.6  Dynamically Removing Users

913	   The <allow-remove-users-dynamically> element represents a boolean
914	   action.  If set to TRUE, the identity is allowed  to instruct the
915	   focus to remove a user from the conference without modifying the
916	   ruleset (in SIP terms, the identity is allowed to send a REFER
917	   request to the focus which results in the focus sending an BYE
918	   request to the user the referrer wishes to leave the conference).  If
919	   set to FALSE, the refer request is rejected.

921	   If this element is undefined it has a value of FALSE, causing the
922	   refer to be rejected.

924	4.3.7.2.7  Floor Request Handling

926	   The <floor-request-handling> element defines the actions used by the
927	   conference focus to control floor requests.  This element defines the
928	   action that the focus is to take when processing a particular request
929	   to a floor within a conference.  This element is an enumerated
930	   integer type, with defined values of:

932	   block:  This action instructs the focus to deny the floor request.
933	      This action has a value of zero and it is the lowest value of the
934	      <floor-request-handling> element.  This action is the default
935	      action taken in the absence of any other actions.

937	   confirm:  This action instructs the focus to allow the request.  The
938	      focus then uses the defined floor algorithm to further allow of
939	      deny the floor.  The algorithms used are outside the scope of this
940	      document.

942	   Note that placing a value of block for this element doesn't guarantee
943	   that a participant is blocked from joining the conference.  Any other
944	   rule that might evaluate to true for this participant that carried an
945	   action whose value was higher than block would automatically grant
946	   confirm/allow permission to that participant.

948	4.3.7.3  Transformations

950	4.3.7.3.1  Key Participant

952	   When the <is-key-participant> element is set to TRUE, the joining
953	   participant is denoted as a key participant.  If set to FALSE, the
954	   participant is not denoted as a key participant.

956	   If this element is undefined, it has a value of FALSE, causing no key
957	   participant status to be given to the participant.

959	4.3.7.3.2  Floor Moderator

961	   When the <is-floor-moderator> element is set to TRUE, the joining
962	   conference participant is denoted as floor moderator, meaning that
963	   they are privileged to control the floor in the conference.  If set
964	   to FALSE, floor moderator privileges are not given to the conference
965	   participant.

967	   If this element is undefined, it has a value of FALSE, causing no
968	   floor moderator privileges to being granted.

970	4.3.7.3.3  Conference Information

972	   The <show-conference-info> element is of type boolean transformation.
973	   If set to TRUE, conference information is shown to the conference
974	   participant.  If set to FALSE, conference information is not shown to
975	   the participant.

977	   The <show-conference-info> element controls whether information in
978	   the <settings>, <time> and <info> elements may be made available
979	   publicly.  For example, an application at a conference server might
980	   list the ongoing conferences on web page, or it may allow searching
981	   for conferences based on the keywords listed in the <Conference-info>
982	   element.  Not setting this transformation to any users instructs the
983	   application not to reveal any such information to any user.  However,
984	   information in other elements, such as <dialout-list>, should not be
985	   seen by anyone else other than a privileged user, even with this
986	   transformation enabled for a user.

988	   If this element is undefined, it has a value of FALSE, causing no
989	   conference information to being shown.

991	4.3.7.3.4  Floor Holder

993	   The <show-floor-holder> element is of type boolean transformation.
994	   If set to TRUE, the conference participant is able to see who is
995	   currently holding the floor.  If set to FALSE, the participant is not
996	   able to see the floor holder.

998	   If this element is undefined, it has a value of FALSE, causing the
999	   floor holder not be shown to the participant.

1001	4.3.7.3.5  Floor Requests

1003	   The <show-floor-requests> element is of type boolean transformation.
1004	   If set to TRUE, the conference participant is able to see the floor
1005	   requests.  If set to FALSE, the conference participant is not able to
1006	   see floor requests.

1008	   If this element is undefined, it has a value of FALSE, causing the
1009	   floor requests to not being seen by the conference participant.

1011	4.3.7.3.6  Providing anonymity

1013	   A rule can be set that provides anonymity to a specific identity.  In
1014	   this case, the focus provides to the rest of the participants an
1015	   anonymous identity for that user, for example anonymous1.  This can
1016	   be achieved by using the <provide-anonymity> element.  It is a
1017	   boolean transformation.  If set to TRUE, the conference participants
1018	   will see an anonymous identity for the user whose identity is present
1019	   in the conditions.  An example of such rule follows:

1021	   	<rule id="4">
1022	   	  <conditions>
1023	   	    <identity>
1024	   	      <id>alice@example.com</id>
1025	   	    </identity>
1026	   	  </conditions>
1027	   	  <actions>
1028	   	    <join-handling>allow</join-handling>
1029	   	  </actions>
1030	   	  <transformations>
1031	   	    <provide-anonymity>
1032	   	  </transformation>
1033	   	</rule>

1035	   If this element is undefined, it has a value of FALSE, causing the
1036	   identity to be revealed.

1038	4.4  XML Schema Extensibility

1040	   The schema as be extended at multiple places:

1042	   o  The <conference> element to enable more conference policy
1043	      information to be added

1045	   o  The <settings> element to allow for future conference settings to
1046	      be defined

1048	   o  The <info> element to allow further conference and host
1049	      information to be conveyed

1051	   o  The <occurrence> element to allow further conference timing
1052	      information

1054	   o  The <target> element and the <external> element in <dialout-list>
1055	      and <refer-list> to allow  extensions on the behaviour of the
1056	      focus.  For example, how many times to retry inviting a user

1058	   o  The <media-streams> element to allow introduction of new media
1059	      streams

1061	   o  The <sidebar> element to allow introduction of new sidebar
1062	      information

1064	4.5  XML Schema

1066	   <?xml version="1.0" encoding="UTF-8"?>
1067	   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-policy" xmlns:cr="urn:ietf:params:xml:ns:common-policy" xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
1068	   	<!-- This import brings in the XML language attribute xml:lang-->
1069	   	<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
1070	   	<!-- This import brings in the common-policy-->
1071	   	<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
1072	   	<!-- The root Conference Element -->
1073	   	<xs:element name="conference">
1074	   		<xs:complexType>
1075	   			<xs:sequence>
1076	   				<xs:element name="settings" type="ConferenceSettings"/>
1077	   				<xs:element name="info" type="ConferenceInfo" minOccurs="0"/>
1078	   				<xs:element name="time" type="ConferenceTime" minOccurs="0"/>
1079	   				<xs:element name="dialout-list" type="UserList" minOccurs="0"/>
1080	   				<xs:element name="refer-list" type="UserList" minOccurs="0"/>
1081	   				<xs:element name="media-streams" type="ConferenceMediaStreams" minOccurs="0"/>
1082	   				<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1083	   				<xs:element ref="cr:ruleset"/>
1084	   		</xs:sequence>
1085	   		</xs:complexType>
1086	   	</xs:element>
1087	   	<!-- Conference Settings -->
1088	   	<xs:complexType name="ConferenceSettings">
1089	   		<xs:sequence>
1090	   			<xs:element name="conference-uri" type="xs:anyURI" maxOccurs="unbounded"/>
1091	   			<xs:element name="max-participant-count" type="xs:nonNegativeInteger" minOccurs="0"/>
1092	   			<xs:element name="security-level" type="SecurityLevel" default="medium" minOccurs="0"/>
1093	   			<xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/>
1094	   			<xs:element name="sidebar" type="Sidebar" minOccurs="0" maxOccurs="unbounded"/>
1095	   			<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1096	   		</xs:sequence>
1097	   	</xs:complexType>
1098	   	<!-- Conference Info -->
1099	   	<xs:complexType name="ConferenceInfo">
1100	   		<xs:sequence>
1101	   			<xs:element name="subject" type="xs:string" minOccurs="0"/>
1102	   			<xs:element name="display-name" type="xs:string" minOccurs="0"/>
1103	   			<xs:element name="free-text" type="xs:string" minOccurs="0"/>
1104	   			<xs:element name="keywords" minOccurs="0">
1105	   				<xs:simpleType>
1106	   					<xs:list itemType="xs:string"/>
1107	   				</xs:simpleType>
1108	   			</xs:element>
1109	   			<xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
1110	   			<xs:element name="host-info" minOccurs="0">
1111	   				<xs:complexType>
1112	   					<xs:sequence>
1113	   						<xs:element name="uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
1114	   						<xs:element name="e-mail" type="xs:anyURI" minOccurs="0"/>
1115	   						<xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
1116	   					</xs:sequence>
1117	   				</xs:complexType>
1118	   			</xs:element>
1119	   			<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1120	   		</xs:sequence>
1121	   		<xs:attribute ref="xml:lang"/>
1122	   	</xs:complexType>
1123	   	<!-- Conference time -->
1124	   	<xs:complexType name="ConferenceTime">
1125	   		<xs:sequence>
1126	   			<xs:element name="occurrence" minOccurs="0" maxOccurs="unbounded">
1127	   				<xs:complexType>
1128	   					<xs:sequence>
1129	   						<xs:element name="mixing-start-time" type="StartStopTime" minOccurs="0"/>
1130	   						<xs:element name="mixing-stop-time" type="StartStopTime" minOccurs="0"/>
1131	   						<xs:element name="can-join-after" type="xs:dateTime" minOccurs="0"/>
1132	   						<xs:element name="must-join-before" type="xs:dateTime" minOccurs="0"/>
1133	   						<xs:element name="request-users" type="StartStopTime" minOccurs="0"/>
1134	   						<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1135	   					</xs:sequence>
1136	   				</xs:complexType>
1137	   			</xs:element>
1138	   		</xs:sequence>
1139	   	</xs:complexType>
1140	   	<!-- User List -->
1141	   	<xs:complexType name="UserList">
1142	   		<xs:sequence>
1143	   			<xs:element name="target" type="Target" minOccurs="0" maxOccurs="unbounded"/>
1144	   			<xs:element name="external" type="Target" minOccurs="0" maxOccurs="unbounded"/>
1145	   		</xs:sequence>
1146	   	</xs:complexType>
1147	   	<!-- Conference Media Streams -->
1148	   	<xs:complexType name="ConferenceMediaStreams">
1149	   		<xs:sequence>
1150	   			<xs:element name="video" type="xs:string" minOccurs="0"/>
1151	   			<xs:element name="audio" type="xs:string" minOccurs="0"/>
1152	   			<xs:element name="message" type="xs:string" minOccurs="0"/>
1153	   			<xs:element name="text" type="xs:string" minOccurs="0"/>
1154	   			<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1155	   		</xs:sequence>
1156	   	</xs:complexType>
1157	   	<!-- Target  -->
1158	   	<xs:complexType name="Target">
1159	   		<xs:sequence>
1160	   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1161	   		</xs:sequence>
1162	   		<xs:attribute name="uri" type="xs:anyURI" use="required"/>
1163	   	</xs:complexType>
1164	   	<!-- Start/Stop time -->
1165	   	<xs:complexType name="StartStopTime">
1166	   		<xs:simpleContent>
1167	   			<xs:extension base="xs:dateTime">
1168	   				<xs:attribute name="required-participant" use="required">
1169	   					<xs:simpleType>
1170	   						<xs:restriction base="xs:string">
1171	   							<xs:enumeration value="key-participant"/>
1172	   							<xs:enumeration value="participant"/>
1173	   							<xs:enumeration value="none"/>
1174	   						</xs:restriction>
1175	   					</xs:simpleType>
1176	   				</xs:attribute>
1177	   			</xs:extension>
1178	   		</xs:simpleContent>
1179	   	</xs:complexType>
1180	   	<!-- Security Level -->
1181	   	<xs:simpleType name="SecurityLevel">
1182	   		<xs:restriction base="xs:string">
1183	   			<xs:enumeration value="none"/>
1184	   			<xs:enumeration value="low"/>
1185	   			<xs:enumeration value="medium"/>
1186	   			<xs:enumeration value="high"/>
1187	   		</xs:restriction>
1188	   	</xs:simpleType>
1189	   	<!-- Join Handling -->
1190	   	<xs:simpleType name="JoinHandling">
1191	   		<xs:restriction base="xs:string">
1192	   			<xs:enumeration value="block"/>
1193	   			<xs:enumeration value="allow"/>
1194	   			<xs:enumeration value="confirm"/>
1195	   		</xs:restriction>
1196	   	</xs:simpleType>
1197	   	<!-- Sidebar -->
1198	   	<xs:complexType name="Sidebar">
1199	   		<xs:sequence>
1200	   			<xs:element name="uri" type="xs:anyURI" maxOccurs="unbounded"/>
1201	   			<xs:element name="policy" type="xs:anyURI" minOccurs="0"/>
1202	   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1203	   		</xs:sequence>
1204	   		<xs:attribute name="id" type="xs:string" use="required"/>
1205	   	</xs:complexType>
1206	   	<!-- Conferenece Authorisation -->
1207	        <xs:element name="cp-identity" substitutionGroup="cr:condition">
1208	          <xs:complexType>
1209	            <xs:choice>
1210	              <xs:sequence>
1211	                <xs:element name="any"/>
1212	                <xs:sequence minOccurs="0">
1213	                  <xs:element name="except" type="xs:string"
1214	                    maxOccurs="unbounded"/>
1215	                </xs:sequence>
1216	              </xs:sequence>
1217	              <xs:sequence>
1218	                <xs:element name="external-list" type="xs:string"/>
1219	                <xs:sequence minOccurs="0">
1220	                  <xs:element name="except" type="xs:string"
1221	                    maxOccurs="unbounded"/>
1222	                </xs:sequence>
1223	              </xs:sequence>
1224	            </xs:choice>
1225	          </xs:complexType>
1226	        </xs:element>
1227	   	<xs:element name="pseudonymous" type="xs:string" substitutionGroup="cr:condition"/>
1228	   	<xs:element name="has-been-referred" type="xs:string" substitutionGroup="cr:condition"/>
1229	   	<xs:element name="has-been-invited" type="xs:string" substitutionGroup="cr:condition"/>
1230	   	<xs:element name="has-been-in-conference" type="xs:string" substitutionGroup="cr:condition"/>
1231	   	<xs:element name="is-in-conference" type="xs:string" substitutionGroup="cr:condition"/>
1232	   	<xs:element name="key-participant" type="xs:string" substitutionGroup="cr:condition"/>
1233	   	<xs:element name="is-on-dialout-list" type="xs:string" substitutionGroup="cr:condition"/>
1234	   	<xs:element name="is-on-refer-list" type="xs:string" substitutionGroup="cr:condition"/>
1235	   	<xs:element name="floor-id" type="xs:anyURI" substitutionGroup="cr:condition"/>
1236	   	<xs:element name="participant-passcode" substitutionGroup="cr:condition"/>
1237	   	<xs:element name="key-participant-passcode" substitutionGroup="cr:condition"/>
1238	   	<xs:element name="allow-conference-state" type="xs:boolean" substitutionGroup="cr:action"/>
1239	   	<xs:element name="allow-floor-events" type="xs:boolean" substitutionGroup="cr:action"/>
1240	   	<xs:element name="join-handling" type="JoinHandling" substitutionGroup="cr:action"/>
1241	   	<xs:element name="allow-refer-users-dynamically" type="xs:boolean" substitutionGroup="cr:action"/>
1242	   	<xs:element name="allow-invite-users-dynamically" type="xs:boolean" substitutionGroup="cr:action"/>
1243	   	<xs:element name="allow-remove-users-dynamically" type="xs:boolean" substitutionGroup="cr:action"/>
1244	   	<xs:element name="floor-request-handling" type="xs:boolean" substitutionGroup="cr:action"/>
1245	   	<xs:element name="is-key-participant" type="xs:boolean" substitutionGroup="cr:transformation"/>
1246	   	<xs:element name="is-floor-moderator" type="xs:boolean" substitutionGroup="cr:transformation"/>
1247	   	<xs:element name="show-conference-info" type="xs:boolean" substitutionGroup="cr:transformation"/>
1248	   	<xs:element name="show-floor-holder" type="xs:boolean" substitutionGroup="cr:transformation"/>
1249	   	<xs:element name="show-floor-requests" type="xs:boolean" substitutionGroup="cr:transformation"/>
1250	   	<xs:element name="provide-anonymity" type="xs:boolean" substitutionGroup="cr:transformation"/>
1251	   	</xs:schema>

1253	5.  Conference Policy Manipulation and Conference Entity Behaviour

1255	5.1  Overview of Operation

1257	   This document assumes that the user knows the location of conference
1258	   policy serve, the details of that discovery are beyond the scope of
1259	   this document.

1261	   CPCP allows clients to manipulate the conference policy at the
1262	   conference policy server (CPS).  CPS is able to inform the focus
1263	   about changes in conference policy, if necessary.  For example, if
1264	   new users are added to the dial-out list, then conference policy
1265	   server informs the focus which makes the invitations as requested.

1267	   Some assumptions about the conferencing architecture are made.
1268	   Clients always connect to the conference policy server (CPS) when
1269	   they perform manipulation operations.  It is assumed that the CPS
1270	   informs other conferencing entities, such as focus, the floor control
1271	   server and the mixer directly or via the focus.  For example, if user
1272	   A wants to expel user B from an ongoing conference, user A must first
1273	   manipulate the conference policy data.  The CPS then communicates
1274	   that change to the focus to perform the operation.

1276	   User privileges are defined in [16]

1278	5.2  Use of External Lists

1280	   External lists MAY be used in a conference policy.  They can be used
1281	   in the dial-out list, the refer-list and the authorization policy.
1282	   An external list is a list of resources created by means outside the
1283	   scope of this document.

1285	   A privileged user of the conference policy uses an external list by
1286	   placing its URI in an conference policy element that is dedicated to
1287	   carrying external list URIs.  The external list URI is the URI used
1288	   to manipulate the list and not the URI used to signal to the list.
1289	   There are three such elements documented in this memo: the
1290	   <external-list> element in the authorization rules (Section
1291	   4.3.7.1.4.2) and the <external> element in both, the dialout list
1292	   (Section 4.3.4) and the refer list (Section 4.3.5).  At the time the
1293	   focus needs to activate the policy surrounding the URI, the focus
1294	   fetches the URIs for the members of the external list using the list
1295	   URI.  For example, a conference creator creates a conference and
1296	   places the URI of an external list in the dial-out list.  At some
1297	   point, the focus needs to invite using on the dial-out list to join
1298	   the conference.  It is at that moment that the focus retrieves the
1299	   members of the external list.  It then sends INVITE (in SIP terms) to
1300	   the members of that external list.  This results in all participants
1301	   connected to one focus.

1303	   It can happen that the external list is not accessible at the time
1304	   the focus requires it.  In this case, the external list is ignored,
1305	   and in the case of an authorization rule, that rule fails.

1307	   There are also cases where the external list has been manipulated.
1308	   It is outside the scope of this document how the focus can learn of
1309	   such manipulation.  But if is does, it reacts in a similar manner as
1310	   it would have if the list was local and has been modified.

1312	   If an external list contains a reference to yet another list, that
1313	   referenced list is also fetched if the focus has not already done so.
1314	   This is to avoid list loops.

1316	5.3  Communication Between Conference Entities

1318	   The communication between different (logical) conferencing elements
1319	   is beyond the scope of this document.  It can be expected that in
1320	   most cases CPS includes also those logical functions.

1322	5.4  Manipulating Participant Lists

1324	   A user with sufficient privileges is allowed to perform user
1325	   management operations, such as adding a new user to the conference or
1326	   expelling a user from the conference.  These operations are performed
1327	   by modifying the conference policy at the conference policy server.
1328	   After authorising the user to do such manipulations, the conference
1329	   policy server communicates the change to the focus.  The focus reacts
1330	   by performing singlling operations such as sending SIP INVITE, BYE or
1331	   REFER.

1333	5.4.1  Expelling a Participant

1335	   Expelling a user is performed by a privileged user creating or
1336	   manipulating an existing authorization rule and setting that user's
1337	   <join-handling> action to "block>.  The focus reacts by terminating
1338	   the session with that participant, such as a sending SIP BYE request.

1340	   Care must be taken since if one rules allows a user to join and one
1341	   blocks a user from joining, the result in that the user is allowed to
1342	   join.  For example, Bob can join a conference since an authorization
1343	   rule has been defined to allow everyone at example.com:

1345	   	<rule id="1">
1346	   		<conditions>
1347	   			<identity>
1348	   				<domain>example.com</domain>
1349	   			</identity>
1350	   		</conditions>
1351	   		<actions>
1352	   			<join-handling>allow</join-handling>
1353	   		</actions>
1354	   		<transformations/>
1355	   	</rule>

1357	   Setting the following rule will not block Bob from joining nor will
1358	   it expel him since the above rule overrides it:

1360	   	<rule id="2">
1361	   		<conditions>
1362	   			<identity>
1363	   				<uri>bob@example.com</uri>
1364	   			</identity>
1365	   		</conditions>
1366	   		<actions>
1367	   			<join-handling>block</join-handling>
1368	   		</actions>
1369	   		<transformations/>
1370	   	</rule>

1372	   So, in order to expel Bob, the original rule has to be modified using
1373	   the <except> element:

1375	   	<rule id="1">
1376	   		<conditions>
1377	   			<identity>
1378	   				<domain>example.com</domain>
1379	   				<except>bob@domain.com</except>
1380	   			</identity>
1381	   		</conditions>
1382	   		<actions>
1383	   			<join-handling>allow</join-handling>
1384	   		</actions>
1385	   		<transformations/>
1386	   	</rule>

1388	5.5  Re-joining a Conference

1390	   Participants can drop out of a conference for many reasons including:
1391	   client crash, out of coverage, had to leave for a while.  It might be
1392	   of interest to enable that user to re-join the conference.  To allow
1393	   that, participants that have departed the conference gracefully can
1394	   only re-join if a privileged user has added an authorization rule
1395	   allowing them to join.  Participants that have departed the
1396	   conference ungracefully (eg: crash) require a special behaviour from
1397	   the focus .  The focus is aware when a user has not gracefully
1398	   departed a conference (for example; it did not receive a SIP BYE
1399	   request and media is no longer being received).  If this is the case,
1400	   the focus is required to re-issue the invitation or referral to that
1401	   user after a pre-configured unit of time.

1403	6.  Examples

1405	6.1  A Simple Conference Policy Document

1407	   The simplist of a conference policy document contains the conference
1408	   URI, a dial-out list, and the media.  An example looks like
1409	   this:

1411	   <?xml version="1.0" encoding="UTF-8"?>
1412	   <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1413	   	xmlns:cr="urn:ietf:params:xml:ns:common-policy">
1414	   	<settings>
1415	   		<conference-uri>sip:myconference@example.com</conference-uri>
1416	   	</settings>
1417	   	<dialout-list>
1418	   		<target uri="sip:bob@example.com"/>
1419	   		<target uri="sip:alice@example.com"/>
1420	   		<target uri="sip:john@example.com"/>
1421	   		<target uri="sip:robert@example.com"/>
1422	   	</dialout-list>
1423	   	<media-streams>
1424	   		<audio/>
1425	   	</media-streams>
1426	   	<cr:ruleset/>
1427	   </conference>

1429	6.2  A Complex Conference Policy Document

1431	   Alice creates a conference with the follows policy:

1433	   o  Conference URIs are suggested to be sip:myconference@example.com
1434	      and tel:+3581234567.

1436	   o  Maximum number of participants in the conference is 10.

1438	   o  The security level for the conference is medium.

1440	   o  The conference allows sidebars

1442	   o  Media mixing starts at the latter of 9:30 am and the first
1443	      participant arrives

1445	   o  Media mixing sends at 12:30 pm.  The conference does not need a
1446	      key participant to continue.

1448	   o  Users can join 5 minutes before media mixing starts and cannot
1449	      join half an hour before media mixing ends.

1451	   o  Users are requested to join a conference (invited and referred) 5
1452	      minutes before the conference starts and no participant nor
1453	      key-participant is needed for this action to take place.

1455	   o  Everyone at the domain example.com is allowed to join and can
1456	      subscribe to the conference state event package.

1458	   o  Alice is a key participant

1460	   o  Alice will be invited to join the conference while Sarah will be
1461	      referred to the conference.

1463	   o  Two media are made available in the conference:audio and video.

1465	   The resulting CPCP document looks like

1467	   <?xml version="1.0" encoding="UTF-8"?>
1468	   <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1469	   	xmlns:cr="urn:ietf:params:xml:ns:common-policy">
1470	   	<settings>
1471	   		<conference-uri>sip:myconference@example.com</conference-uri>
1472	   		<max-participant-count>10</max-participant-count>
1473	   		<allow-sidebars>true</allow-sidebars>
1474	   	</settings>
1475	   	<info xml:lang="en-us">
1476	   		<subject>What's happening tonight</subject>
1477	   		<display-name>Party Goer's</display-name>
1478	   		<free-text>John and Peter will join the conference soon</free-text>
1479	   		<keywords>party nightclub beer</keywords>
1480	   		<host-info>
1481	   			<uri>sip:Alice@example.com</uri>
1482	   			<uri>tel:+3581234567</uri>
1483	   			<e-mail>mailto:Alice@example.com</e-mail>
1484	   			<web-page>http://www.example.com/users/Alice</web-page>
1485	   		</host-info>
1486	   	</info>
1487	   	<time>
1488	   		<occurrence>
1489	   			<mixing-start-time required-participant="participant">2004-12-17T09:30:00-05:00</mixing-start-time>
1490	   			<mixing-stop-time required-participant="none">2004-12-17T12:30:00-05:00</mixing-stop-time>
1491	   			<can-join-after>2001-12-17T09:25:00-05:00</can-join-after>
1492	   			<must-join-before>2004-12-17T12:00:00-05:00</must-join-before>
1493	   			<request-users required-participant="none">2001-12-17T09:30:00-05:00</request-users>
1494	   		</occurrence>
1495	   	</time>
1496	   	<dialout-list>
1497	   		<target uri="sip:bob@example.com"/>
1498	   	</dialout-list>
1499	   	<refer-list>
1500	   		<target uri="sip:sarah@example.com"/>
1501	   	</refer-list>
1502	   	<media-streams>
1503	   		<video/>
1504	   		<audio/>
1505	   	</media-streams>
1506	   	<cr:ruleset>
1507	   		<cr:rule id="1">
1508	   			<cr:conditions>
1509	   				<cr:identity>
1510	   					<cr:domain>example.com</cr:domain>
1511	   				</cr:identity>
1512	   			</cr:conditions>
1513	   			<cr:actions>
1514	   				<allow-conference-state>true</allow-conference-state>
1515	   				<join-handling>allow</join-handling>
1516	   			</cr:actions>
1517	   			<cr:transformations/>
1518	   		</cr:rule>
1519	   		<cr:rule id="2">
1520	   			<cr:conditions>
1521	   				<cr:identity>
1522	   					<cr:id>alice@example.com</cr:id>
1523	   				</cr:identity>
1524	   			</cr:conditions>
1525	   			<cr:actions/>
1526	   			<cr:transformations>
1527	   				<is-key-participant>true</is-key-participant>
1528	   			</cr:transformations>
1529	   		</cr:rule>
1530	   	</cr:ruleset>
1531	   </conference>

1533	7.  Security Considerations

1535	   A conference policy document may contain information that is highly
1536	   sensitive.  Its delivery to the conference server needs to happen
1537	   strictly, paying special attention to integrity and confidentiality.
1538	   Reading the document is also a security concern since the conference
1539	   policy contains sensitive information like the topic of the
1540	   conference, who is allowed to join and the URIs of the users that can
1541	   participate.

1543	   Manipulations of the conference policy have similar security issues.
1544	   Users with relevant privileges can manipulate parts of the conference
1545	   policy.  A user impersonating another may make changes to a
1546	   conference policy.  This can happen because the conference policy may
1547	   have a companion conference policy provileges document that carries
1548	   the identities and the authorization rules that apply to those
1549	   identities.  Those authorization rules carry the privileges that
1550	   certain identities have.  If an unauthorized user gets access to the
1551	   conference policy document (pretending to be someone else), s/he can
1552	   manipulate parts of the conference policy under a false identity.
1553	   Some of the things that a malicious user can do include: giving
1554	   himself floor moderation, removing users from lists, removing rules
1555	   for certain identities, changing the media streams and changing
1556	   conference time.  Therefore, it is very important that only
1557	   authorized clients are able to manipulate the conference policy.  Any
1558	   conference policy transport protocol MUST provide authentication,
1559	   confidentiality and integrity.

1561	   Passcodes are generated and distributed by means outside the scope of
1562	   this document.  The distribution mechanism MUST be secure.  If
1563	   distributed via email, it is recommented that the emails are signed
1564	   and ecrypted.

1566	   External lists are have also potential of abuse.  A focus bringing in
1567	   identities to a conference using an external list MUST make sure that
1568	   the list is created an maintained in a secure manner.  It is NOT
1569	   RECOMMENDED for a focus to use external lists that are not within its
1570	   trust domain.

1572	   A focus accepting a user requesting pseudonymity into a conference
1573	   may result in a user impersonating another.  The imporsonation cannot
1574	   be detectable by the focus and may cause other users that rely of a
1575	   user interface providing names of participants to be misinformed.  Of
1576	   course the focus does not rely on the pseudonym to authenticate a
1577	   user.  A conference creator needs to be careful when creating such
1578	   rules allowing pseudonymity.  A safer rule to have is for the
1579	   conference policy itself to provide the transformation
1580	   <provide-pseudonymity>.  this, however, requires the user to ask the
1581	   creator or a privileged user, out of band, to provide such rule that
1582	   gives that user pseudonymity.

1584	8.  IANA Considerations

1586	8.1  XCAP Application Usage ID

1588	   This section registers a new XCAP Application Usage ID (AUID)
1589	   according to the IANA procedures defined in..

1591	   Name of the AUID: conference-policy
1592	   Description: Conference policy application manipulates conference
1593	   policy at a server.

1595	8.2  application/conference-policy+xml MIME TYPE

1597	   MIME media type: application

1599	   MIME subtype name: conference-policy+xml

1601	   Mandatory parameters: none

1603	   Optional parameters: Same as charset parameter application/xml as
1604	   specified in RFC 3023 [7].

1606	   Encoding considerations: Same as encoding considerations of
1607	   application/xml as specified in RFC 3023 [7].

1609	   Security considerations: See section 10 of RFC 3023 [7] and section
1610	   Section 8 of this document.

1612	   Interoperability considerations: none.

1614	   Published specification: This document.

1616	   Applications which use this media type: This document type has been
1617	   used to support conference policy manipulation for SIP based
1618	   conferencing.

1620	   Additional information:

1622	   Magic number: None

1624	   File extension: .cl or .xml

1626	   Macintosh file type code: "TEXT"

1628	   Personal and email address for further information: Petri Koskelainen
1629	   (petri.koskelainen@nokia.com)

1631	   Intended Usage: COMMON
1632	   Author/change controller: The IETF

1634	8.3  URN Sub-Namespace Registration for
1635	    urn:ietf:params:xml:ns:conference-policy

1637	   This section registers a new XML namespace, as per guidelines in URN
1638	   document [15].

1640	   URI: The URI for this namespace is
1641	   urn:ietf:params:xml:ns:conference-policy.

1643	   Registrant Contact: IETF, XCON working group, Petri Koskelainen
1644	   (petri.koskelainen@nokia.com)

1646	   XML:

1648	   BEGIN
1649	   <?xml version="1.0"?>
1650	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
1651	        "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
1652	   <html xmlns="http://www.w3.org/1999/xhtml">
1653	   <head>
1654	    <meta http-equiv="content-type"
1655	      content="text/html;charset=iso-8859-1"/>
1656	    <title>Conference Policy Namespace</title>
1657	   </head>
1658	   <body>
1659	     <h1>Namespace for Conference Policy</h1>
1660	     <h2>application/conference-policy+xml</h2>
1661	     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
1662	   </body>
1663	   </html>
1664	   END

1666	9.  Contributors

1668	      Jose Costa-Requena

1670	      Simo Veikkolainen

1672	      Teemu Jalava

1674	10.  Acknowledgements

1676	   The authors would like to thank Markus Isomaki, Adam Roach, Eunsook
1677	   Kim, Roni Evan, Alan Johnston, Hannes Tschofenig, Cullen Jennings,
1678	   Rohan Mahy and the IETF XCON working group for their feedback and
1679	   suggestions.

1681	11  Normative References

1683	   [1]   Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J. and J.
1684	         Rosenberg, "Common Policy", Internet-Draft
1685	         I-D.ietf-geopriv-common-policy, February 2004.

1687	   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
1688	         Levels", RFC 2119, BCD 14, March 1997.

1690	   [3]   Moats, R., "URN Syntax", RFC 2141, May 1997.

1692	   [4]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
1693	         August 1999.

1695	   [5]   Rosenberg, J., Shulzrinne, H., Camarillo, G., Johnston, A.,
1696	         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
1697	         Session Initiation Protocol", RFC 3261, June 2002.

1699	   [6]   Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
1700	         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
1701	         REC REC-xml-20001006, October 2000.

1703	   [7]   Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC
1704	         3023, January 2001.

1706	   [8]   Koskelainen, P. and H. Khartabil, "Requirements for conference
1707	         policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in
1708	         progress), January 2004.

1710	   [9]   Johnston, A. and O. Levin, "Session Initiation Protocol Call
1711	         Control - Conferencing for User Agents",
1712	         draft-ietf-sipping-cc-conferencing-03 (work in progress),
1713	         February 2004.

1715	   [10]  Rosenberg, J., "The Extensible Markup Language (XML)
1716	         Configuration Access Protocol (XCAP)",
1717	         draft-ietf-simple-xcap-02 (work in progress), February 2004.

1719	   [11]  Rosenberg, J., "An Extensible Markup Language (XML)
1720	         Configuration Access Protocol (XCAP) Usage for Presence Lists",
1721	         draft-ietf-simple-xcap-list-usage-02 (work in progress),
1722	         February 2004.

1724	   [12]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
1725	         Package for Modification Events for the Extensible Markup
1726	         Language (XML) Configuration Access Protocol (XCAP) Managed
1727	         Documents", draft-ietf-simple-xcap-package-01 (work in
1728	         progress), February 2004.

1730	   [13]  Rosenberg, J., "A Framework for Conferencing with the Session
1731	         Initiation Protocol",
1732	         draft-ietf-sipping-conferencing-framework-01 (work in
1733	         progress), October 2003.

1735	   [14]  Rosenberg, J., Shulzrinne, H. and O. Levin, "A Session
1736	         Initiation Protocol (SIP) Event Package for Conference State",
1737	         draft-ietf-sipping-conference-package-03, February 2004.

1739	   [15]  Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

1741	   [16]  Khartabil, H. and A. Niemi, "Privileges for Manipulating a
1742	         Conference Policy",
1743	         draft-ietf-xcon-conference-policy-privileges-00 (work in
1744	         progress), September 2004.

1746	   [17]  Jennings, C. and B. Rosen, "Media Mixer Control for XCON",
1747	         draft-jennings-xcon-media-control-00 (work in progress),
1748	         February 2004.

1750	   [18]  Rosen, B. and A. Johnson, "SIP Conferencing: Sub-conferences
1751	         and Sidebars", draft-rosen-xcon-conf-sidebars-01 (work in
1752	         progress), July 2004.

1754	Authors' Addresses

1756	   Hisham Khartabil
1757	   Nokia
1758	   P.O. Box 321
1759	   Helsinki  FIN-00045
1760	   Finland

1762	   EMail: hisham.khartabil@nokia.com

1764	   Petri Koskelainen
1765	   Nokia
1766	   P.O. Box 100 (Visiokatu 1)
1767	   Tampere  FIN-33721
1768	   Finland

1770	   EMail: petri.koskelainen@nokia.com
1771	   Aki Niemi
1772	   Nokia
1773	   P.O. Box 100
1774	   NOKIA GROUP, FIN  00045
1775	   Finland

1777	   Phone: +358 50 389 1644
1778	   EMail: aki.niemi@nokia.com

1780	Intellectual Property Statement

1782	   The IETF takes no position regarding the validity or scope of any
1783	   Intellectual Property Rights or other rights that might be claimed to
1784	   pertain to the implementation or use of the technology described in
1785	   this document or the extent to which any license under such rights
1786	   might or might not be available; nor does it represent that it has
1787	   made any independent effort to identify any such rights.  Information
1788	   on the procedures with respect to rights in RFC documents can be
1789	   found in BCP 78 and BCP 79.

1791	   Copies of IPR disclosures made to the IETF Secretariat and any
1792	   assurances of licenses to be made available, or the result of an
1793	   attempt made to obtain a general license or permission for the use of
1794	   such proprietary rights by implementers or users of this
1795	   specification can be obtained from the IETF on-line IPR repository at
1796	   http://www.ietf.org/ipr.

1798	   The IETF invites any interested party to bring to its attention any
1799	   copyrights, patents or patent applications, or other proprietary
1800	   rights that may cover technology that may be required to implement
1801	   this standard.  Please address the information to the IETF at
1802	   ietf-ipr@ietf.org.

1804	Disclaimer of Validity

1806	   This document and the information contained herein are provided on an
1807	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1808	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1809	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1810	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1811	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1812	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1814	Copyright Statement

1816	   Copyright (C) The Internet Society (2004).  This document is subject
1817	   to the rights, licenses and restrictions contained in BCP 78, and
1818	   except as set forth therein, the authors retain all their rights.

1820	Acknowledgment

1822	   Funding for the RFC Editor function is currently provided by the
1823	   Internet Society.