idnits 2.17.1 

draft-ietf-xcon-cpcp-00.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 3667, Section 5.1 on line 15.

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

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

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

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

  ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
     1770), which is fine, but *also* found old RFC 2026, Section 10.4C,
     paragraph 1 text on line 37.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** 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:

        By submitting this Internet-Draft, I certify that any applicable patent
        or other IPR claims of which I am aware have been disclosed, or
        will be disclosed, and any of which I become aware will be
        disclosed, in accordance with RFC 3668.


  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 54 instances of too long lines in the document, the longest
     one being 125 characters in excess of 72.

  ** There are 385 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 438 has weird spacing: '...ined in  the c...'

  == Line 645 has weird spacing: '...N codes  to...'

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

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

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

  == (1 more instance...)

  -- 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 (September 9, 2004) is 7162 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 1636, but no explicit reference
     was found in the text

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

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

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

  == Unused Reference: '21' is defined on line 1702, 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

  ** Obsolete normative reference: RFC 2617 (ref. '16') (Obsoleted by RFC
     7235, RFC 7615, RFC 7616, RFC 7617)

  ** Obsolete normative reference: RFC 2818 (ref. '17') (Obsoleted by RFC
     9110)

  == Outdated reference: A later version (-01) exists of
     draft-rosen-xcon-conf-sidebars-00

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

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

  == Outdated reference: A later version (-26) exists of
     draft-ietf-mmusic-sdp-new-18


     Summary: 14 errors (**), 0 flaws (~~), 23 warnings (==), 11 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: March 10, 2005                                         A. Niemi
4	                                                                   Nokia
5	                                                       September 9, 2004

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

10	Status of this Memo

12	   By submitting this Internet-Draft, I certify that any applicable
13	   patent or other IPR claims of which I am aware have been disclosed,
14	   and any of which I become aware will be disclosed, in accordance with
15	   RFC 3668.

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

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

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

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

33	   This Internet-Draft will expire on March 10, 2005.

35	Copyright Notice

37	   Copyright (C) The Internet Society (2004).  All Rights Reserved.

39	Abstract

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

50	Table of Contents

52	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
53	   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
54	   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
55	   4.  Structure of a Conference Policy document  . . . . . . . . . .  4
56	     4.1   MIME Type for CPCP XML Document  . . . . . . . . . . . . .  4
57	     4.2   Conference Root  . . . . . . . . . . . . . . . . . . . . .  4
58	     4.3   XML Document Description . . . . . . . . . . . . . . . . .  5
59	       4.3.1   Conference Settings  . . . . . . . . . . . . . . . . .  5
60	       4.3.2   Conference Information . . . . . . . . . . . . . . . .  7
61	       4.3.3   Conference Time  . . . . . . . . . . . . . . . . . . .  8
62	       4.3.4   Conference Authorization Rules . . . . . . . . . . . .  9
63	       4.3.5   Conference Dial-Out List . . . . . . . . . . . . . . . 20
64	       4.3.6   Conference Refer List  . . . . . . . . . . . . . . . . 20
65	       4.3.7   Conference Media Streams . . . . . . . . . . . . . . . 21
66	     4.4   XML Schema Extensibility . . . . . . . . . . . . . . . . . 21
67	     4.5   XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 22
68	   5.  Conference Policy Manipulation and Conference Entity
69	       Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . . . 27
70	     5.1   Overview of Operation  . . . . . . . . . . . . . . . . . . 27
71	     5.2   Use of External Lists  . . . . . . . . . . . . . . . . . . 27
72	     5.3   Communication Between Conference Entities  . . . . . . . . 28
73	     5.4   Manipulating Participant Lists . . . . . . . . . . . . . . 28
74	       5.4.1   Expelling a Participant  . . . . . . . . . . . . . . . 28
75	     5.5   Re-joining a Conference  . . . . . . . . . . . . . . . . . 30
76	   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
77	     6.1   A Simple Conference Policy Document  . . . . . . . . . . . 30
78	     6.2   A Complex Conference Policy Document . . . . . . . . . . . 31
79	   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
80	   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
81	     8.1   XCAP Application Usage ID  . . . . . . . . . . . . . . . . 34
82	     8.2   application/conference-policy+xml MIME TYPE  . . . . . . . 34
83	     8.3   URN Sub-Namespace Registration for
84	           urn:ietf:params:xml:ns:conference-policy . . . . . . . . . 35
85	   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36
86	   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
87	   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 36
88	   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 36
89	   11.2  Informative References . . . . . . . . . . . . . . . . . . . 38
90	       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38
91	       Intellectual Property and Copyright Statements . . . . . . . . 40

93	1.  Introduction

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

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

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

110	2.  Conventions Used in This Document

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

116	3.  Terminology

118	   This document uses terminology from [13].  Some additional
119	   definitions are introduced here.

121	   Conference authorization policy (CAP):  Conference authorization
122	      policy consists of an unordered set of rules, which control the
123	      permissions and privileges that are given to conference
124	      participants.

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

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

131	   Floor control:  Floor control is a mechanism that enables
132	      applications or users to gain safe and mutually exclusive or
133	      non-exclusive access to the shared object or resource in a
134	      conference.

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

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

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

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

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

150	4.  Structure of a Conference Policy document

152	   The conference policy document is an XML [6] document that MUST be
153	   well-formed and MUST be valid.  The Conference policy documents MUST
154	   be based on XML 1.0 and MUST be encoded using UTF-8.  This
155	   specification makes use of XML namespaces for identifying conference
156	   policy documents and document fragments.  The namespace URI for
157	   elements defined by this specification is a URN [3], using the
158	   namespace identifier 'ietf' defined by [4] and extended by [15].
159	   This URN is:

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

163	4.1  MIME Type for CPCP XML Document

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

168	4.2  Conference Root

170	   A conference policy document begins with the root element tag
171	   <conference>.  Other elements from different namespaces MAY be
172	   present for the purposes of extensibility.  Elements or attributes
173	   from unknown namespaces MUST be ignored.  The conference policy is
174	   build up using the following:

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

181	   o  The <info> element: This element is optional and includes
182	      information describing the conference, that can be used, for
183	      example, search purposes.  This information can also be used in
184	      the session description when the focus is sending invitations.  It
185	      can occur only once in the document.

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

191	   o  The <authorization> element: This optional element is the
192	      conference authorisation rules.  It contains rules for users who
193	      can dial into the conference, users who are blocked from dialling
194	      in, amongst others.

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

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

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

207	   The elements are described in more detail in the forthcoming
208	   sections.

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

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

220	4.3  XML Document Description

222	4.3.1  Conference Settings

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

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

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

241	   <security-level> is an optional element.  It describes the security
242	   level that the creator of the conference wishes to have for the
243	   conference being created, including signalling and media.  There are
244	   4 security levels defined: none, low, medium, and high with medium
245	   being the default value if this element is absent.  Those levels are
246	   loosly defined here.  The interpretation of those levels and the
247	   security protocols applied is left as a local policy of the focus.  A
248	   focus may interpret those levels as follows:

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

252	   low:  Signalling and media integrity is required

254	   medium:  Signalling and media confidentiality is required

256	   high:  Signalling and media integrity and confidentiality are
257	      required

259	   <allow-sidebars> is an optional element with a boolean value
260	   indicating if sidebars are allowed in this conference or not.  The
261	   default value, if omitted, is "true" indicating that sidebars are
262	   allowed.

264	   <sidebar> is an element identifying a side bar.  Multiple <sidebar>
265	   elements can occur indicating multiple sidebars.  No <sidebar>
266	   elements appearing in a conference policy indicates that there are no
267	   sidebars currently for this conference.  A <sidebar> element contains
268	   a mandatory 'id' attribute that uniquely identifies the sidebar.  It
269	   also contains an <uri> element that hold the sidebar URI.  It can
270	   occur more than once to accommodate multiple signaling protocols.
271	   Once a sidebar URI is set, it MUST NOT be changed or removed for the
272	   duration of the conference.  Only one URI per protocol MUST be set.
273	   URIs can be added at any time.

275	   A sidebar MAY have its own policy.  This policy is created exactly in
276	   the same manner as any other conference.  The <policy> element in the
277	   <sidebar> element points to such policy.  If the <policy> element is
278	   omitted, the sidebar inherits the policy of the conference it is a
279	   sidebar of.

281	   A conference is identified by one or more conference URIs, one for
282	   each call signaling protocol that is supported.  There must be at
283	   least one URI for a conference.  Conference URIs can be proposed by
284	   the creator of the conference policy, as it may be useful to have
285	   human-friendly name in some cases, or can be assigned by the CPS.  If
286	   the creator has proposed a conference URI, the server needs to decide
287	   whether to accept the name proposed by the client or not.  It does
288	   this determination by examining if the conference URI already exists
289	   or not.  If it exists, the CPS rejects the request to create the
290	   conference with that conference URI.  Similarly, the CPS rejects the
291	   request to create a conference with a conference URI for a signalling
292	   protocol it does not support.

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

298	   Sidebar URIs are subject to the same behaviour.

300	4.3.2  Conference Information

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

309	   Each conference has an optional <subject> element, which describes
310	   the current topic in a conference.  The optional <display-name>
311	   element is the display name of the conference, which usually does not
312	   change over time.

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

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

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

329	4.3.3  Conference Time

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

337	   The <time> element contains one or more <occurrence> elements each
338	   defining the time information of a single conference occurrence.
339	   Multiple <occurrence> elements MAY be used if a conference is active
340	   at multiple times; each additional <occurrence> element contains time
341	   information for a specific occurrence.

343	   For each occurrence, the <mixing-start-time> element specifies when
344	   conference media mixing starts.  the <mixing-stop-time> element
345	   specifies the time a conference media mixing stops.  If the
346	   <mixing-start-time> element is not present, it indicates that the
347	   conference media mixing starts immediately.  If the
348	   <mixing-stop-time> element is not present, it indicates that the
349	   conference occurrence is not bounded, i.e.  permanent unitl the
350	   conference policy is removed from the server.

352	   <mixing-start-time> and <mixing-stop-time> elements both have the
353	   mandatory 'require-participant' attribute.  This attribute has one of
354	   3 values: "none", "key-participant", and "participant".  For mixing
355	   start time, this attribute allows a privileged user to define when
356	   media mixing starts based on the latter of the mixing start time, and
357	   the time the first participant or key participant arrives.  If the
358	   value is set to "none", mixing starts according to the mixing start
359	   time.  For mixing stop time, this attribute allows a privileged user
360	   to define when media mixing stops based on the earlier of the mixing
361	   stop time, and the time the last participant or key participant
362	   leaves.  If the value is set to "none", mixing stops according to the
363	   mixing stop time.

365	   Users can be allowed to join a conference before the media mixing
366	   time starts and after a certain time.  A conference privileged user
367	   can indicate the time when users can join by populating the
368	   <can-join-after> element.  Similarly, a conference privileged user
369	   can define the time after which new users are not allowed to join the
370	   conference anymore.  This is done by populating the
371	   <must-join-before> element.

373	   It is possible to define the time when users or resources on the
374	   dial-out list and on the refer-list are requested to join the
375	   conference by using the <request-users> element.  It is also possible
376	   to define that the users and resources on the dial-out list and the
377	   refer-list are requested to join the conference only after the first
378	   a participant or key participant has joined.  This is achieved with
379	   the 'require-participant' attribute.  A value of "none" indicates
380	   that the focus sends the requests immediately after the specified
381	   time has lapsed.

383	   The absence of this conference time information indicates that a
384	   conference starts immediately and terminates when the conference
385	   policy is removed.

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

391	   If a conference is in progress when deleted or stopped, the focus
392	   issues signalling requests to terminate all conference related
393	   sessions it has with participants.  In SIP, the focus issues BYE
394	   requests.

396	4.3.4  Conference Authorization Rules

398	   One of the key components of conference policy is the set of
399	   authorization rules that specify who is allowed to join a conference,
400	   see floors and request/grant them, subscribe to
401	   conference-information notifications and so on.  The unordered list
402	   of authorization rules together define the conference authorization
403	   policy

405	   The conference authorization rules are enclosed in the
406	   <authorization-rules> element and are formatted according to the XML
407	   schema defined in the common policy framework [1].  In the
408	   <authorization-rules> element, there can be multiple rules, each rule
409	   is represented by the <rule> element, each of which consist of three
410	   parts: conditions, actions and transformations.  Conditions determine
411	   whether a particular rule applies to a request.  Each action or
412	   transformation in the applied rule is a positive grant of permission
413	   to the conference participant.  The details of each specific element
414	   and attribute is described in [1].

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

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

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

431	   This section outlines the new conditions, actions and transformations
432	   for conference authorization policy.

434	4.3.4.1  Conditions

436	4.3.4.1.1  Validity

438	   The <validity> element, as defined in  the common policy framework
439	   [1], expresses the rule validity period by two attributes, a starting
440	   and a ending time.  Times are expressed in XML dateTime format.
441	   Expressing the lifetime of a rule implements a garbage collection
442	   mechanism.  A rule maker might not have always access to the
443	   conference policy server to remove some rules which grant
444	   permissions.  Hence this mechanisms allows to remove or invalidate
445	   granted permissions automatically without further interaction between
446	   the rule maker and the conference policy server.

448	   To give a real life example, there are often meetings where
449	   management are allowed to join the first half of the conference and
450	   engineers are only allowed to join the conference during the second
451	   half of that meeting to report technical findings, etc.  Two rules
452	   can be set in this scenario, the first rules allows the managers to
453	   join the conference without specifying a validity contraint.  The
454	   second rule allows engineers to join an hour into the conference.
455	   The following example demostrates this.  The meeting starts at 9:30
456	   and ends at 12:30.  The manager can join at any time while the
457	   engineer cannot only join before 10:30 (Note that the example is
458	   simplified for clarity).

460	     <rule id="1">
461	       <conditions>
462	         <identity>
463	           <id>manager@example.com</id>
464	         </identity>
465	       </conditions>
466	       <actions>
467	         <join-handling>allow</join-handling>
468	       </actions>
469	       <transformations/>
470	     </rule>
471	     <rule id="2">
472	       <conditions>
473	         <validity>
474	           <from>2004-12-17T10:30:00-05:00</from>
475	           <to>2004-12-17T12:30:00-05:00</to>
476	         </validity>
477	         <identity>
478	           <id>engineeer@example.com</id>
479	         </identity>
480	       </conditions>
481	       <actions>
482	         <join-handling>allow</join-handling>
483	       </actions>
484	       <transformations/>
485	     </rule>
486	     ...
487	     <time>
488	       <occurrence>
489	         <mixing-start-time required-participant="participant">
490	           2004-12-17T09:30:00-05:00</mixing-start-time>
491	         <mixing-stop-time required-participant="none">
492	           2004-12-17T12:30:00-05:00</mixing-stop-time>
493	       </occurrence>
494	     </time>

496	4.3.4.1.2  Identity

498	   The <identity> element is already defined in the common policy
499	   framework [1]The presence of the <identity> element is a condition
500	   requires any identity within it to be authenticated before a rule is
501	   applied to it.  This includes the <id> element (Section 4.3.4.1.2.1),
502	   the <any> element (Section 4.3.4.1.2.2), the <external-list> element
503	   (Section 4.3.4.1.2.4), their exceptions, and any future extension
504	   that carries an identity.  The absence of the <identity> element with
505	   in a condition indicated that the rule applies to all unauthenticated
506	   identities.  That is participants that have provided no authenticated
507	   identity to the conference focus.

509	4.3.4.1.2.1  Interpreting the <id> Element

511	   As earlier indicated, the <identity> element is already defined in
512	   the common policy framework [1].  However, the rules for interpreting
513	   the identities in <id> elements are left for each application to
514	   define separately.  This document, however, does not define the rules
515	   for interpreting identities in <id> elements in conferencing
516	   applications since those interpretation rules are signalling protocol
517	   specific.

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

522	4.3.4.1.2.2  Matching Any Identity

524	   The <any> element is used to match any participant.  This allows a
525	   conference to be open to any authenticated user.  Just as for the
526	   <domain> element in <identity> element, The <any> element contains a
527	   list of <except> elements and allows to implement a simple blacklist
528	   mechanism.  The <except> element contains the identity.  It differs
529	   from the <domain> element in that the domain part is needed in the
530	   identity since it has not domain to refer to.

532	4.3.4.1.2.3  Matching Pseudonymous Identities

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

542	   	<rule id="4">
543	      		<conditions>
544	      			<pseudonymous>
545	   		</conditions>
546	      		<actions>
547	      			<join-handling>allow</join-handling>
548	      		</actions>
549	      		<transformations/>
550	      	</rule>

552	   The <pseudonymous> element can be combined with the <identity>
553	   element to provide the focus with a rule on what to do when a
554	   specific identity is authenticated and that identity is requesting
555	   pseudonymity through the signalling protocol.  An example of such a
556	   rule follows:

558	   <rule id="4">
559	     <conditions>
560	       <identity>
561	         <id>alice@example.com</id>
562	       </identity>
563	       <pseudonymous>
564	     </conditions>
565	     <actions>
566	       <join-handling>allow</join-handling>
567	     </actions>
568	     <transformations/>
569	   </rule>

571	4.3.4.1.2.4  Matching Identities in External Lists

573	   The <external-list> element can be used to match those participants
574	   that are part of a resource list that is created externally.  Section
575	   5.2 talks about the use of this condition in more detail.

577	4.3.4.1.2.5  Matching Referred Identities

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

582	4.3.4.1.2.6  Matching Invited Identities

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

587	4.3.4.1.2.7  Matching Identities of Former Conference Participants

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

592	4.3.4.1.2.8  Matching Identities Currently in the Conference

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

597	4.3.4.1.2.9  Matching Key Participant Identities

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

602	4.3.4.1.2.10  Matching Identities on the Dial-out List

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

607	4.3.4.1.2.11  Matching Identities on the Refer List

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

612	4.3.4.1.2.12  Floor ID

614	   The <floor-id> element can be used to assign users as floor
615	   moderators.  It MUST be used in conjunction with the <id> element
616	   that identifies the floor moderator.  The <floor-id> element carries
617	   the floor ID of the floor that the user is a moderator of.  The
618	   transformation <is-floor-moderator> is used to assert that the user
619	   identified using the <id> condition is the floor moderator of the
620	   floor identified in the <floor-id> condition.

622	   The <floor-id> element is also used with the <floor-request-handling>
623	   element (Section 4.3.4.2.6) to set rules on who is allowed to request
624	   a floor.

626	4.3.4.1.2.13  Matching PIN Codes

628	   The <pin> element can be used to match those participants that are
629	   have knowledge on a PIN code for the conference.  For example:

631	   	<rule id="1">
632	   		<conditions>
633	   			<pin>12345</pin>
634	   		</conditions>
635	   		<actions>
636	   			<join-handling>allow</join-handling>
637	   		</actions>
638	   		<transformations/>
639	   	</rule>

641	   So the condition is the PIN.  If any user knows the PIN, ignoring
642	   their identity, the user is allowed to join.

644	   A combination of the <identity> condition and the <pin>  condition
645	   creates the possibility of assigning users personal PIN codes  to
646	   enable them to join a conference.  For example:

648	   	<rule id="2">
649	   		<conditions>
650	   			<identity>
651	   				<id>358401234567</id>
652	   			</identity>
653	   			<pin>67890</pin>
654	   		</conditions>
655	   		<actions>
656	   			<join-handling>allow</join-handling>
657	   		</actions>
658	   		<transformations/>
659	   	</rule>

661	4.3.4.1.2.14  Matching Passwords

663	   The <password> element can be used to match those participants that
664	   are have knowledge on a password for the conference.  For example:

666	   	<rule id="3">
667	   		<conditions>
668	   			<password>pass1</password>
669	   		</conditions>
670	   		<actions>
671	   			<join-handling>allow</join-handling>
672	   		</actions>
673	   		<transformations/>
674	   	</rule>

676	   So the condition is the password.  If any user knows the password,
677	   ignoring their identity, the user is allowed to join.

679	   A combination of the <identity> condition and the <password>
680	   condition creates the possibility of assigning users personal
681	   passwords to enable them to join a conference.  For example:

683	   	<rule id="4">
684	   		<conditions>
685	   			<identity>
686	   				<id>alice@example.com</id>
687	   			</identity>
688	   			<password>pass2</password>
689	   		</conditions>
690	   		<actions>
691	   			<join-handling>allow</join-handling>
692	   		</actions>
693	   		<transformations/>
694	   	</rule>

696	4.3.4.2  Actions

698	4.3.4.2.1  Conference State Events

700	   The <allow-conference-state> element represents a boolean action.  If
701	   set to TRUE, the focus is instructed to allow the subscription to
702	   conference state events, such as the SIP Event Package for Conference
703	   State [14].  If set to FALSE, the subscription to conference state
704	   events would be rejected.

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

709	4.3.4.2.2  Floor Control Events

711	   The <allow-floor-events> element represents a boolean action.  If set
712	   to TRUE, the focus is instructed to accept the subscription to floor
713	   control events.  If set to FALSE, the focus is instructed to reject
714	   the subscription.

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

719	4.3.4.2.3  Conference Join Handling

721	   The <join-handling> element defines the actions used by the
722	   conference focus to control conference participation.  This element
723	   defines the action that the focus is to take when processing a
724	   particular request to join a conference.  This element is an
725	   enumerated integer type, with defined values of:

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

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

737	   allow:  This action instructs the focus to accept the conference join
738	      request and grant access to the conference within the instructions
739	      specified in the transformations of this rule.  This action has a
740	      value of two.

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

748	4.3.4.2.4  Dynamically Referring Users

750	   The <allow-refer-users-dynamically> element represents a boolean
751	   action.  If set to TRUE, the identity is allowed  to instruct the
752	   focus to refer a user to the conference without modifying the
753	   refer-list (in SIP terms, the identity is allowed to send a REFER
754	   request to the focus which results in the focus sending a REFER
755	   request to the user the referrer wishes to join the conference).  If
756	   set to FALSE, the refer request is rejected.

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

761	4.3.4.2.5  Dynamically Inviting Users

763	   The <allow-invite-users-dynamically> element represents a boolean
764	   action.  If set to TRUE, the identity is allowed  to instruct the
765	   focus to invite a user to the conference without modifying the
766	   dial-out list (in SIP terms, the identity is allowed to send a REFER
767	   request to the focus which results in the focus sending an INVITE
768	   requested to the user the referrer wishes to join the conference).
769	   If set to FALSE, the refer request is rejected.

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

774	4.3.4.2.6  Floor Request Handling

776	   The <floor-request-handling> element defines the actions used by the
777	   conference focus to control floor requests.  This element defines the
778	   action that the focus is to take when processing a particular request
779	   to a floor within a conference.  This element is an enumerated
780	   integer type, with defined values of:

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

787	   confirm:  This action instructs the focus to allow the request.  The
788	      focus then uses the defined floor algorithm to further allow of
789	      deny the floor.  The algorithms used are outside the scope of this
790	      document.

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

798	4.3.4.3  Transformations

800	4.3.4.3.1  Key Participant

802	   When the <is-key-participant> element is set to TRUE, the joining
803	   participant is denoted as a key participant.  If set to FALSE, the
804	   participant is not denoted as a key participant.

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

809	4.3.4.3.2  Floor Moderator

811	   When the <is-floor-moderator> element is set to TRUE, the joining
812	   conference participant is denoted as floor moderator, meaning that
813	   they are privileged to control the floor in the conference.  If set
814	   to FALSE, floor moderator privileges are not given to the conference
815	   participant.

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

820	4.3.4.3.3  Conference Information

822	   The <show-conference-info> element is of type boolean transformation.
823	   If set to TRUE, conference information is shown to the conference
824	   participant.  If set to FALSE, conference information is not shown to
825	   the participant.

827	   The <show-conference-info> element controls whether information in
828	   the <settings>, <time> and <info> elements may be made available
829	   publicly.  For example, an application at a conference server might
830	   list the ongoing conferences on web page, or it may allow searching
831	   for conferences based on the keywords listed in the <Conference-info>
832	   element.  Not setting this transformation to any users instructs the
833	   application not to reveal any such information to any user.  However,
834	   information in other elements, such as <dialout-list>, should not be
835	   seen by anyone else other than a privileged user, even with this
836	   transformation enabled for a user.

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

841	4.3.4.3.4  Floor Holder

843	   The <show-floor-holder> element is of type boolean transformation.
844	   If set to TRUE, the conference participant is able to see who is
845	   currently holding the floor.  If set to FALSE, the participant is not
846	   able to see the floor holder.

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

851	4.3.4.3.5  Floor Requests

853	   The <show-floor-requests> element is of type boolean transformation.
854	   If set to TRUE, the conference participant is able to see the floor
855	   requests.  If set to FALSE, the conference participant is not able to
856	   see floor requests.

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

861	4.3.4.3.6  Providing anonymity

863	   A rule can be set that provides anonymity to a specific identity.  In
864	   this case, the focus provides to the rest of the participants an
865	   anonymous identity for that user, for example anonymous1.  This can
866	   be achieved by using the <provide-anonymity> element.  It is a
867	   boolean transformation.  If set to TRUE, the conference participants
868	   will see an anonymous identity for the user whose identity is present
869	   in the conditions.  An example of such rule follows:

871	   <rule id="4">
872	     <conditions>
873	       <identity>
874	         <id>alice@example.com</id>
875	       </identity>
876	     </conditions>
877	     <actions>
878	       <join-handling>allow</join-handling>
879	     </actions>
880	     <transformations>
881	       <provide-anonymity>
882	     </transformation>
883	   </rule>

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

888	4.3.5  Conference Dial-Out List

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

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

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

907	4.3.6  Conference Refer List

909	   The Refer List (RL) contains a list of resources that the focus needs
910	   to refer to the conference.  In SIP, this is achieved by the focus
911	   sending a REFER request to those potential participants.  This list
912	   can be updated during the conference lifetime so it can be used for
913	   mid-conference refers as well.

915	   The Refer List differs from the Dial-out list in that the dial-out
916	   list contains a list of resources that the focus will initiate a
917	   session with.  The resources on the refer list, on the other had, are
918	   expected to initiate the session establishment towards the focus
919	   themselves.  It is also envisioned that difference users will have
920	   different access rights to those lists and therefore a separation
921	   between the two is needed.

923	   The <refer-list> element is optional and identical to the
924	   <dialout-list> element in Section 4.3.5.

926	4.3.7  Conference Media Streams

928	   Media policy is an integral part of the conference policy.  It
929	   defines e.g.  what kind of media topologies exist in the conference.
930	   Media policy is documented in [20].This document does not define
931	   media policy, but instead enables the user to specify the media
932	   streams a conference has.  This is used by the focus to know what
933	   media streams to invite users with and what media streams it should
934	   accept from dialling in users.  Media can be added to or removed from
935	   a conference by a privileged user before or during a conference
936	   occurance.  This might result in the focus modifying the session it
937	   has with each participant.  In SIP, this means re-issuing and INVITE
938	   request modifying the session description (SDP).

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

945	4.4  XML Schema Extensibility

947	   The schema as be extended at multiple places:

949	   o  The <conference> element to enable more conference policy
950	      information to be added

952	   o  The <settings> element to allow for future conference settings to
953	      be defined

955	   o  The <info> element to allow further conference and host
956	      information to be conveyed

958	   o  The <occurrence> element to allow further conference timing
959	      information

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

965	   o  The <media-streams> element to allow introduction of new media
966	      streams

968	   o  The <sidebar> element to allow introduction of new sidebar
969	      information

971	4.5  XML Schema

973	   <?xml version="1.0" encoding="UTF-8"?>
974	   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:conference-policy" elementFormDefault="qualified">
975	   	<!-- This import brings in the XML language attribute xml:lang-->
976	   	<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
977	   	<!-- The root Conference Element -->
978	   	<xs:element name="conference">
979	   		<xs:complexType>
980	   			<xs:sequence>
981	   				<xs:element name="settings" type="ConferenceSettings"/>
982	   				<xs:element name="info" type="ConferenceInfo" minOccurs="0"/>
983	   				<xs:element name="time" type="ConferenceTime" minOccurs="0"/>
984	   				<xs:element name="authorization-rules" type="ConferenceAuthorizationRules" minOccurs="0"/>
985	   				<xs:element name="dailout-list" type="UserList" minOccurs="0"/>
986	   				<xs:element name="refer-list" type="UserList" minOccurs="0"/>
987	   				<xs:element name="media-streams" type="ConferenceMediaStreams" minOccurs="0"/>
988	   				<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
989	   			</xs:sequence>
990	   		</xs:complexType>
991	   	</xs:element>
992	   	<!-- Conference Settings -->
993	   	<xs:complexType name="ConferenceSettings">
994	   		<xs:sequence>
995	   			<xs:element name="conference-uri" type="xs:anyURI" maxOccurs="unbounded"/>
996	   			<xs:element name="max-participant-count" type="xs:nonNegativeInteger" minOccurs="0"/>
997	   			<xs:element name="security-level" type="SecurityLevel" default="medium" minOccurs="0"/>
998	   			<xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/>
999	   			<xs:element name="sidebar" type="Sidebar" minOccurs="0" maxOccurs="unbounded"/>
1000	   			<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1001	   		</xs:sequence>
1002	   	</xs:complexType>
1003	   	<!-- Conference Info -->
1004	   	<xs:complexType name="ConferenceInfo">
1005	   		<xs:sequence>
1006	   			<xs:element name="subject" type="xs:string" minOccurs="0"/>
1007	   			<xs:element name="display-name" type="xs:string" minOccurs="0"/>
1008	   			<xs:element name="free-text" type="xs:string" minOccurs="0"/>
1009	   			<xs:element name="keywords" minOccurs="0">
1010	   				<xs:simpleType>
1011	   					<xs:list itemType="xs:string"/>
1012	   				</xs:simpleType>
1013	   			</xs:element>
1014	   			<xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
1015	   			<xs:element name="host-info" minOccurs="0">
1016	   				<xs:complexType>
1017	   					<xs:sequence>
1018	   						<xs:element name="uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
1019	   						<xs:element name="e-mail" type="xs:anyURI" minOccurs="0"/>
1020	   						<xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
1021	   					</xs:sequence>
1022	   				</xs:complexType>
1023	   			</xs:element>
1024	   			<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1025	   		</xs:sequence>
1026	   		<xs:attribute ref="xml:lang"/>
1027	   	</xs:complexType>
1028	   	<!-- Conference time -->
1029	   	<xs:complexType name="ConferenceTime">
1030	   		<xs:sequence>
1031	   			<xs:element name="occurrence" minOccurs="0" maxOccurs="unbounded">
1032	   				<xs:complexType>
1033	   					<xs:sequence>
1034	   						<xs:element name="mixing-start-time" type="StartStopTime" minOccurs="0"/>
1035	   						<xs:element name="mixing-stop-time" type="StartStopTime" minOccurs="0"/>
1036	   						<xs:element name="can-join-after" type="xs:dateTime" minOccurs="0"/>
1037	   						<xs:element name="must-join-before" type="xs:dateTime" minOccurs="0"/>
1038	   						<xs:element name="request-users" type="StartStopTime" minOccurs="0"/>
1039	   						<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1040	   					</xs:sequence>
1041	   				</xs:complexType>
1042	   			</xs:element>
1043	   		</xs:sequence>
1044	   	</xs:complexType>
1045	   	<!-- Conferenece Authorisation -->
1046	   	<xs:complexType name="ConferenceAuthorizationRules">
1047	   		<xs:sequence>
1048	   			<xs:element name="rule" type="ruleType" minOccurs="0" maxOccurs="unbounded"/>
1049	   		</xs:sequence>
1050	   	</xs:complexType>
1051	   	<xs:complexType name="ruleType">
1052	   		<xs:sequence>
1053	   			<xs:element name="conditions" minOccurs="0">
1054	   				<xs:complexType>
1055	   					<xs:sequence>
1056	   						<xs:element ref="condition" minOccurs="0" maxOccurs="unbounded"/>
1057	   					</xs:sequence>
1058	   				</xs:complexType>
1059	   			</xs:element>
1060	   			<xs:element name="actions" minOccurs="0">
1061	   				<xs:complexType>
1062	   					<xs:sequence>
1063	   						<xs:element ref="action" minOccurs="0" maxOccurs="unbounded"/>
1064	   					</xs:sequence>
1065	   				</xs:complexType>
1066	   			</xs:element>
1067	   			<xs:element name="transformations" minOccurs="0">
1068	   				<xs:complexType>
1069	   					<xs:sequence>
1070	   						<xs:element ref="transformation" minOccurs="0" maxOccurs="unbounded"/>
1071	   					</xs:sequence>
1072	   				</xs:complexType>
1073	   			</xs:element>
1074	   		</xs:sequence>
1075	   		<xs:attribute name="id" type="xs:string" use="required"/>
1076	   	</xs:complexType>
1077	   	<xs:element name="condition" abstract="true"/>
1078	   	<xs:element name="action" abstract="true"/>
1079	   	<xs:element name="transformation" abstract="true"/>
1080	   	<xs:element name="validity" substitutionGroup="condition">
1081	   		<xs:complexType>
1082	   			<xs:all>
1083	   				<xs:element name="from" type="xs:dateTime"/>
1084	   				<xs:element name="to" type="xs:dateTime"/>
1085	   			</xs:all>
1086	   		</xs:complexType>
1087	   	</xs:element>
1088	   	<xs:element name="identity" substitutionGroup="condition">
1089	   		<xs:complexType>
1090	   			<xs:choice>
1091	   				<xs:element name="id" type="xs:string" maxOccurs="unbounded"/>
1092	   				<xs:sequence>
1093	   					<xs:element name="domain" type="xs:string"/>
1094	   					<xs:sequence minOccurs="0">
1095	   						<xs:element name="except" type="xs:string" maxOccurs="unbounded"/>
1096	   					</xs:sequence>
1097	   				</xs:sequence>
1098	   				<xs:sequence>
1099	   					<xs:element name="any" type="xs:string"/>
1100	   					<xs:sequence minOccurs="0">
1101	   						<xs:element name="except" type="xs:string" maxOccurs="unbounded"/>
1102	   					</xs:sequence>
1103	   				</xs:sequence>
1104	   				<xs:sequence>
1105	   					<xs:element name="external-list" type="xs:string"/>
1106	   					<xs:sequence minOccurs="0">
1107	   						<xs:element name="except" type="xs:string" maxOccurs="unbounded"/>
1108	   					</xs:sequence>
1109	   				</xs:sequence>
1110	   			</xs:choice>
1111	   		</xs:complexType>
1112	   	</xs:element>
1113	   	<xs:element name="pseudonymous" type="xs:string" substitutionGroup="condition"/>
1114	   	<xs:element name="has-been-referred" type="xs:string" substitutionGroup="condition"/>
1115	   	<xs:element name="has-been-invited" type="xs:string" substitutionGroup="condition"/>
1116	   	<xs:element name="has-been-in-conference" type="xs:string" substitutionGroup="condition"/>
1117	   	<xs:element name="is-in-conference" type="xs:string" substitutionGroup="condition"/>
1118	   	<xs:element name="key-participant" type="xs:string" substitutionGroup="condition"/>
1119	   	<xs:element name="is-on-dialout-list" type="xs:string" substitutionGroup="condition"/>
1120	   	<xs:element name="is-on-refer-list" type="xs:string" substitutionGroup="condition"/>
1121	   	<xs:element name="floor-id" type="xs:anyURI" substitutionGroup="condition"/>
1122	   	<xs:element name="pin" type="xs:anyURI" substitutionGroup="condition"/>
1123	   	<xs:element name="password" type="xs:anyURI" substitutionGroup="condition"/>
1124	   	<xs:element name="allow-conference-state" type="xs:boolean" substitutionGroup="action"/>
1125	   	<xs:element name="allow-floor-events" type="xs:boolean" substitutionGroup="action"/>
1126	   	<xs:element name="join-handling" type="JoinHandling" substitutionGroup="action"/>
1127	   	<xs:element name="allow-refer-users-dynamically" type="xs:boolean" substitutionGroup="action"/>
1128	   	<xs:element name="allow-invite-users-dynamically" type="xs:boolean" substitutionGroup="action"/>
1129	   	<xs:element name="floor-request-handling" type="xs:boolean" substitutionGroup="action"/>
1130	   	<xs:element name="is-key-participant" type="xs:boolean" substitutionGroup="transformation"/>
1131	   	<xs:element name="is-floor-moderator" type="xs:boolean" substitutionGroup="transformation"/>
1132	   	<xs:element name="show-conference-info" type="xs:boolean" substitutionGroup="transformation"/>
1133	   	<xs:element name="show-floor-holder" type="xs:boolean" substitutionGroup="transformation"/>
1134	   	<xs:element name="show-floor-requests" type="xs:boolean" substitutionGroup="transformation"/>
1135	   	<xs:element name="provide-anonymity" type="xs:boolean" substitutionGroup="transformation"/>
1136	   	<!-- User List -->
1137	   	<xs:complexType name="UserList">
1138	   		<xs:sequence>
1139	   			<xs:element name="target" type="Target" minOccurs="0" maxOccurs="unbounded"/>
1140	   			<xs:element name="external" type="Target" minOccurs="0" maxOccurs="unbounded"/>
1141	   		</xs:sequence>
1142	   	</xs:complexType>
1143	   	<!-- Conference Media Streams -->
1144	   	<xs:complexType name="ConferenceMediaStreams">
1145	   		<xs:sequence>
1146	   			<xs:element name="video" type="xs:string" minOccurs="0"/>
1147	   			<xs:element name="audio" type="xs:string" minOccurs="0"/>
1148	   			<xs:element name="message" type="xs:string" minOccurs="0"/>
1149	   			<xs:element name="text" type="xs:string" minOccurs="0"/>
1150	   			<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1151	   		</xs:sequence>
1152	   	</xs:complexType>
1153	   	<!-- Target  -->
1154	   	<xs:complexType name="Target">
1155	   		<xs:sequence>
1156	   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1157	   		</xs:sequence>
1158	   		<xs:attribute name="uri" type="xs:anyURI" use="required"/>
1159	   	</xs:complexType>
1160	   	<!-- Start/Stop time -->
1161	   	<xs:complexType name="StartStopTime">
1162	   		<xs:simpleContent>
1163	   			<xs:extension base="xs:dateTime">
1164	   				<xs:attribute name="required-participant" use="required">
1165	   					<xs:simpleType>
1166	   						<xs:restriction base="xs:string">
1167	   							<xs:enumeration value="key-participant"/>
1168	   							<xs:enumeration value="participant"/>
1169	   							<xs:enumeration value="none"/>
1170	   						</xs:restriction>
1171	   					</xs:simpleType>
1172	   				</xs:attribute>
1173	   			</xs:extension>
1174	   		</xs:simpleContent>
1175	   	</xs:complexType>
1176	   	<!-- Security Level -->
1177	   	<xs:simpleType name="SecurityLevel">
1178	   		<xs:restriction base="xs:string">
1179	   			<xs:enumeration value="none"/>
1180	   			<xs:enumeration value="low"/>
1181	   			<xs:enumeration value="medium"/>
1182	   			<xs:enumeration value="high"/>
1183	   		</xs:restriction>
1184	   	</xs:simpleType>
1185	   	<!-- Join Handling -->
1186	   	<xs:simpleType name="JoinHandling">
1187	   		<xs:restriction base="xs:string">
1188	   			<xs:enumeration value="block"/>
1189	   			<xs:enumeration value="allow"/>
1190	   			<xs:enumeration value="confirm"/>
1191	   		</xs:restriction>
1192	   	</xs:simpleType>
1193	   	<!-- Sidebar -->
1194	   	<xs:complexType name="Sidebar">
1195	   		<xs:sequence>
1196	   			<xs:element name="uri" type="xs:anyURI" maxOccurs="unbounded"/>
1197	   			<xs:element name="policy" type="xs:anyURI" minOccurs="0"/>
1198	   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1199	   		</xs:sequence>
1200	   		<xs:attribute name="id" type="xs:string" use="required"/>
1201	   	</xs:complexType>
1202	   </xs:schema>

1204	5.  Conference Policy Manipulation and Conference Entity Behaviour

1206	5.1  Overview of Operation

1208	   This document assumes that the user knows the location of conference
1209	   policy serve, the details of that discovery are beyond the scope of
1210	   this document.

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

1218	   Some assumptions about the conferencing architecture are made.
1219	   Clients always connect to the conference policy server (CPS) when
1220	   they perform manipulation operations.  It is assumed that the CPS
1221	   informs other conferencing entities, such as focus, the floor control
1222	   server and the mixer directly or via the focus.  For example, if user
1223	   A wants to expel user B from an ongoing conference, user A must first
1224	   manipulate the conference policy data.  The CPS then communicates
1225	   that change to the focus to perform the operation.

1227	   User privileges are defined in [19]

1229	5.2  Use of External Lists

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

1236	   A privileged user of the conference policy uses an external list by
1237	   placing its URI in an conference policy element that is dedicated to
1238	   carrying external list URIs.  The external list URI is the URI used
1239	   to manipulate the list and not the URI used to signal to the list.
1240	   There are three such elements documented in this memo: the
1241	   <external-list> element in the authorization rules (Section
1242	   4.3.4.1.2.4) and the <external> element in both, the dialout list
1243	   (Section 4.3.5) and the refer list (Section 4.3.6).  At the time the
1244	   focus needs to activate the policy surrounding the URI, the focus
1245	   fetches the URIs for the members of the external list using the list
1246	   URI.  For example, a conference creator creates a conference and
1247	   places the URI of an external list in the dial-out list.  At some
1248	   point, the focus needs to invite using on the dial-out list to join
1249	   the conference.  It is at that moment that the focus retrieves the
1250	   members of the external list.  It then sends INVITE (in SIP terms) to
1251	   the members of that external list.  This results in all participants
1252	   connected to one focus.

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

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

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

1267	5.3  Communication Between Conference Entities

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

1273	5.4  Manipulating Participant Lists

1275	   A user with sufficient privileges is allowed to perform user
1276	   management operations, such as adding a new user to the conference or
1277	   expelling a user from the conference.  These operations are performed
1278	   by modifying the conference policy at the conference policy server.
1279	   After authorising the user to do such manipulations, the conference
1280	   policy server communicates the change to the focus.  The focus reacts
1281	   by performing singlling operations such as sending SIP INVITE, BYE or
1282	   REFER.

1284	5.4.1  Expelling a Participant

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

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

1296	   	<rule id="1">
1297	   		<conditions>
1298	   			<identity>
1299	   				<domain>example.com</domain>
1300	   			</identity>
1301	   		</conditions>
1302	   		<actions>
1303	   			<join-handling>allow</join-handling>
1304	   		</actions>
1305	   		<transformations/>
1306	   	</rule>

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

1311	   	<rule id="2">
1312	   		<conditions>
1313	   			<identity>
1314	   				<uri>bob@example.com</uri>
1315	   			</identity>
1316	   		</conditions>
1317	   		<actions>
1318	   			<join-handling>block</join-handling>
1319	   		</actions>
1320	   		<transformations/>
1321	   	</rule>

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

1326	   	<rule id="1">
1327	   		<conditions>
1328	   			<identity>
1329	   				<domain>example.com</domain>
1330	   				<except>bob@domain.com</except>
1331	   			</identity>
1332	   		</conditions>
1333	   		<actions>
1334	   			<join-handling>allow</join-handling>
1335	   		</actions>
1336	   		<transformations/>
1337	   	</rule>

1339	5.5  Re-joining a Conference

1341	   Participants can drop out of a conference for many reasons including:
1342	   client crash, out of coverage, had to leave for a while.  It might be
1343	   of interest to enable that user to re-join the conference.  To allow
1344	   that, participants that have departed the conference gracefully can
1345	   only re-join if a privileged user has added an authorization rule
1346	   allowing them to join.  Participants that have departed the
1347	   conference ungracefully (eg: crash) require a special behaviour from
1348	   the focus .  The focus is aware when a user has not gracefully
1349	   departed a conference (for example; it did not receive a SIP BYE
1350	   request and media is no longer being received).  If this is the case,
1351	   the focus is required to re-issue the invitation or referral to that
1352	   user after a pre-configured unit of time.

1354	6.  Examples

1356	6.1  A Simple Conference Policy Document

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

1362	   <?xml version="1.0" encoding="UTF-8"?>
1363	   <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
1364	   	<settings>
1365	   		<conference-uri>sip:myconference@example.com</conference-uri>
1366	   	</settings>
1367	   	<dailout-list>
1368	   		<target uri="sip:bob@example.com"/>
1369	   		<target uri="sip:alice@example.com"/>
1370	   		<target uri="sip:john@example.com"/>
1371	   		<target uri="sip:robert@example.com"/>
1372	   	</dailout-list>
1373	   	<media-streams>
1374	   		<audio/>
1375	   	</media-streams>
1376	   </conference>

1378	6.2  A Complex Conference Policy Document

1380	   Alice creates a conference with the follows policy:

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

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

1387	   o  The security level for the conference is medium.

1389	   o  The conference allows sidebars

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

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

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

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

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

1407	   o  Alice is a key participant
1408	   o  Alice will be invited to join the conference while Sarah will be
1409	      referred to the conference.

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

1413	   The resulting CPCP document looks like

1415	   <?xml version="1.0" encoding="UTF-8"?>
1416	   <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
1417	   	<settings>
1418	   		<conference-uri>sip:myconference@example.com</conference-uri>
1419	   		<max-participant-count>10</max-participant-count>
1420	   		<allow-sidebars>true</allow-sidebars>
1421	   	</settings>
1422	   	<info xml:lang="en-us">
1423	   		<subject>What's happening tonight</subject>
1424	   		<display-name>Party Goer's</display-name>
1425	   		<free-text>John and Peter will join the conference soon</free-text>
1426	   		<keywords>party nightclub beer</keywords>
1427	   		<host-info>
1428	   			<uri>sip:Alice@example.com</uri>
1429	   			<uri>tel:+3581234567</uri>
1430	   			<e-mail>mailto:Alice@example.com</e-mail>
1431	   			<web-page>http://www.example.com/users/Alice</web-page>
1432	   		</host-info>
1433	   	</info>
1434	   	<time>
1435	   		<occurrence>
1436	   			<mixing-start-time required-participant="participant">2004-12-17T09:30:00-05:00</mixing-start-time>
1437	   			<mixing-stop-time required-participant="none">2004-12-17T12:30:00-05:00</mixing-stop-time>
1438	   			<can-join-after>2001-12-17T09:25:00-05:00</can-join-after>
1439	   			<must-join-before>2004-12-17T12:00:00-05:00</must-join-before>
1440	   			<request-users required-participant="none">2001-12-17T09:30:00-05:00</request-users>
1441	   		</occurrence>
1442	   	</time>
1443	   	<authorization-rules>
1444	   		<rule id="1">
1445	   			<conditions>
1446	   				<identity>
1447	   					<domain>example.com</domain>
1448	   				</identity>
1449	   			</conditions>
1450	   			<actions>
1451	   				<allow-conference-state>true</allow-conference-state>
1452	   				<join-handling>allow</join-handling>
1453	   			</actions>
1454	   			<transformations/>
1455	   		</rule>
1456	   		<rule id="2">
1457	   			<conditions>
1458	   				<identity>
1459	   					<id>alice@example.com</id>
1460	   				</identity>
1461	   			</conditions>
1462	   			<actions/>
1463	   			<transformations>
1464	   				<is-key-participant>true</is-key-participant>
1465	   			</transformations>
1466	   		</rule>
1467	   	</authorization-rules>
1468	   	<dailout-list>
1469	   		<target uri="sip:bob@example.com"/>
1470	   	</dailout-list>
1471	   	<refer-list>
1472	   		<target uri="sip:sarah@example.com"/>
1473	   	</refer-list>
1474	   	<media-streams>
1475	   		<video/>
1476	   		<audio/>
1477	   	</media-streams>
1478	   </conference>

1480	7.  Security Considerations

1482	   A conference document may contain information that is highly
1483	   sensitive.  Its delivery to the conference server needs to happen
1484	   strictly, paying special attention to integrity and confidentiality.
1485	   Reading the document is also a security concern since the conference
1486	   policy contains sensitive information like the topic of the
1487	   conference, who is allowed to join and the URIs of the users that can
1488	   participate.

1490	   Manipulations of the conference policy have similar security issues.
1491	   Users with relevant privileges can manipulate parts of the conference
1492	   policy giving themselves and others privileges to manipulate the
1493	   conference policy, including the dial-out list and the security level
1494	   settings for a conference.  This can happen because the conference
1495	   policy itself carries the identities and the authorization rules that
1496	   apply to those identities.  Those authorization rules carry the
1497	   privileges that certain identities have.  If an unauthorized user
1498	   gets access to this document (pretending to be someone else), s/he
1499	   can manipulate those rules giving himself and other unauthorized
1500	   users access to the conference policy.  S/he can also manipulate
1501	   other parts of the conference policy under a false identity.  Some of
1502	   the things that a malicious user can do include: denying users
1503	   certain privileges, giving himself floor moderation, removing users
1504	   from lists, removing rules for certain identities, giving privileges
1505	   to other malicious users, changing the media streams and changing
1506	   conference time.  Therefore, it is very important that only
1507	   authorized clients are able to manipulate the conference policy.  Any
1508	   conference policy transport protocol MUST provide authentication,
1509	   confidentiality and integrity.

1511	   In the case that XCAP is used to create and manipulate a conference
1512	   policy, the XCAP base specification mandates that all XCAP servers
1513	   MUST implement HTTP Authentication: Basic and Digest Access
1514	   Authentication [16].  Furthermore, XCAP servers MUST implement HTTP
1515	   over TLS [17].  It is recommended that administrators of XCAP servers
1516	   use an HTTPS URI as the XCAP root services URI, so that the digest
1517	   client authentication occurs over TLS.  By using these means, XCAP
1518	   client and server can ensure the confidentiality and integrity of the
1519	   XCAP created conference policy document  and its manipulation
1520	   operations, and that only authorized clients are allowed to perform
1521	   them.

1523	8.  IANA Considerations

1525	8.1  XCAP Application Usage ID

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

1530	   Name of the AUID: conference-policy
1531	   Description: Conference policy application manipulates conference
1532	   policy at a server.

1534	8.2  application/conference-policy+xml MIME TYPE

1536	   MIME media type: application

1538	   MIME subtype name: conference-policy+xml

1540	   Mandatory parameters: none

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

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

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

1551	   Interoperability considerations: none.

1553	   Published specification: This document.

1555	   Applications which use this media type: This document type has been
1556	   used to support conference policy manipulation for SIP based
1557	   conferencing.

1559	   Additional information:

1561	   Magic number: None

1563	   File extension: .cl or .xml

1565	   Macintosh file type code: "TEXT"

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

1570	   Intended Usage: COMMON

1572	   Author/change controller: The IETF

1574	8.3  URN Sub-Namespace Registration for
1575	    urn:ietf:params:xml:ns:conference-policy

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

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

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

1586	   XML:

1588	   BEGIN
1589	   <?xml version="1.0"?>
1590	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
1591	        "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
1592	   <html xmlns="http://www.w3.org/1999/xhtml">
1593	   <head>
1594	    <meta http-equiv="content-type"
1595	      content="text/html;charset=iso-8859-1"/>
1596	    <title>Conference Policy Namespace</title>
1597	   </head>
1598	   <body>
1599	     <h1>Namespace for Conference Policy</h1>
1600	     <h2>application/conference-policy+xml</h2>
1601	     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
1602	   </body>
1603	   </html>
1604	   END

1606	9.  Contributors

1608	      Jose Costa-Requena

1610	      Simo Veikkolainen

1612	      Teemu Jalava

1614	10.  Acknowledgements

1616	   The authors would like to thank Markus Isomaki, Adam Roach, Eunsook
1617	   Kim, Roni Evan, Alan Johnston, Hannes Tschofenig and the IETF XCON
1618	   working group for their feedback and suggestions.

1620	11.  References

1622	11.1  Normative References

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

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

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

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

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

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

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

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

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

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

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

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

1671	   [13]  Rosenberg, J., "A Framework for Conferencing with the Session
1672	         Initiation Protocol",
1673	         draft-ietf-sipping-conferencing-framework-01 (work in
1674	         progress), October 2003.

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

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

1682	   [16]  Franks, J., "HTTP Authentication: Basic and Digest Access
1683	         Authentication", RFC 2617, June 1999.

1685	   [17]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

1687	11.2  Informative References

1689	   [18]  Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars",
1690	         draft-rosen-xcon-conf-sidebars-00 (work in progress), July
1691	         2004.

1693	   [19]  Khartabil, H. and A. Niemi, "Privileges for Manipulating a
1694	         Conference Policy",
1695	         draft-ietf-xcon-conference-policy-privileges-00 (work in
1696	         progress), September 2004.

1698	   [20]  Jennings, C. and B. Rosen, "Media Mixer Control for XCON",
1699	         draft-jennings-xcon-media-control-00 (work in progress),
1700	         February 2004.

1702	   [21]  Handly, M., Eriksson, G., Jacobson, V. and C. Perkins,
1703	         "Grouping of Media Lines in SDP", draft-ietf-mmusic-sdp-new-18
1704	         (work in progress), June 2004.

1706	Authors' Addresses

1708	   Hisham Khartabil
1709	   Nokia
1710	   P.O. Box 321
1711	   Helsinki  FIN-00045
1712	   Finland

1714	   EMail: hisham.khartabil@nokia.com

1716	   Petri Koskelainen
1717	   Nokia
1718	   P.O. Box 100 (Visiokatu 1)
1719	   Tampere  FIN-33721
1720	   Finland

1722	   EMail: petri.koskelainen@nokia.com
1723	   Aki Niemi
1724	   Nokia
1725	   P.O. Box 100
1726	   NOKIA GROUP, FIN  00045
1727	   Finland

1729	   Phone: +358 50 389 1644
1730	   EMail: aki.niemi@nokia.com

1732	Intellectual Property Statement

1734	   The IETF takes no position regarding the validity or scope of any
1735	   Intellectual Property Rights or other rights that might be claimed to
1736	   pertain to the implementation or use of the technology described in
1737	   this document or the extent to which any license under such rights
1738	   might or might not be available; nor does it represent that it has
1739	   made any independent effort to identify any such rights.  Information
1740	   on the procedures with respect to rights in RFC documents can be
1741	   found in BCP 78 and BCP 79.

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

1750	   The IETF invites any interested party to bring to its attention any
1751	   copyrights, patents or patent applications, or other proprietary
1752	   rights that may cover technology that may be required to implement
1753	   this standard.  Please address the information to the IETF at
1754	   ietf-ipr@ietf.org.

1756	Disclaimer of Validity

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

1766	Copyright Statement

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

1772	Acknowledgment

1774	   Funding for the RFC Editor function is currently provided by the
1775	   Internet Society.