idnits 2.17.1 

draft-ietf-sipping-conference-package-11.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 on line 18.

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

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

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

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

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


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

     No issues found here.

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

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

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords. 

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
  -- 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 (June 5, 2005) is 6900 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)

  -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 2002

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

  ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566)

  ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226)

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

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

  ** Obsolete normative reference: RFC 3265 (ref. '10') (Obsoleted by RFC
     6665)

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

  -- Obsolete informational reference (is this intentional?): RFC 2326 (ref.
     '18') (Obsoleted by RFC 7826)

  == Outdated reference: A later version (-15) exists of
     draft-ietf-sip-gruu-03

  == Outdated reference: A later version (-06) exists of
     draft-ietf-sip-identity-05


     Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--).

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

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


2	SIPPING                                                     J. Rosenberg
3	Internet-Draft                                             Cisco Systems
4	Expires: December 7, 2005                                 H. Schulzrinne
5	                                                     Columbia University
6	                                                           O. Levin, Ed.
7	                                                   Microsoft Corporation
8	                                                            June 5, 2005

10	 A Session Initiation Protocol (SIP) Event Package for Conference State
11	                draft-ietf-sipping-conference-package-11

13	Status of this Memo

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

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

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

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

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

36	   This Internet-Draft will expire on December 7, 2005.

38	Copyright Notice

40	   Copyright (C) The Internet Society (2005).

42	Abstract

44	   This document defines a conference event package for the Session
45	   Initiation Protocol (SIP) Events framework, along with a data format
46	   used in notifications for this package.  The conference package
47	   allows users to subscribe to a conference URI.  Notifications are
48	   sent about changes in the membership of this conference and
49	   optionally about changes in the state of additional conference
50	   components.

52	Table of Contents

54	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
55	   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
56	   3.  Conference Event Package . . . . . . . . . . . . . . . . . . .  4
57	     3.1   Event Package Name . . . . . . . . . . . . . . . . . . . .  4
58	     3.2   Filtering  . . . . . . . . . . . . . . . . . . . . . . . .  5
59	     3.3   Subscription Duration  . . . . . . . . . . . . . . . . . .  5
60	     3.4   NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . .  5
61	     3.5   Notifier Processing of SUBSCRIBE Requests  . . . . . . . .  5
62	     3.6   Notifier Generation of NOTIFY Requests . . . . . . . . . .  6
63	     3.7   Subscriber Processing of NOTIFY Requests . . . . . . . . .  6
64	     3.8   Handling of Forked Requests  . . . . . . . . . . . . . . .  7
65	     3.9   Rate of Notifications  . . . . . . . . . . . . . . . . . .  7
66	     3.10  State Agents . . . . . . . . . . . . . . . . . . . . . . .  7
67	   4.  Conference Document  . . . . . . . . . . . . . . . . . . . . .  7
68	     4.1   Format . . . . . . . . . . . . . . . . . . . . . . . . . .  7
69	     4.2   Namespace  . . . . . . . . . . . . . . . . . . . . . . . .  7
70	     4.3   Versioning . . . . . . . . . . . . . . . . . . . . . . . .  7
71	     4.4   Partial Notifications Mechanism  . . . . . . . . . . . . .  8
72	     4.5   Element Keys . . . . . . . . . . . . . . . . . . . . . . .  8
73	     4.6   Constructing Coherent State Procedure  . . . . . . . . . .  9
74	   5.  Conference Data  . . . . . . . . . . . . . . . . . . . . . . . 11
75	     5.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
76	     5.2   <conference-info>  . . . . . . . . . . . . . . . . . . . . 13
77	     5.3   <conference-description> . . . . . . . . . . . . . . . . . 13
78	       5.3.1   <conf-uris>  . . . . . . . . . . . . . . . . . . . . . 14
79	       5.3.2   <service-uris> . . . . . . . . . . . . . . . . . . . . 15
80	       5.3.3   <maximum-user-count> . . . . . . . . . . . . . . . . . 15
81	       5.3.4   <available-media>  . . . . . . . . . . . . . . . . . . 15
82	     5.4   <host-info>  . . . . . . . . . . . . . . . . . . . . . . . 16
83	       5.4.1   <display-text> . . . . . . . . . . . . . . . . . . . . 16
84	       5.4.2   <web-page> . . . . . . . . . . . . . . . . . . . . . . 17
85	       5.4.3   <uris> . . . . . . . . . . . . . . . . . . . . . . . . 17
86	     5.5   <conference-state> . . . . . . . . . . . . . . . . . . . . 17
87	       5.5.1   <user-count> . . . . . . . . . . . . . . . . . . . . . 17
88	       5.5.2   <active> . . . . . . . . . . . . . . . . . . . . . . . 17
89	       5.5.3   <locked> . . . . . . . . . . . . . . . . . . . . . . . 17
90	     5.6   <users> and its <user> sub-elements  . . . . . . . . . . . 17
91	       5.6.1   <display-text> . . . . . . . . . . . . . . . . . . . . 18
92	       5.6.2   <associated-aors>  . . . . . . . . . . . . . . . . . . 18
93	       5.6.3   <roles>  . . . . . . . . . . . . . . . . . . . . . . . 19
94	       5.6.4   <languages>  . . . . . . . . . . . . . . . . . . . . . 19
95	       5.6.5   <cascaded-focus> . . . . . . . . . . . . . . . . . . . 19
96	       5.6.6   <endpoint> . . . . . . . . . . . . . . . . . . . . . . 19

98	     5.7   <endpoint> . . . . . . . . . . . . . . . . . . . . . . . . 20
99	       5.7.1   <display-text> . . . . . . . . . . . . . . . . . . . . 20
100	       5.7.2   <referred> . . . . . . . . . . . . . . . . . . . . . . 20
101	       5.7.3   <status> . . . . . . . . . . . . . . . . . . . . . . . 21
102	       5.7.4   <joining-method> . . . . . . . . . . . . . . . . . . . 22
103	       5.7.5   <joining-info> . . . . . . . . . . . . . . . . . . . . 22
104	       5.7.6   <disconnection-method> . . . . . . . . . . . . . . . . 23
105	       5.7.7   <disconnection-info> . . . . . . . . . . . . . . . . . 23
106	       5.7.8   <media>  . . . . . . . . . . . . . . . . . . . . . . . 24
107	       5.7.9   <call-info>  . . . . . . . . . . . . . . . . . . . . . 24
108	     5.8   <media>  . . . . . . . . . . . . . . . . . . . . . . . . . 24
109	       5.8.1   <display-text> . . . . . . . . . . . . . . . . . . . . 24
110	       5.8.2   <type> . . . . . . . . . . . . . . . . . . . . . . . . 24
111	       5.8.3   <label>  . . . . . . . . . . . . . . . . . . . . . . . 25
112	       5.8.4   <src-id> . . . . . . . . . . . . . . . . . . . . . . . 25
113	       5.8.5   <status> . . . . . . . . . . . . . . . . . . . . . . . 25
114	     5.9   Sidebars . . . . . . . . . . . . . . . . . . . . . . . . . 25
115	       5.9.1   <sidebars-by-ref>  . . . . . . . . . . . . . . . . . . 26
116	       5.9.2   <sidebar-by-val> . . . . . . . . . . . . . . . . . . . 26
117	   6.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 26
118	   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
119	     7.1   Basic Example  . . . . . . . . . . . . . . . . . . . . . . 34
120	     7.2   Rich Example . . . . . . . . . . . . . . . . . . . . . . . 36
121	   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
122	     8.1   Connection Security  . . . . . . . . . . . . . . . . . . . 40
123	     8.2   Authorization Considerations . . . . . . . . . . . . . . . 40
124	   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 41
125	     9.1   conference Event Package Registration  . . . . . . . . . . 41
126	     9.2   application/conference-info+xml MIME Registration  . . . . 41
127	     9.3   URN Sub-Namespace Registration for
128	           urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 42
129	     9.4   XML Schema Registration  . . . . . . . . . . . . . . . . . 43
130	     9.5   URI Purposes Sub-registry Establishment  . . . . . . . . . 43
131	   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
132	   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 44
133	     11.1  Normative References . . . . . . . . . . . . . . . . . . . 44
134	     11.2  Informative References . . . . . . . . . . . . . . . . . . 46
135	       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
136	       Intellectual Property and Copyright Statements . . . . . . . . 48

138	1.  Introduction

140	   The Session Initiation Protocol (SIP) Events Framework [10] defines
141	   general mechanisms for subscribing to, and receiving notifications
142	   of, events within SIP networks.  It introduces the notion of a
143	   package, which is a specific "instantiation" of the events framework
144	   for a well-defined set of events.  Here, we define an event package
145	   for SIP conferences.  This package provides the conference
146	   notification service as outlined in the SIP conferencing framework
147	   [16].  As described there, subscriptions to a conference URI are
148	   routed to the focus that is handling the conference.  It acts as the
149	   notifier, and provides clients with updates on conference state.

151	   The information provided by this package is comprised of conference
152	   identifier(s), conference participants (optionally with their
153	   statuses and media description), conference sidebars, conference
154	   service URIs, etc.

156	2.  Terminology

158	   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
159	   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
160	   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
161	   indicate requirement levels for compliant implementations.

163	3.  Conference Event Package

165	   The conference event package allows a user to subscribe to a
166	   conference.  In SIP, conferences are represented by URIs.  These URIs
167	   route to a SIP user agent, called a focus, that is responsible for
168	   ensuring that all users in the conference can communicate with each
169	   other, as described in Conferencing Framework [16].  The focus has
170	   sufficient information about the state of the conference to inform
171	   subscribers about it.

173	   It is possible that a participant in the conference may in fact be
174	   another focus.  In order to provide a more complete participant list,
175	   the focus MAY subscribe to the conference package of the other focus
176	   to discover the participant list in the cascaded conference.  This
177	   information can then be included in notifications by use of the
178	   <cascaded-focus> element as specified by this package.

180	   This section provides the details for defining a SIP-specific event
181	   notification package, as specified by RFC 3265 [10].

183	3.1  Event Package Name

185	   The name of this event package is "conference".  This package name is
186	   carried in the Event and Allow-Events header, as defined in RFC 3265
187	   [10].

189	3.2  Filtering

191	   Filters to conference subscriptions are a desirable feature, which
192	   can be considered as a subject of future standardization activities.
193	   This document does not define the filters for the conference package
194	   to be included in the SUBSCRIBE body.

196	   A SUBSCRIBE for a conference package, being sent without a body,
197	   implies the default subscription filtering policy.  The default
198	   policy is:
199	   o  Notifications are generated every time there is any change in the
200	      state of the conference.
201	   o  Notifications do not normally contain full state; rather, they
202	      only indicate the state that has changed.  The exception is a
203	      NOTIFY sent in response to a SUBSCRIBE.  These NOTIFYs contain the
204	      full state of the information requested by the subscriber.

206	3.3  Subscription Duration

208	   The default expiration time for a subscription to a conference is one
209	   hour.  Once the conference ends, all subscriptions to that particular
210	   conference are terminated, with a reason of "noresource" as defined
211	   in RFC 3265 [10].

213	3.4  NOTIFY Bodies

215	   According to RFC 3265 [10], the NOTIFY message will contain bodies
216	   that describe the state of the subscribed resource.  This body is in
217	   a format listed in the Accept header field of the SUBSCRIBE, or a
218	   package-specific default if the Accept header field was omitted from
219	   the SUBSCRIBE.

221	   In this event package, the body of the notification contains a
222	   conference information document that describes the state of a
223	   conference.  All subscribers and notifiers MUST support the
224	   "application/conference-info+xml" data format described in Section 5.
225	   By default, i.e. if no Accept header is specified to a SUBSCRIBE
226	   request, the NOTIFY will contain a body in the "application/
227	   conference-info+xml" data format.  If the Accept header field is
228	   present, it MUST include "application/conference-info+xml" and MAY
229	   include any other types.

231	3.5  Notifier Processing of SUBSCRIBE Requests

233	   The conference information contains very sensitive information.

235	   Therefore, all subscriptions SHOULD be authenticated and then
236	   authorized before approval.  Authorization policy is at the
237	   discretion of the administrator, as always.

239	   However, it is RECOMMENDED that all users in the conference be
240	   allowed to subscribe to the conference event package.

242	3.6  Notifier Generation of NOTIFY Requests

244	   Notifications SHOULD be generated for the conference state when a new
245	   participant joins (i.e. gets "connected" to) or a participant leaves
246	   (i.e. gets "disconnected" from) the conference.

248	   Subject to a local focus policy, additional changes in participants'
249	   status, changes in their media types, and other optional information
250	   MAY be reported by the focus.

252	   Changes in sidebar rosters SHOULD be reported by the focus to their
253	   participants and MAY be reported to others, subject to local policy.

255	   Changes in conference identifiers and service URIs SHOULD be reported
256	   by the focus to the Conference package subscribers.

258	   Changes in other conference state information MAY be reported by the
259	   focus to the Conference package subscribers.

261	3.7  Subscriber Processing of NOTIFY Requests

263	   The SIP Events framework expects packages to specify how a subscriber
264	   processes NOTIFY requests in any package specific ways, and in
265	   particular, how it uses the NOTIFY requests to construct a coherent
266	   view of the state of the subscribed resource.

268	   Typically, the NOTIFY for the conference package will only contain
269	   information about those users whose state in the conference has
270	   changed.  To construct a coherent view of the total state of all
271	   users, a subscriber to the conference package will need to combine
272	   NOTIFYs received over time.

274	   Notifications within this package can convey partial information;
275	   that is, they can indicate information about a subset of the state
276	   associated with the subscription.  This means that an explicit
277	   algorithm needs to be defined in order to construct coherent and
278	   consistent state.  The details of this mechanism are specific to the
279	   particular document type.  See Section 4.6 for information on
280	   constructing coherent information from an application/
281	   conference-info+xml document.

283	3.8  Handling of Forked Requests

285	   By their nature, the conferences supported by this package are
286	   centralized.  Therefore, SUBSCRIBE requests for a conference should
287	   not generally fork.  Users of this package MUST NOT install more than
288	   a single subscription as a result of a single SUBSCRIBE request.

290	3.9  Rate of Notifications

292	   For reasons of congestion control, it is important that the rate of
293	   notifications not become excessive.  As a result, it is RECOMMENDED
294	   that the server doesn't generate notifications for a single
295	   subscriber at a rate faster than once every 5 seconds.

297	3.10  State Agents

299	   Conference state is ideally maintained in the element in which the
300	   conference resides.  Therefore, a conference focus is the best suited
301	   element to handle subscriptions to it.  Cascaded foci MAY implement
302	   state agents (as defined in RFC 3265 [10]) for this package.

304	4.  Conference Document

306	4.1  Format

308	   Conference information is an XML document that MUST be well-formed
309	   and valid.  It MUST be based on Extensible Markup Language (XML) 1.0
310	   and MUST be encoded using UTF-8 [14].

312	4.2  Namespace

314	   This specification makes use of XML namespaces for identifying
315	   conference information documents and document fragments.  The
316	   namespace URI for elements defined by this specification is a URN
317	   [2], using the namespace identifier 'ietf' defined by [6] and
318	   extended by RFC 3688 [21].  This URN is:

320	   urn:ietf:params:xml:ns:conference-info

322	4.3  Versioning

324	   The conference information is described by a hierarchal XML structure
325	   with the root element <conference-info>.  The root element is the
326	   only element in the schema that carries meaningful version number for
327	   all the elements in the document.  The whole conference information
328	   is associated with this version number.

330	   The 'version' attribute MUST be included in the root <conference-
331	   info> element.

333	4.4  Partial Notifications Mechanism

335	   This specification defines a basic partial notifications mechanism by
336	   using a 'state' attribute as described below.  This mechanism MUST be
337	   supported by all subscribing clients.  Additional general partial
338	   notifications mechanisms can be defined and applied to this package
339	   in the future.

341	   All sub-elements in the <conference-info> hierarchal XML structure
342	   can be classified in two groups: permissible for partial
343	   notifications or not.  Elements that carry a substantial amount of
344	   data that is subject to frequent changes are permissible for partial
345	   notifications and have a 'state' attribute attached to them.  All
346	   future extensions to this schema MUST define which extension elements
347	   can also use this mechanism.  All other elements can be updated as
348	   atomic pieces of data only.

350	   Below is the complete list of elements permissible to use the partial
351	   notifications mechanism defined in this specification.  (Note that
352	   future partial notifications mechanisms can potentially be applicable
353	   to additional elements.)

355	   o  Element <conference-info>
356	   o  Element <users>
357	   o  Element <user>
358	   o  Element <endpoint>
359	   o  Element <sidebars-by-val>
360	   o  Element <sidebars-by-ref>

362	   The 'state' attribute value indicates whether the reported
363	   information about the element is "full", "partial" or the element is
364	   "deleted" from the conference state document.  The default value of
365	   any 'state' attribute is "full".

367	   A 'state' attribute of a child element in the document MUST be
368	   consistent with its parent 'state'.  This means that if the parent's
369	   'state' is "full", the state of its children MUST be "full".  If the
370	   parent's 'state' is "partial", the state of its children MAY be
371	   either "partial", "full", or "deleted".  A parent element with
372	   "deleted" 'state' SHOULD NOT contain child elements.  Any information
373	   provided for child elements of a "deleted" parent MUST be ignored by
374	   the package subscriber.

376	4.5  Element Keys

378	   The defined XML schema has a property of unique identification among
379	   sub-elements of a common parent, which makes it possible to use the
380	   partial notifications mechanism defined in this document.  This
381	   property is achieved by defining a key to each sub-element that can
382	   appear multiple times under the common parent.

384	   In the context of this specification, the element key is the set of
385	   mandatory attributes or sub-elements of an element.  The key value
386	   MUST be unique for the element among its siblings of the same type.

388	   In the context of this specification, the comparison rules for keys
389	   of type xs:anyURI are byte-by-byte (including all URI parameters that
390	   can be included with the URI).

392	   Below is the list of elements (subject to partial notifications of
393	   their parent elements) with their keys as defined by this
394	   specification:

396	   o  Element <user> uses as the key 'entity'
397	   o  Element <endpoint> uses as the key 'entity'
398	   o  Element <media> uses as the key 'id'
399	   o  Element <entry> (child to <sidebars-by-val>) uses as the key
400	      'entity'
401	   o  Element <sidebars-by-ref> uses as the key <uri>

403	4.6  Constructing Coherent State Procedure

405	   This section describes the algorithm for constructing a coherent
406	   conference state by a subscriber to the conference package.  Using
407	   software programming abstraction, the subscriber maintains a single
408	   local version number for the whole conference document and a local
409	   element instance for each element in the schema.  Also, for each
410	   element with keys (as defined above), the subscriber maintains a
411	   virtual table with a row for each existing key value.

413	   The first time a NOTIFY with a "full" document is received (as
414	   indicated by the value of the 'state' attribute in the <conference-
415	   info> element), the conference package subscriber MUST set the local
416	   'version' number to the value of the 'version' attribute from the
417	   received <conference-info> and populate local data with the received
418	   information.

420	   Each time a new NOTIFY is received, the value of the local version
421	   number and the value of the 'version' attribute in the new received
422	   document are compared.  If the value in the document is equal or less
423	   than the local version, the document is discarded without processing.

425	   Otherwise, if the received NOTIFY contains a "full" or "deleted"
426	   state, the conference package subscriber MUST set the local 'version'
427	   number to the value of the 'version' attribute from the received
428	   <conference-info> and replace the local information with the received
429	   document.  Receiving "deleted" state for the <conference-info>
430	   element means that the conference has ceased to exist and the
431	   subscriber SHOULD terminate the subscription by sending the SUBSCRIBE
432	   with Expires = 0.

434	   Otherwise (i.e. if the received NOTIFY contains "partial" state), if
435	   the 'version' number in the received document is more than one number
436	   higher than the previous local version number, the subscriber MUST
437	   generate a subscription refresh request to trigger a full state
438	   notification.  If the 'version' number in the document is one higher
439	   than the local version number, the local version number is updated
440	   accordingly and the document is used to update the local content as
441	   described below.

443	   For each sub-element of the <conference-info> element in the received
444	   document,

446	   1.  If the element contains "full" state, the whole local element
447	   content is flushed and repopulated from the document.

449	   2.  Otherwise, if the element contains "deleted" state, the whole
450	   element MUST be removed from the local content.

452	   3.  Otherwise, if the element contains "partial" state:

454	   3.1 For elements with keys, the subscriber compares the keys received
455	   in the update with the keys in the local tables.

457	   3.1.1 If a key does not exist in the local table, a row is added, and
458	   its content is set to the element information from the update.

460	   3.1.2 Otherwise, if a key of the same value does exist, for each sub-
461	   element in the row the algorithm is applied from step 3.2.

463	   3.2 For each atomic element received in the schema, the element is
464	   replaced with the new information as a whole.  For each non-atomic
465	   element received in the schema with either no 'state' attribute
466	   included or the state attribute is set to "full", the element is
467	   replaced with the new information as a whole.  Also, for each element
468	   with the state attribute set to "deleted", the whole element is
469	   removed from the local content.

471	   3.3 For each non-atomic element with the state attribute set to
472	   "partial", the algorithm is applied recursively starting from step
473	   3.1.

475	5.  Conference Data

477	5.1  Overview

479	   The <conference-info> document format is designed to convey
480	   information about the conference and about participation in the
481	   conference.  The following non-normative diagram gives an example of
482	   the overall hierarchy used in this format.  Conferences contain users
483	   who can be represented by multiple endpoints, each of which can have
484	   multiple media streams.  Conferences can also include or reference
485	   "sidebar conferences".  When sidebar information is incorporated into
486	   a conference information document in a <sidebar-by-value> element,
487	   each <entry> element represents a sidebar and can include any sub-
488	   elements permitted in the <conference-info> top-level element.

490	   conference-info
491	     |
492	     |-- conference-description
493	     |
494	     |-- host-info
495	     |
496	     |-- conference-state
497	     |
498	     |-- users
499	     |    |-- user
500	     |    |    |-- endpoint
501	     |    |    |    |-- media
502	     |    |    |    |-- media
503	     |    |    |    |-- call-info
504	     |    |    |
505	     |    |    |-- endpoint
506	     |    |         |-- media
507	     |    |-- user
508	     |         |-- endpoint
509	     |              |-- media
510	     |
511	     |-- sidebars-by-ref
512	     |    |-- entry
513	     |    |-- entry
514	     |
515	     |-- sidebars-by-val
516	          |-- entry
517	          |    |-- users
518	          |         |-- user
519	          |         |-- user
520	          |-- entry
521	               |-- users
522	                    |-- user
523	                    |-- user
524	                    |-- user

526	   In most cases, this document doesn't mandate how the information,
527	   presented through the conference document to the subscribers, is
528	   obtained by the focus.  In many cases, the information can be
529	   dynamically learned from the call signaling and also be manually
530	   populated by an administrator - all subject to local policies.  This
531	   document specifies what the XML elements mean in order to allow the
532	   subscribers to appropriately interpret it.  Some portions of the
533	   information are intended for automata processing, others - for human
534	   consumption only.  For example, the <display-text> sub-elements of
535	   elements <conf-uris>, <service-uris>, <available-media>, <host-info>,
536	   <endpoint>, and <media> are intended for display to human subscribers
537	   only.

539	   Following sections describe the XML schema in more details.

541	5.2  <conference-info>

543	   A conference information document begins with the root element tag
544	   <conference-info> of conference-type.

546	   The following attributes are defined for <conference-info>:

548	   entity: This attribute contains the conference URI that identifies
549	      the conference being described in the document.  This is the SIP
550	      URI that an interested entity needs to SUBSCRIBE to in order to
551	      get the conference package information.  Note that this URI can be
552	      listed as one of the URIs to be used in order to access the
553	      conference by SIP means and in accordance with  Section 5.3.1
554	      below.

556	   state: This attribute indicates whether the document contains the
557	      whole conference information ("full"), only the information that
558	      has changed since the previous document ("partial"), or the
559	      conference ceased to exist ("deleted").  For more detail see
560	      Section 4.

562	   version: This attribute allows the recipient of conference
563	      information documents to properly order them and it MUST be
564	      included when used in the root <conference-info> element.  Version
565	      number is a 32 bit monotonically increasing integer scoped within
566	      a subscription.  A server MUST increment the version number by one
567	      for each new partial notification being sent to a subscriber.

569	   The <conference-info> element is comprised of <conference-
570	   description>, <host-info>, <conference-state>, <users>, <sidebar-by-
571	   ref> and <sidebars-by-val> child elements.  A "full" conference
572	   document MUST at least include the <conference-description> and
573	   <users> child elements.

575	   Following sections describe these elements in detail.  The full XML
576	   schema is provided in Section 6.

578	5.3  <conference-description>

580	   The <conference-description> element describes the conference as a
581	   whole.

583	   The child elements <display-text>, <subject>, <free-text>, and
584	   <keywords> are used to describe the conference content:

586	   <display-text>: Contains descriptive text suitable for human
587	      consumption, for example, listing in a directory

589	   <subject>: Contains the subject of the conference

591	   <free-text>: Contains an additional longer description of the
592	      conference

594	   <keywords>: Contains a list of space-separated string tokens that can
595	      be used by search engines to better classify the conference

597	   Additional child elements <conf-uris> and <service-uris> are used to
598	   describe the conference-related URIs; <maximum-user-count> and
599	   <available-media> are used to describe the overall characteristics.

601	   This information is typically derived from the system conference
602	   policies, is set before the conference activation, and is rarely
603	   changed during the conference lifetime.

605	   The following sections describe the remaining elements in more
606	   detail.  Other sub-elements can extend <conference-description> in
607	   the future.

609	5.3.1  <conf-uris>

611	   This element contains a sequence of <entry> child elements - each
612	   containing the URI to be used in order to access the conference by
613	   different signaling means.  The value of the URI MUST be unique in
614	   the conference context and is included in the <uri> sub-element.

616	   Each <entry> can contain additional optional information useful to
617	   the participant when accessing the conference.

619	   An <entry> element MAY contain the <display-text> sub-element that
620	   provides a textual description meant for human consumption.

622	   Each <entry> element SHOULD contain a <purpose> sub-element that
623	   describes what happens when accessing the URI.  The currently defined
624	   <purpose> values to be used with the <conf-uris> are:

626	   participation: Accessing a URI with this <purpose> will bring the
627	      party into the conference
628	   streaming: Accessing a URI with this <purpose> will commence
629	      streaming the conference, but not allow active participation

631	   Examples of suitable URI schemes include sip: and sips: [8], xmpp:
632	   [22], h323: [20], and tel: [19] URIs.  The rtsp [18] URI is suitable
633	   for streaming.

635	   Future extensions to this schema may define new values and register
636	   them with IANA under the registry established by this specification.

638	5.3.2  <service-uris>

640	   This element describes auxiliary services available for the
641	   conference.  Like <conference-uris>, this element contains a set of
642	   <entry> child elements - each containing the URI to be used in order
643	   to access different services available for the particular conference.
644	   The value of the URI MUST be unique in the conference context and is
645	   included in the <uri> sub-element.

647	   An <entry> element MAY contain the <display-text> sub-element that
648	   provides a textual description meant for user consumption.

650	   Each <entry> element SHOULD contain a <purpose> sub-element.  The
651	   currently defined <purpose> values to be used with the <service-uris>
652	   are:

654	   web-page: Indicates the web page containing the additional
655	      information about the conference
656	   recording: Indicates the link at which the recorded conference
657	      context can be retrieved
658	   event: Indicates the URI at which a subscription to the conference
659	      event package may be requested.  This would typically be the
660	      conference URI of the main conference

662	   Future extensions to this schema may define new values and register
663	   them with IANA under the registry established by this specification.

665	5.3.3  <maximum-user-count>

667	   The value of this element provides a hint to the recipient of the
668	   conference document about the number of users that can be invited to
669	   the conference.  Typically, this value represents the overall number
670	   of users allowed to join the conference by different means as
671	   published through the conference document in <conf-uris>.  Note that
672	   this value is set by an administrator and can reflect any local
673	   policies combination such as network consumption, CPU processing
674	   power, and licensing rules.

676	5.3.4  <available-media>

678	   This element contains a sequence of <entry> child elements of
679	   conference-medium-type, each being indexed by the attribute 'label'.

681	   The 'label' attribute is the media stream identifier being assigned
682	   by the conferencing server such as its value is unique in the
683	   <conference-info> context.  If a corresponding media stream between a
684	   participant and a focus is established using the Session Description
685	   Protocol  (SDP) [3] and the SDP "label" media attribute defined in
686	   [17], the value of the SDP "label" attribute MUST be equal to the
687	   value of the 'label' attribute in <available-media>.

689	   Each <entry> describes a single media stream available to the
690	   participants in the conference and contains the following
691	   information:

693	   <display-text> This element contains the display text for the media
694	      stream.

696	   <type> This element contains the media type of the media stream.  The
697	      value of this element MUST be one of the values registered for
698	      "media" of SDP [3] and its later revision(s).  For example:
699	      "audio", "video", "text", and "message".

701	   <status> This element indicates the available status of the media
702	      stream available to the conference participants.  For example,
703	      this would be the status of the media stream, which would be
704	      offered by the focus, in a 'dial-out' scenario.  Using normal SIP
705	      offer answer mechanisms (being defined in RFC 3264 [9])in both
706	      dial-in and dial-out scenarios, a participant can of course
707	      establish only a subset of the available stream (i.e., request or
708	      accept the stream in one direction only, if both directions are
709	      available).  The valid values are "sendrecv", "sendonly",
710	      "recvonly", or "inactive" as defined in SDP [3] and its later
711	      revision(s).  (Note that the value specifies the direction from
712	      the participants' point of view.)

714	5.4  <host-info>

716	   This element contains information about the entity hosting the
717	   conference.  This information is set before the conference
718	   activation, and is rarely changed during the conference lifetime,
719	   unless the whole conference is moved to be hosted by another entity.
720	   The host information is comprised of the following elements:

722	5.4.1  <display-text>

724	   This element contains display text describing the entity hosting the
725	   conference.

727	5.4.2  <web-page>

729	   This element contains a URI of a web page describing either the
730	   conference service or the user hosting the conference.

732	5.4.3  <uris>

734	   This element can contain URIs pointing to the conference host, in
735	   addition to the conference URI.

737	5.5  <conference-state>

739	   By including this element in the conference document, the server can
740	   inform the subscribers about the changes in the overall conference
741	   information.  The <conference-state> child elements are described
742	   below.

744	5.5.1  <user-count>

746	   The value of this element tells the recipient of the conference
747	   document the overall number of users participating in the conference
748	   at a certain moment.  Typically this value represents the overall
749	   number of users who joined the conference by different means as
750	   published through the conference document in <conf-uris>.  Note that
751	   this number does not necessarily need to match and MAY exceed the
752	   number of the entries in the <users> container.  For example, in
753	   lecturing scenario a large conference notifications may not include
754	   every participant in the <users> element, but instead report only the
755	   panelists or the speakers.

757	5.5.2  <active>

759	   This Boolean element indicates whether the conference is currently
760	   active or not.  A conference is active if calling one of the <conf-
761	   uris> by an authorized client results in successful establishment of
762	   a signaling session between the client and the focus and a successful
763	   joining of the conference.

765	5.5.3  <locked>

767	   This Boolean element says whether the conference is currently locked
768	   or not.  In this context, "locked" means that the conference roster
769	   can not be added to (although participants may leave or be removed
770	   from the conference).

772	5.6  <users> and its <user> sub-elements

774	   The <users> element is a container of <user> child elements, each
775	   describing a single participant in the conference.

777	   The following attributes are defined for <user> element:

779	   entity: This attribute contains the URI for the user in the
780	      conference.  This is a logical identifier, which corresponds to
781	      the call signaling authenticated identity of the participant.  The
782	      'entity' value MUST be unique among all participants in the
783	      conference.  If for some participants, the focus decides to not
784	      reveal this information (due to local policies or security
785	      reasons, for example), the host portion of the user URI MUST use
786	      the .invalid top level domain (TLD) according to definitions of
787	      RFC 2606 [5].  The focus also MUST construct the user portion of
788	      the URI so that the URI is unique among all participants of the
789	      same domain.  For example, the convention

791	          "AnonymousX" <sip:anonymousX@anonymous.invalid>

793	      SHOULD be used for a participant requesting privacy in accordance
794	      with the guidelines for generating anonymous URIs of RFC 3323
795	      [11].  Note that in a different case, such as when used in
796	      conjunction with Enhancements for Authenticated Identity
797	      Management in SIP [25], the following convention can be used:

799	          "AnonymousX" <sip:anonymousX@example.com>

801	   state: This attribute indicates whether the document contains the
802	      whole user information ("full"), only the information that has
803	      changed since the previous document ("partial"), or the user was
804	      removed from the conference ("deleted").

806	   The following child elements are defined for <user> element:

808	5.6.1  <display-text>

810	   This element is used to display the user friendly name in the
811	   conference.

813	5.6.2  <associated-aors>

815	   This element contains additional (to the 'entity') URIs being
816	   associated with the <user>.  Typically, this information will be
817	   manually provided by an administrator showing the logical association
818	   between signaling entities otherwise independent.  For example, if
819	   the 'entity' of a <user> contains a GRUU Globally Routable User URI
820	   [24] or tel: URI RFC 3966 [19], it would be useful to populate this
821	   field with the AOR of the person, who uses these devices, each
822	   represented as an independent <user>.

824	5.6.3  <roles>

826	   This element can contain a set of human readable strings describing
827	   the roles of the user in the conference.  Note that this information
828	   is applicable for human consumption only.  This specification doesn't
829	   define the set of possible conferencing roles nor the semantics
830	   associated with each.  It is expected that future conferencing
831	   specifications will define these and the corresponding schema
832	   extensions, as appropriate.

834	5.6.4  <languages>

836	   This element contains a list of tokens, separated by spaces, each
837	   containing a language understood by the user.  This information can
838	   be automatically learned via call signaling or be manually set per
839	   participant.

841	5.6.5  <cascaded-focus>

843	   This element contains a conference URI (different from the main
844	   conference URI) for users that are connected to the main conference
845	   as a result of focus cascading.  In accordance with the SIP
846	   conferencing framework [16], this package allows for representation
847	   of peer-to-peer (i.e. "flat") focus cascading only.  The actual
848	   cascading graph can not be deduced from the information provided in
849	   the package alone.  Advanced applications can construct the graph by
850	   subscribing to both this package and the Dialog Package [23] of each
851	   cascaded focus and correlating the relevant information.

853	5.6.6  <endpoint>

855	   By including one or more <endpoint> elements under a parent <user>
856	   element, the server can provide the desired level of detail
857	   (including the state, media streams, and access information) about
858	   the user's devices and signaling sessions taking part in the
859	   conference.

861	   In a conferencing system where authentication is performed per
862	   endpoint (rather than per user), the focus can be unaware of the
863	   logical association of multiple endpoints under a common user.  In
864	   this case, each endpoint will appear as a separate <user> with its
865	   own <endpoint> sub-element(s) in the conference document.

867	   In a different case, the focus may choose to shield the information
868	   about the participant's multiple endpoints and signaling sessions
869	   from other subscribers altogether (due to privacy policies, for
870	   example).  To do so, the focus MAY aggregate the multiple signaling
871	   sessions' information under a single <endpoint> element.  Note that
872	   in this case, the detailed call signaling information (represented by
873	   <call-info> sub-element) will not be included.

875	5.7  <endpoint>

877	   This section describes the <endpoint> element in more detail.

879	   The following attributes are defined for <endpoint> element:

881	   entity: The server MUST generate the 'entity' key for each <endpoint>
882	      element included under the parent <user>, such as its value is
883	      unique in the user context.  In SIP terms, this can be the Contact
884	      URI, GRUU, etc.

886	   state: This attribute indicates whether the element contains the
887	      whole endpoint information ("full"), only the information that has
888	      changed since the previous document ("partial"), or the endpoint
889	      has been removed from the conference ("deleted").

891	   The following child elements are defined for <endpoint> element:

893	5.7.1  <display-text>

895	   This element contains the display text for the endpoint.

897	5.7.2  <referred>

899	   This element contains information about the user who's action
900	   resulted in this endpoint being brought into the conference (e.g. the
901	   SIP user identified by this URI sent a REFER to the focus).  It can
902	   contain the following sub-elements:

904	   when: This element of the XML dateTime type contains the date and
905	      time that the endpoint was referred to the conference and SHOULD
906	      be expressed in Coordinated Universal Time (UTC) format.  For
907	      example,

909	        <when>2005-03-04T20:00:00Z</when>

911	   reason: This element contains the reason the endpoint was referred to
912	      the conference.  It is RECOMMENDED to include the information in
913	      the format defined by RFC 3326 [12].  For example,

915	   <reason>Reason: SIP;text="Ad-hoc Invitation"</reason>
916	   by: This element contains the URI of the entity who caused the
917	      endpoint to be referred to the conference.  In SIP case, it will
918	      be populated from the Referred-By header defined in RFC 3892 [15].

920	5.7.3  <status>

922	   This element contains the status of the endpoint, and can assume the
923	   following values:

925	   connected: The endpoint is a participant in the conference.
926	      Depending on the media policies, he/she can send and receive media
927	      to and from other participants.

929	   disconnected: The endpoint is not a participant in the conference and
930	      no active dialog exists between the endpoint and the focus.

932	   on-hold: Active signaling dialog exists between an endpoint and a
933	      focus, but endpoint is "on-hold" for this conference, i.e. he/she
934	      is neither "hearing" the conference mix, nor is his/her media
935	      being mixed in the conference.  As an example, the endpoint has
936	      asked to join the conference using SIP, but his/her participation
937	      is pending based on moderator approval.  In the meantime he/she is
938	      hearing music-on-hold or some other kind of related content.

940	   muted-via-focus: Active signaling dialog exists between an endpoint
941	      and a focus and the endpoint can "listen" to the conference, but
942	      endpoint's media is not being mixed into the conference.  Note
943	      that sometimes a subset of endpoint media streams can be muted by
944	      focus (such as poor quality video) while others (such as voice or
945	      IM) can still be active.  In this case, it is RECOMMENDED that the
946	      "aggregated" endpoint connectivity <status> reflects the status of
947	      the most active media.

949	   pending: Endpoint is not yet in the session, but it is anticipated
950	      that he/she will join in the near future.

952	   alerting: A PSTN ALERTING or SIP 180 Ringing was returned for the
953	      outbound call, endpoint is being alerted.

955	   dialing-in: Endpoint is dialing into the conference, not yet in the
956	      roster (probably being authenticated).

958	   dialing-out: Focus has dialed out to connect the endpoint to the
959	      conference, but the endpoint is not yet in the roster (probably
960	      being authenticated).

962	   disconnecting: Focus is in the process of disconnecting the endpoint
963	      (e.g., in SIP a DISCONNECT or BYE was sent to the endpoint).

965	   Note that the defined transient statuses (e.g., disconnecting,
966	   alerting, etc.) could generate a lot of traffic.  Therefore
967	   implementations MAY choose to generate notifications on these
968	   statuses to certain participants only or not generate them at all,
969	   subject to local policy.

971	5.7.4  <joining-method>

973	   This element contains method by which the endpoint joined the
974	   conference, and can assume the following values:

976	   dialed-in: The endpoint dialed into the conference (e.g., in SIP sent
977	      INVITE to the focus), which resulted in successful dialog
978	      establishment.

980	   dialed-out: The focus has brought the endpoint into the
981	      conference(e.g., in SIP the focus sent a successful INVITE to the
982	      endpoint).

984	   focus-owner: The endpoint is the focus for this conference.  This
985	      status is used only when a participant's UA acts as a conference
986	      focus.

988	5.7.5  <joining-info>

990	   This element contains information about how the endpoint joined and
991	   can contain the following sub-elements:

993	   when: This element of the XML dateTime type contains the date and
994	      time that the endpoint joined the conference and SHOULD be
995	      expressed in Coordinated Universal Time (UTC).

997	   reason: This element contains the reason the endpoint joined the
998	      conference.  It is RECOMMENDED to include the information in the
999	      format defined by RFC 3326 [12].  For example,

1001	   <reason>Reason: SIP;text="Ad-hoc Invitation"</reason>

1003	   by: This element contains the URI of the entity who caused the
1004	      endpoint to join the conference.

1006	5.7.6  <disconnection-method>

1008	   This element contains the method by which the endpoint departed the
1009	   conference, and can assume the following values:

1011	   departed: In SIP, the endpoint sent a BYE, thus leaving the
1012	      conference.

1014	   booted: In SIP, the endpoint was sent a BYE by the focus, ejecting
1015	      him/her out of the conference.  Alternatively, the endpoint tried
1016	      to dial into to conference but was rejected by the focus due to
1017	      local policy.

1019	   failed: In SIP, the server tried to bring the endpoint into the
1020	      conference, but its attempt to contact the specific endpoint
1021	      resulted in a non-200 class final response.  Alternatively, the
1022	      endpoint tried to dial into the conference without success due to
1023	      technical reasons.

1025	   busy: In SIP, the server tried to bring the endpoint into the
1026	      conference, but its attempt to contact the specific endpoint
1027	      resulted in 486 "Busy Here" final response.  Alternatively, the
1028	      endpoint tried to dial into the conference but the focus responded
1029	      with 486 response.

1031	5.7.7  <disconnection-info>

1033	   This element contains information about the endpoint's departure from
1034	   the conference and can contain the following sub-elements:

1036	   when: This element of the XML dateTime type contains the date and
1037	      time that the endpoint departed the conference and SHOULD be
1038	      expressed in Coordinated Universal Time (UTC).

1040	   reason: This element contains the reason the endpoint departed the
1041	      conference.  When known and meaningful, it is RECOMMENDED to
1042	      include the information as conveyed/reported by the call signaling
1043	      in the format defined by RFC 3326 [12].  For example,

1045	   <reason>Reason: SIP;cause=415;text="Unsupported Media Type"</reason>

1047	   by: This element contains the URI of the entity who caused the
1048	      endpoint to depart the conference.

1050	5.7.8  <media>

1052	   This element contains information about a single media stream and is
1053	   included for each media stream being established between the focus
1054	   and the <endpoint>.  The media stream definition can be found in SDP
1055	   [3].

1057	   Note that if the <call-info> sub-element of the endpoint is not
1058	   included in the document by the server, it is possible that the media
1059	   streams listed under the common <endpoint> were established by
1060	   separate signaling sessions.

1062	5.7.9  <call-info>

1064	   The <call-info> element provides detailed call signaling information
1065	   for a call being maintained between the participant and the focus.
1066	   Privacy policies MUST be consulted before revealing this information
1067	   to other participants.

1069	   The <sip> sub-element contains the SIP dialog identifier of the
1070	   endpoint's dialog with the focus.  The element includes sub-elements
1071	   <display-text>, <call-id>, <to-tag>, <from-tag>.

1073	   In future, the <call-info> element can be expanded to include call
1074	   signaling protocol information for other protocols besides SIP.

1076	5.8  <media>

1078	   This section describes the <media> element in more detail.

1080	   A single 'id' attribute is defined for this element.  This is the
1081	   media stream identifier being generated by the server such as its
1082	   value is unique in the endpoint context.  This attribute is the key
1083	   to refer to a particular media stream in the conference document.

1085	   The following child elements are defined for <media>:

1087	5.8.1  <display-text>

1089	   This element contains the display text for the media stream.  The
1090	   value of this element corresponds to the SDP description media
1091	   attribute ("i") defined in SDP [3].

1093	5.8.2  <type>

1095	   This element contains the media type for the media stream.  The value
1096	   of this element MUST be one of the values registered for "media" of
1097	   SDP [3] and its later revision(s).

1099	5.8.3  <label>

1101	   The <label> element carries a unique identifier for this stream among
1102	   all streams in the conference and is assigned by the focus.  The
1103	   value of this element corresponds to the SDP "label" media attribute
1104	   defined in [17], which is exchanged between a participant and a focus
1105	   over the signaling connection between them.

1107	   If the <available-media> information (described in Section 5.3.4) is
1108	   included in the conference document, the value of this element MUST
1109	   be equal to the 'label' value of the corresponding media stream
1110	   <entry> in the <available-media> container.

1112	5.8.4  <src-id>

1114	   The <src-id> element, if applicable, carries the information about
1115	   the actual source of the media.  For example, for Real-Time Transport
1116	   Protocol (RTP) / Real-Time Control Protocol (RTCP) [13] media
1117	   streams, the value MUST contain the synchronization source (SSRC)
1118	   identifier value generated by the endpoint for the stream it sends.

1120	   When an RTP mixer generates a contributing source (CSRC) identifiers'
1121	   list according to RTP/RTCP [13], it inserts a list of the SSRC
1122	   identifiers of the sources that contributed to the generation of a
1123	   particular packet into the RTP header of that packet.  A quote from
1124	   RFC 3550: "An example application is audio conferencing where a mixer
1125	   indicates all the talkers whose speech was combined to produce the
1126	   outgoing packet, allowing the receiver to indicate the current
1127	   talker, even though all the audio packets contain the same SSRC
1128	   identifier (that of the mixer)."

1130	   If an RTP mixer compliant to the above is used, participants can
1131	   perform an SSRC to user mapping and identify "a current speaker".

1133	5.8.5  <status>

1135	   The element <status> indicates the status in both directions of the
1136	   media stream and has the values "sendrecv", "sendonly", "recvonly",
1137	   or "inactive" as defined in SDP [3] and its later revision(s).  Note
1138	   that value specifies the direction from the participant's point of
1139	   view.  For example, a muted participant's stream will have the value
1140	   of "recvonly".

1142	5.9  Sidebars

1144	   If a participant in the main conference joins a sidebar, a new <user>
1145	   element representing the user is created either as a part of a
1146	   separate sub-conference referenced from the <sidebars-by-ref> element
1147	   or under one of the <sidebar-by-val> elements as described below.

1149	   Note that the <user> in the main roster is not being deleted, but its
1150	   media statuses can be updated to reflect the effect being caused by
1151	   his/her participation in the sidebar.  The display of this
1152	   information can vary among subscribers to the same conference
1153	   information, subject to local policies and to the subscriber role
1154	   both in the sidebar and in the main conference.

1156	5.9.1  <sidebars-by-ref>

1158	   This element contains a set of <entry> child elements each containing
1159	   a sidebar conference URI.  The recipient of the information can then
1160	   subscribe to sidebar information independently from the main
1161	   conference package subscription.

1163	5.9.2  <sidebar-by-val>

1165	   This element contains a set of <entry> child elements each containing
1166	   information about a single sidebar.  By using this element of
1167	   conference-type, the server can include a full or a partial
1168	   description of each sidebar (as a sub-conference) in the body of the
1169	   main conference document.

1171	6.  XML Schema

1173	   <?xml version="1.0" encoding="UTF-8" ?>
1174	   <xs:schema
1175	   targetNamespace="urn:ietf:params:xml:ns:conference-info"
1176	   xmlns:tns="urn:ietf:params:xml:ns:conference-info"
1177	   xmlns:xs="http://www.w3.org/2001/XMLSchema"
1178	   xmlns="urn:ietf:params:xml:ns:conference-info"
1179	   elementFormDefault="qualified"
1180	   attributeFormDefault="unqualified"><!--
1181	     This imports the xml:language definition
1182	   -->
1183	      <xs:import namespace="http://www.w3.org/XML/1998/namespace"
1184	       schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
1185	   <!--
1186	     CONFERENCE ELEMENT
1187	   -->
1188	      <xs:element name="conference-info" type="conference-type"/>
1189	      <!--
1190	         CONFERENCE TYPE
1191	      -->
1192	      <xs:complexType name="conference-type">
1193	       <xs:sequence>
1194	        <xs:element name="conference-description"
1195	         type="conference-description-type" minOccurs="0"/>
1196	        <xs:element name="host-info"
1197	         type="host-type" minOccurs="0"/>
1198	        <xs:element name="conference-state"
1199	         type="conference-state-type" minOccurs="0"/>
1200	        <xs:element name="users"
1201	         type="users-type" minOccurs="0"/>
1202	        <xs:element name="sidebars-by-ref"
1203	         type="uris-type" minOccurs="0"/>
1204	        <xs:element name="sidebars-by-val"
1205	         type="sidebars-by-val-type" minOccurs="0"/>
1206	        <xs:any namespace="##other" processContents="lax"
1207	         minOccurs="0" maxOccurs="unbounded"/>
1208	       </xs:sequence>
1209	       <xs:attribute name="entity"
1210	        type="xs:anyURI" use="required"/>
1211	       <xs:attribute name="state"
1212	        type="state-type" use="optional" default="full"/>
1213	       <xs:attribute name="version"
1214	        type="xs:unsignedInt" use="optional"/>
1215	       <xs:anyAttribute namespace="##other"/>
1216	      </xs:complexType>
1217	      <!--
1218	         STATE TYPE
1219	      -->
1220	      <xs:simpleType name="state-type">
1221	       <xs:restriction base="xs:string">
1222	        <xs:enumeration value="full"/>
1223	        <xs:enumeration value="partial"/>
1224	        <xs:enumeration value="deleted"/>
1225	       </xs:restriction>
1226	      </xs:simpleType>
1227	      <!--
1228	         CONFERENCE DESCRIPTION TYPE
1229	      -->
1230	      <xs:complexType name="conference-description-type">
1231	       <xs:sequence>
1232	        <xs:element name="display-text"
1233	         type="xs:string" minOccurs="0"/>
1234	        <xs:element name="subject"
1235	         type="xs:string" minOccurs="0"/>
1236	        <xs:element name="free-text"
1237	         type="xs:string" minOccurs="0"/>
1238	        <xs:element name="keywords"
1239	         type="keywords-type" minOccurs="0"/>
1240	        <xs:element name="conf-uris"
1241	         type="uris-type" minOccurs="0"/>

1243	        <xs:element name="service-uris"
1244	         type="uris-type" minOccurs="0"/>
1245	        <xs:element name="maximum-user-count"
1246	         type="xs:unsignedInt" minOccurs="0"/>
1247	        <xs:element name="available-media"
1248	         type="conference-media-type" minOccurs="0"/>
1249	        <xs:any namespace="##other" processContents="lax"
1250	         minOccurs="0" maxOccurs="unbounded"/>
1251	       </xs:sequence>
1252	       <xs:anyAttribute namespace="##other"/>
1253	      </xs:complexType>
1254	      <!--
1255	         HOST TYPE
1256	      -->
1257	      <xs:complexType name="host-type">
1258	       <xs:sequence>
1259	        <xs:element name="display-text" type="xs:string"
1260	         minOccurs="0"/>
1261	        <xs:element name="web-page" type="xs:anyURI"
1262	         minOccurs="0"/>
1263	        <xs:element name="uris" type="uris-type"
1264	         minOccurs="0"/>
1265	        <xs:any namespace="##other" processContents="lax"

1267	         minOccurs="0" maxOccurs="unbounded"/>
1268	       </xs:sequence>
1269	       <xs:anyAttribute namespace="##other"/>
1270	      </xs:complexType>
1271	      <!--
1272	         CONFERENCE STATE TYPE
1273	      -->
1274	      <xs:complexType name="conference-state-type">
1275	       <xs:sequence>
1276	        <xs:element name="user-count" type="xs:unsignedInt"
1277	         minOccurs="0"/>
1278	        <xs:element name="active" type="xs:boolean"
1279	         minOccurs="0"/>
1280	        <xs:element name="locked" type="xs:boolean"
1281	         minOccurs="0"/>
1282	        <xs:any namespace="##other" processContents="lax"
1283	         minOccurs="0" maxOccurs="unbounded"/>
1284	       </xs:sequence>
1285	       <xs:anyAttribute namespace="##other"/>
1286	      </xs:complexType>
1287	      <!--
1288	         CONFERENCE MEDIA TYPE
1289	      -->
1290	      <xs:complexType name="conference-media-type">
1291	       <xs:sequence>
1292	        <xs:element name="entry" type="conference-medium-type"
1293	         maxOccurs="unbounded"/>
1294	       </xs:sequence>
1295	       <xs:anyAttribute namespace="##other"/>
1296	      </xs:complexType>
1297	      <!--
1298	         CONFERENCE MEDIUM TYPE
1299	      -->
1300	      <xs:complexType name="conference-medium-type">
1301	       <xs:sequence>
1302	        <xs:element name="display-text" type="xs:string"
1303	         minOccurs="0"/>
1304	        <xs:element name="type" type="xs:string"/>
1305	        <xs:element name="status" type="media-status-type"
1306	         minOccurs="0"/>
1307	        <xs:any namespace="##other" processContents="lax"
1308	         minOccurs="0" maxOccurs="unbounded"/>
1309	       </xs:sequence>
1310	       <xs:attribute name="label" type="xs:string"
1311	        use="required"/>
1312	       <xs:anyAttribute namespace="##other"/>
1313	      </xs:complexType>
1314	      <!--
1315	         URIs TYPE
1316	      -->
1317	      <xs:complexType name="uris-type">
1318	       <xs:sequence>
1319	        <xs:element name="entry" type="uri-type"
1320	         maxOccurs="unbounded"/>
1321	       </xs:sequence>
1322	       <xs:attribute name="state" type="state-type"
1323	        use="optional" default="full"/>
1324	       <xs:anyAttribute namespace="##other"/>
1325	      </xs:complexType>
1326	      <!--
1327	         URI TYPE
1328	      -->
1329	      <xs:complexType name="uri-type">
1330	       <xs:sequence>
1331	        <xs:element name="uri" type="xs:anyURI"/>
1332	        <xs:element name="display-text" type="xs:string"
1333	         minOccurs="0"/>
1334	        <xs:element name="purpose" type="xs:string"
1335	         minOccurs="0"/>
1336	        <xs:element name="modified" type="execution-type"
1337	         minOccurs="0"/>
1338	        <xs:any namespace="##other" processContents="lax"
1339	         minOccurs="0" maxOccurs="unbounded"/>
1340	       </xs:sequence>
1341	       <xs:anyAttribute namespace="##other"/>
1342	      </xs:complexType>
1343	      <!--
1344	         KEWORDS TYPE
1345	      -->
1346	      <xs:simpleType name="keywords-type">
1347	       <xs:list itemType="xs:string"/>
1348	      </xs:simpleType>
1349	      <!--
1350	         USERS TYPE
1351	      -->
1352	      <xs:complexType name="users-type">
1353	       <xs:sequence>
1354	        <xs:element name="user" type="user-type"
1355	         minOccurs="0" maxOccurs="unbounded"/>
1356	        <xs:any namespace="##other" processContents="lax"
1357	         minOccurs="0" maxOccurs="unbounded"/>
1358	       </xs:sequence>
1359	       <xs:attribute name="state" type="state-type"
1360	        use="optional" default="full"/>
1361	       <xs:anyAttribute namespace="##other"/>
1362	      </xs:complexType>
1363	      <!--
1364	         USER TYPE
1365	      -->
1366	      <xs:complexType name="user-type">
1367	       <xs:sequence>
1368	        <xs:element name="display-text" type="xs:string"
1369	         minOccurs="0"/>
1370	        <xs:element name="associated-aors" type="uris-type"
1371	         minOccurs="0"/>
1372	        <xs:element name="roles" type="user-roles-type"
1373	         minOccurs="0"/>
1374	        <xs:element name="languages" type="user-languages-type"
1375	         minOccurs="0"/>
1376	        <xs:element name="cascaded-focus" type="xs:anyURI"
1377	         minOccurs="0"/>
1378	        <xs:element name="endpoint" type="endpoint-type"
1379	         minOccurs="0" maxOccurs="unbounded"/>
1380	        <xs:any namespace="##other" processContents="lax"
1381	         minOccurs="0" maxOccurs="unbounded"/>
1382	       </xs:sequence>
1383	       <xs:attribute name="entity" type="xs:anyURI"/>
1384	       <xs:attribute name="state" type="state-type"
1385	        use="optional" default="full"/>
1386	       <xs:anyAttribute namespace="##other"/>

1388	      </xs:complexType>
1389	      <!--
1390	         USER ROLES TYPE
1391	      -->
1392	      <xs:complexType name="user-roles-type">
1393	       <xs:sequence>
1394	        <xs:element name="entry" type="xs:string"
1395	         maxOccurs="unbounded"/>
1396	       </xs:sequence>
1397	       <xs:anyAttribute namespace="##other"/>
1398	      </xs:complexType>
1399	      <!--
1400	         USER LANGUAGES TYPE
1401	      -->
1402	      <xs:simpleType name="user-languages-type">
1403	       <xs:list itemType="xs:language"/>
1404	      </xs:simpleType>
1405	      <!--
1406	         ENDPOINT TYPE
1407	      -->
1408	      <xs:complexType name="endpoint-type">
1409	       <xs:sequence>
1410	        <xs:element name="display-text" type="xs:string"
1411	         minOccurs="0"/>
1412	        <xs:element name="referred" type="execution-type"
1413	         minOccurs="0"/>
1414	        <xs:element name="status" type="endpoint-status-type"
1415	         minOccurs="0"/>
1416	        <xs:element name="joining-method" type="joining-type"
1417	         minOccurs="0"/>
1418	        <xs:element name="joining-info"
1419	         type="execution-type"
1420	         minOccurs="0"/>
1421	        <xs:element name="disconnection-method"
1422	         type="disconnection-type"
1423	         minOccurs="0"/>
1424	        <xs:element name="disconnection-info"

1426	         type="execution-type"
1427	         minOccurs="0"/>
1428	        <xs:element name="media" type="media-type"
1429	         minOccurs="0" maxOccurs="unbounded"/>
1430	        <xs:element name="call-info" type="call-type"
1431	         minOccurs="0"/>
1432	        <xs:any namespace="##other" processContents="lax"
1433	         minOccurs="0" maxOccurs="unbounded"/>
1434	       </xs:sequence>
1435	       <xs:attribute name="entity" type="xs:string"/>
1436	       <xs:attribute name="state" type="state-type"
1437	        use="optional" default="full"/>
1438	       <xs:anyAttribute namespace="##other"/>
1439	      </xs:complexType>
1440	      <!--
1441	         ENDPOINT STATUS TYPE
1442	      -->
1443	      <xs:simpleType name="endpoint-status-type">
1444	       <xs:restriction base="xs:string">
1445	        <xs:enumeration value="pending"/>
1446	        <xs:enumeration value="dialing-out"/>
1447	        <xs:enumeration value="dialing-in"/>
1448	        <xs:enumeration value="alerting"/>
1449	        <xs:enumeration value="on-hold"/>
1450	        <xs:enumeration value="connected"/>
1451	        <xs:enumeration value="muted-via-focus"/>
1452	        <xs:enumeration value="disconnecting"/>

1454	        <xs:enumeration value="disconnected"/>
1455	       </xs:restriction>
1456	      </xs:simpleType>
1457	      <!--
1458	         JOINING TYPE
1459	      -->
1460	      <xs:simpleType name="joining-type">
1461	       <xs:restriction base="xs:string">
1462	        <xs:enumeration value="dialed-in"/>
1463	        <xs:enumeration value="dialed-out"/>
1464	        <xs:enumeration value="focus-owner"/>
1465	       </xs:restriction>
1466	      </xs:simpleType>
1467	      <!--
1468	         DISCONNECTION TYPE
1469	      -->
1470	      <xs:simpleType name="disconnection-type">
1471	       <xs:restriction base="xs:string">
1472	        <xs:enumeration value="departed"/>
1473	        <xs:enumeration value="booted"/>
1474	        <xs:enumeration value="failed"/>
1475	        <xs:enumeration value="busy"/>
1476	       </xs:restriction>
1477	      </xs:simpleType>
1478	      <!--
1479	         EXECUTION TYPE
1480	      -->
1481	      <xs:complexType name="execution-type">
1482	       <xs:sequence>
1483	        <xs:element name="when" type="xs:dateTime"
1484	         minOccurs="0"/>
1485	        <xs:element name="reason" type="xs:string"
1486	         minOccurs="0"/>
1487	        <xs:element name="by" type="xs:anyURI"
1488	         minOccurs="0"/>
1489	       </xs:sequence>
1490	       <xs:anyAttribute namespace="##other"/>
1491	      </xs:complexType>
1492	     <!--
1493	         CALL TYPE
1494	      -->
1495	      <xs:complexType name="call-type">
1496	       <xs:choice>
1497	        <xs:element name="sip" type="sip-dialog-id-type"/>
1498	        <xs:any namespace="##other" processContents="lax"
1499	         minOccurs="0" maxOccurs="unbounded"/>
1500	       </xs:choice>
1501	       <xs:anyAttribute namespace="##other"/>
1502	      </xs:complexType>
1503	      <!--
1504	         SIP DIALOG ID TYPE
1505	      -->
1506	      <xs:complexType name="sip-dialog-id-type">
1507	       <xs:sequence>
1508	        <xs:element name="display-text" type="xs:string"
1509	         minOccurs="0"/>
1510	        <xs:element name="call-id" type="xs:string"/>
1511	        <xs:element name="from-tag" type="xs:string"/>
1512	        <xs:element name="to-tag" type="xs:string"/>
1513	        <xs:any namespace="##other" processContents="lax"
1514	         minOccurs="0" maxOccurs="unbounded"/>
1515	       </xs:sequence>
1516	       <xs:anyAttribute namespace="##other"/>
1517	      </xs:complexType>
1518	      <!--
1519	         MEDIA TYPE
1520	      -->
1521	      <xs:complexType name="media-type">
1522	       <xs:sequence>
1523	        <xs:element name="display-text" type="xs:string"
1524	         minOccurs="0"/>
1525	        <xs:element name="type" type="xs:string"
1526	         minOccurs="0"/>
1527	        <xs:element name="label" type="xs:string"
1528	         minOccurs="0"/>
1529	        <xs:element name="src-id" type="xs:string"
1530	         minOccurs="0"/>
1531	        <xs:element name="status" type="media-status-type"
1532	         minOccurs="0"/>
1533	        <xs:any namespace="##other" processContents="lax"
1534	         minOccurs="0" maxOccurs="unbounded"/>
1535	       </xs:sequence>
1536	       <xs:attribute name="id" type="xs:string"
1537	        use="required"/>
1538	       <xs:anyAttribute namespace="##other"/>
1539	      </xs:complexType>
1540	      <!--
1541	         MEDIA STATUS TYPE
1542	      -->
1543	      <xs:simpleType name="media-status-type">
1544	       <xs:restriction base="xs:string">
1545	        <xs:enumeration value="recvonly"/>
1546	        <xs:enumeration value="sendonly"/>
1547	        <xs:enumeration value="sendrecv"/>
1548	        <xs:enumeration value="inactive"/>
1549	       </xs:restriction>
1550	      </xs:simpleType>
1551	       <!--
1552	         SIDEBARS BY VAL TYPE
1553	       -->
1554	       <xs:complexType name="sidebars-by-val-type">
1555	        <xs:sequence>
1556	         <xs:element name="entry" type="conference-type"
1557	          minOccurs="0" maxOccurs="unbounded"/>
1558	        </xs:sequence>
1559	        <xs:attribute name="state" type="state-type"
1560	         use="optional" default="full"/>
1561	        <xs:anyAttribute namespace="##other"/>
1562	       </xs:complexType>

1564	    </xs:schema>

1566	7.  Examples

1568	7.1  Basic Example

1570	   The following is an example of a full conference information
1571	   document:

1573	   <conference-info entity="sips:conf233@example.com"
1574	    state="full" version="1">
1575	   <!--
1576	     CONFERENCE INFO
1577	   -->
1578	    <conference-description>
1579	     <subject>Agenda: This month's goals</subject>
1580	      <service-uris>
1581	       <entry>
1582	        <uri>http://sharepoint/salesgroup/</uri>
1583	        <purpose>web-page</purpose>
1584	       </entry>
1585	      </service-uris>
1586	     </conference-description>
1587	   <!--
1588	      CONFERENCE STATE
1589	   -->
1590	    <conference-state>
1591	     <user-count>33</user-count>
1592	    </conference-state>
1593	   <!--
1594	     USERS
1595	   -->
1596	    <users>
1597	     <user entity="sip:bob@example.com" state="full">
1598	      <display-text>Bob Hoskins</display-text>
1599	   <!--
1600	     ENDPOINTS
1601	   -->
1602	      <endpoint entity="sip:bob@pc33.example.com">
1603	       <display-text>Bob's Laptop</display-text>
1604	       <status>disconnected</status>
1605	       <disconnection-method>departed</disconnection-method>
1606	       <disconnection-info>
1607	        <when>2005-03-04T20:00:00Z</when>
1608	        <reason>bad voice quality</reason>
1609	        <by>sip:mike@example.com</by>
1610	       </disconnection-info>
1611	   <!--
1612	     MEDIA
1613	   -->
1614	       <media id="1">
1615	        <display-text>main audio</display-text>
1616	        <type>audio</type>
1617	        <label>34567</label>
1618	        <src-id>432424</src-id>
1619	        <status>sendrecv</status>
1620	       </media>
1621	      </endpoint>
1622	     </user>
1623	   <!--
1624	     USER
1625	   -->
1626	     <user entity="sip:alice@example.com" state="full">
1627	      <display-text>Alice</display-text>
1628	   <!--
1629	     ENDPOINTS
1630	   -->
1631	      <endpoint entity="sip:4kfk4j392jsu@example.com;grid=433kj4j3u">
1632	       <status>connected</status>
1633	       <joining-method>dialed-out</joining-method>
1634	       <joining-info>
1635	        <when>2005-03-04T20:00:00Z</when>
1636	        <by>sip:mike@example.com</by>
1637	       </joining-info>
1638	   <!--
1639	     MEDIA
1640	   -->
1641	       <media id="1">
1642	        <display-text>main audio</display-text>
1643	        <type>audio</type>
1644	        <label>34567</label>
1645	        <src-id>534232</src-id>
1646	        <status>sendrecv</status>
1647	       </media>
1648	      </endpoint>
1649	     </user>
1650	    </users>
1651	   </conference-info>

1653	7.2  Rich Example

1655	   The following is an example of a partial conference information
1656	   document.  In this example, there are 32 participants in a voice
1657	   conference.  The user Bob has been ejected from the conference by
1658	   Mike due to bad voice quality.  Note that there are three sidebars in
1659	   the conference, two are referenced just by their sidebar URIs and
1660	   information about the third sidebar is included in this notification.
1661	   Also note that while this conference offers both audio and video
1662	   capabilities, only audio is currently in use.

1664	   <conference-info entity="sips:conf233@example.com"
1665	    state="partial" version="5">
1666	   <!--
1667	     CONFERENCE INFO
1668	   -->
1669	    <conference-description>
1670	     <display-text>Weekly Sales Meeting</display-text>
1671	     <subject>Agenda: This month's goals</subject>
1672	     <free-text>We will start strict on time</free-text>
1673	     <keywords>sales meeting weekly</keywords>
1674	     <conf-uris>
1675	      <entry>
1676	       <uri>tel:+18005671234</uri>
1677	       <display-text>TTI Bridge</display-text>
1678	       <purpose>participation</purpose>
1679	      </entry>
1680	      <entry>
1681	       <uri>h323:conf545@h323.example.com</uri>
1682	       <purpose>participation</purpose>
1683	      </entry>
1684	      <entry>
1685	       <uri>http://real.streaming.com/54634/live.ram</uri>
1686	       <purpose>streaming</purpose>
1687	      </entry>
1688	     </conf-uris>
1689	     <service-uris>
1690	      <entry>
1691	       <uri>http://sharepoint/salesgroup/</uri>
1692	       <purpose>web-page</purpose>
1693	      </entry>
1694	      <entry>
1695	       <uri>http://quicktime.com/54634/recording.mov</uri>
1696	       <display-text>Quicktime</display-text>
1697	       <purpose>recording</purpose>
1698	      </entry>
1699	     </service-uris>
1700	     <maximum-user-count>100</maximum-user-count>
1701	     <available-media>
1702	      <entry label="34567">
1703	       <display-text>main audio</display-text>
1704	       <type>audio</type>
1705	       <status>sendrecv</status>
1706	      </entry>
1707	      <entry label="34569">
1708	       <display-text>main video</display-text>
1709	       <type>video</type>
1710	       <status>inactive</status>
1711	      </entry>
1712	     </available-media>
1713	    </conference-description>
1714	   <!--
1715	     HOST INFO
1716	   -->
1717	    <host-info>
1718	     <display-text>Sales Host</display-text>
1719	     <web-page>http://sharepoint/salesgroup/hosts/</web-page>
1720	     <uris>
1721	      <entry>
1722	       <uri>sip:sales@example.com</uri>
1723	      </entry>
1724	     </uris>
1725	    </host-info>
1726	   <!--
1727	     CONFERENCE STATE
1728	   -->
1729	    <conference-state>
1730	     <user-count>32</user-count>
1731	     <active>true</active>
1732	     <locked>false</locked>
1733	    </conference-state>
1734	   <!--
1735	     USERS
1736	   -->
1737	    <users>
1738	     <user entity="sip:bob@example.com">
1739	      <display-text>Bob Hoskins</display-text>
1740	      <associated-aors>
1741	       <entry>
1742	        <uri>mailto:bob@example.com</uri>
1743	        <display-text>email</display-text>
1744	       </entry>
1745	      </associated-aors>
1746	      <roles>
1747	      <entry>participant</entry>
1748	      </roles>
1749	      <languages>en</languages>
1750	   <!--
1751	     ENDPOINTS
1752	   -->
1753	      <endpoint entity="sip:bob@pc33.example.com">
1754	       <display-text>Bob's Laptop</display-text>
1755	       <referred>
1756	        <when>2005-03-04T20:00:00Z</when>
1757	        <reason>expert required</reason>
1758	        <by>sip:mike@example.com</by>
1759	       </referred>
1760	       <status>disconnecting</status>
1761	       <joining-method>dialed-out</joining-method>
1762	       <joining-info>
1763	        <when>2005-03-04T20:00:00Z</when>
1764	        <reason>invitation</reason>
1765	        <by>sip:mike@example.com</by>
1766	       </joining-info>
1767	       <disconnection-method>booted</disconnection-method>
1768	       <disconnection-info>

1770	        <when>2005-03-04T20:00:00Z</when>
1771	        <reason>bad voice quality</reason>
1772	        <by>sip:mike@example.com</by>
1773	       </disconnection-info>
1774	   <!--
1775	     MEDIA
1776	   -->
1777	       <media id="1">
1778	        <display-text>main audio</display-text>
1779	        <type>audio</type>
1780	        <label>34567</label>
1781	        <src-id>432424</src-id>
1782	        <status>sendrecv</status>
1783	       </media>
1784	   <!--
1785	     CALL INFO
1786	   -->
1787	       <call-info>
1788	        <sip>
1789	         <display-text>full info</display-text>
1790	           <call-id>hsjh8980vhsb78</call-id>
1791	           <from-tag>vav738dvbs</from-tag>
1792	           <to-tag>8954jgjg8432</to-tag>
1793	        </sip>
1794	       </call-info>
1795	      </endpoint>
1796	     </user>
1797	    </users>
1798	   <!--
1799	     SIDEBARS BY REFERENCE
1800	   -->
1801	    <sidebars-by-ref state="partial">
1802	     <entry>
1803	      <uri>sips:conf233@example.com;grid=45</uri>
1804	      <display-text>sidebar with Carol</display-text>
1805	     </entry>
1806	     <entry>
1807	      <uri>sips:conf233@example.com;grid=21</uri>
1808	      <display-text>private with Peter</display-text>
1809	     </entry>
1810	    </sidebars-by-ref>
1811	   <!--
1812	     SIDEBARS BY VALUE
1813	   -->
1814	    <sidebars-by-val state="partial">
1815	     <entry entity="sips:conf233@example.com;grid=77"
1816	      state="partial">
1817	      <users>
1818	       <user entity="sip:bob@example.com"/>
1819	       <user entity="sip:mark@example.com"/>
1820	       <user entity="sip:dan@example.com"/>
1821	      </users>
1822	     </entry>
1823	    </sidebars-by-val>
1824	   </conference-info>

1826	8.  Security Considerations

1828	   Subscriptions to conference state information can reveal very
1829	   sensitive information.  For this reason, it is RECOMMENDED a focus
1830	   use a strong means for authentication, conference information
1831	   protection, and apply comprehensive authorization rules when using
1832	   the conference notification mechanism defined in this document.  The
1833	   following sections will discuss each of these aspects in more detail.

1835	8.1  Connection Security

1837	   It is RECOMMENDED that a focus authenticate a conference package
1838	   subscriber using the normal SIP authentication mechanisms, such as
1839	   Digest as defined in Section 22 of RFC 3261 [8].

1841	   The mechanism used for conveying the conference information MUST
1842	   ensure integrity and SHOULD ensure confidentially of the information.
1843	   In order to achieve these, an end-to-end SIP encryption mechanism,
1844	   such as S/MIME described in Section 26.2.4 of RFC 3261 [8], SHOULD be
1845	   used.

1847	   If strong end-to-end security means (such as above) is not available,
1848	   it is RECOMMENDED that a focus use mutual hop-by-hop TLS
1849	   authentication and encryption mechanisms described in Section 26.2.2
1850	   "SIPS URI Scheme" and Section 26.3.2.2 "Interdomain Requests" of RFC
1851	   3261 [8].

1853	8.2  Authorization Considerations

1855	   Generally speaking, conference applications are very concerned about
1856	   authorization decisions.  Mechanisms for establishing and enforcing
1857	   such authorization rules are a central concept throughout the SIP
1858	   conferencing framework [16].  Because most of the information about a
1859	   conference can be presented using the conference package, many of the
1860	   authorization rules directly apply to this specification.  As a
1861	   result, a notification server MUST be capable of generating distinct
1862	   conference information views to different subscribers, subject to a
1863	   subscriber's role in a conference, personal access rights, etc. - all
1864	   subject to local authorization policies and rules.

1866	   Since a focus provides participant identity information using this
1867	   event package, participant privacy needs to be taken into account.  A
1868	   focus MUST support requests by participants for privacy.  Privacy can
1869	   be indicated by the conference policy - for every participant or
1870	   select participants.  It can also be indicated in the session
1871	   signaling.  In SIP this can be done using the Privacy header field
1872	   described in RFC 3323 [11].  For a participant requesting privacy, no
1873	   identity information SHOULD be revealed by the focus in any included
1874	   URI (e.g. the Address of Record, Contact, or GRUU).  For these cases,
1875	   the anonymous URI generation method outlined in Section 5.6 of this
1876	   document MUST be followed.

1878	9.  IANA Considerations

1880	   This document registers a SIP event package, a new MIME type,
1881	   application/conference-info+xml, a new XML namespace, a new XML
1882	   schema, and creates a  sub-registry "URI purposes" under the
1883	   existing registry: http://www.iana.org/assignments/sip-parameters.

1885	9.1  conference Event Package Registration

1887	   This specification registers an event package, based on the
1888	   registration procedures defined in RFC 3265 [10].  The following is
1889	   the information required for such a registration:
1890	   Package Name: conference
1891	   Package or Template-Package: This is a package.
1892	   Published Document: RFC XXXX (Note to RFC Editor: Please, fill in
1893	      XXXX with the RFC number of this specification).
1894	   Person to Contact: IETF SIPPING Working Group <sipping@ietf.org>, as
1895	      designated by the IESG <iesg@ietf.org>

1897	9.2  application/conference-info+xml MIME Registration
1898	   MIME media type name: application
1899	   MIME subtype name: conference-info+xml
1900	   Mandatory parameters: none
1901	   Optional parameters: Same as charset parameter application/xml as
1902	      specified in RFC 3023 [7]
1903	   Encoding considerations: Same as encoding considerations of
1904	      application/xml as specified in RFC 3023 [7]
1905	   Security considerations: See Section 10 of RFC 3023 [7] and Section 8
1906	      of this specification

1908	   Interoperability considerations: none
1909	   Published specification: This document
1910	   Applications which use this media type: This document type has been
1911	      used to support SIP conferencing applications
1912	   Additional Information:
1913	      Magic Number: None
1914	      File Extension: .xml
1915	      Macintosh file type code: "TEXT"
1916	   Personal and email address for further information: IETF SIPPING
1917	      Working Group <sipping@ietf.org>, as designated by the IESG
1918	      <iesg@ietf.org>
1919	   Intended usage: COMMON
1920	   Author/Change controller: IETF SIPPING Working Group
1921	      <sipping@ietf.org>, as designated by the IESG <iesg@ietf.org>

1923	9.3  URN Sub-Namespace Registration for
1924	     urn:ietf:params:xml:ns:conference-info

1926	   This section registers a new XML namespace, as per the guidelines in
1927	   RFC 3688 [21].

1929	   URI: The URI for this namespace is
1930	      urn:ietf:params:xml:ns:conference-info
1931	   Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>, as
1932	      designated by the IESG <iesg@ietf.org>
1933	   XML:

1935	   BEGIN
1936	   <?xml version="1.0"?>
1937	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
1938	             "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
1939	   <html xmlns="http://www.w3.org/1999/xhtml">
1940	   <head>
1941	     <meta http-equiv="content-type"
1942	        content="text/html;charset=iso-8859-1"/>
1943	     <title>Conference Information Namespace</title>

1945	   </head
1946	   <body>
1947	     <h1>Namespace for Conference Information</h1>
1948	     <h2>urn:ietf:params:xml:ns:conference-info</h2>
1949	     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
1950	   </body>
1951	   </html>
1952	   END

1954	9.4  XML Schema Registration

1956	   This specification registers a schema, as per the guidelines in RFC
1957	   3688 [21].
1958	      URI: please assign
1959	      Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
1960	      as designated by the IESG <iesg@ietf.org>
1961	      XML: The XML can be found as the sole content of Section 6

1963	9.5  URI Purposes Sub-registry Establishment

1965	   This document instructs the IANA to create a new sub-registry "URI
1966	   purposes" under the already existing registry:
1967	   http://www.iana.org/assignments/sip-parameters.

1969	   The purpose of a URI is an XML element, encoded in the conference
1970	   event package [RFC XXXX - substitute with the number assigned to this
1971	   draft].  The value of the <purpose> element indicates the intended
1972	   usage of the URI in the context of the conference event package and
1973	   is defined in sections Section 5.3.1 and Section 5.3.2 of this
1974	   specification.

1976	   This sub-registry is defined as a table that contains the following
1977	   three columns:

1979	   Value: The token under registration
1980	   Description: A descriptive text defining the intended usage of the
1981	      URI
1982	   Document: A reference to the document defining the registration

1984	   This specification instructs IANA to create the table with the
1985	   initial content as defined below:

1987	   Value         Description                         Document
1988	   -------       ----------------------------------  ----------

1990	   participation The URI can be used to join the     [RFC XXXX]
1991	                 conference

1993	   streaming     The URI can be used to access the   [RFC XXXX]
1994	                 streamed conference data

1996	   event         The URI can be used to subscribe    [RFC XXXX]
1997	                 to the conference event package

1999	   recording     The URI can be used to access the   [RFC XXXX]
2000	                 recorded conference data

2002	   web-page      The URI can be used to access a     [RFC XXXX]
2003	                 web page that contains additional
2004	                 information of the conference

2006	   New values of the "URI purposes" are registered by the IANA when
2007	   specification is approved, according to the IETF Consensus policy in
2008	   RFC 2434 [4].  The IANA Considerations section of the specification
2009	   MUST include the following information:

2011	   Value: The value of the <purpose> element to be registered

2013	   Description: A short description of the intended usage of the URI

2015	   Security Considerations: A brief discussion of any security issues
2016	      associated with the new URI purpose usage, and methods of handling
2017	      them

2019	10.  Acknowledgements

2021	   The authors would like to thank Dan Petrie, Sean Olson, Alan
2022	   Johnston, Rohan Mahy, Cullen Jennings, Brian Rosen, Roni Even, and
2023	   Miguel Garcia for their comments and inputs.

2025	11.  References

2027	11.1  Normative References

2029	   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
2030	         Levels", BCP 14, RFC 2119, March 1997.

2032	   [2]   Moats, R., "URN Syntax", RFC 2141, May 1997.

2034	   [3]   Handley, M. and V. Jacobson, "SDP: Session Description
2035	         Protocol", RFC 2327, April 1998.

2037	   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
2038	         Considerations Section in RFCs", BCP 26, RFC 2434,
2039	         October 1998.

2041	   [5]   Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
2042	         BCP 32, RFC 2606, June 1999.

2044	   [6]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
2045	         August 1999.

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

2050	   [8]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
2051	         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
2052	         Session Initiation Protocol", RFC 3261, June 2002.

2054	   [9]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
2055	         Session Description Protocol (SDP)", RFC 3264, June 2002.

2057	   [10]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
2058	         Notification", RFC 3265, June 2002.

2060	   [11]  Peterson, J., "A Privacy Mechanism for the Session Initiation
2061	         Protocol (SIP)", RFC 3323, November 2002.

2063	   [12]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
2064	         Field for the Session Initiation Protocol (SIP)", RFC 3326,
2065	         December 2002.

2067	   [13]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
2068	         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
2069	         RFC 3550, July 2003.

2071	   [14]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
2072	         STD 63, RFC 3629, November 2003.

2074	   [15]  Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
2075	         Mechanism", RFC 3892, September 2004.

2077	   [16]  Rosenberg, J., "A Framework for Conferencing with the Session
2078	         Initiation Protocol",
2079	         draft-ietf-sipping-conferencing-framework-05 (work in
2080	         progress), May 2005.

2082	   [17]  Levin, O. and G. Camarillo, "The SDP (Session Description
2083	         Protocol) Label Attribute",
2084	         draft-ietf-mmusic-sdp-media-label-01 (work in progress),
2085	         January 2005.

2087	11.2  Informative References

2089	   [18]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
2090	         Protocol (RTSP)", RFC 2326, April 1998.

2092	   [19]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
2093	         December 2004.

2095	   [20]  Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
2096	         Registration", RFC 3508, April 2003.

2098	   [21]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2099	         January 2004.

2101	   [22]  Saint-Andre, P., "A Uniform Resource Identifier (URI) Scheme
2102	         for the Extensible Messaging and  Presence Protocol (XMPP)",
2103	         draft-saintandre-xmpp-uri-08 (work in progress), December 2004.

2105	   [23]  Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
2106	         the Session Initiation  Protocol (SIP)",
2107	         draft-ietf-sipping-dialog-package-06 (work in progress),
2108	         April 2005.

2110	   [24]  Rosenberg, J., "Obtaining and Using Globally Routable User
2111	         Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
2112	         (SIP)", draft-ietf-sip-gruu-03 (work in progress),
2113	         February 2005.

2115	   [25]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
2116	         Identity Management in the Session Initiation  Protocol (SIP)",
2117	         draft-ietf-sip-identity-05 (work in progress), May 2005.

2119	Authors' Addresses

2121	   Jonathan Rosenberg
2122	   Cisco Systems
2123	   600 Lanidex Plaza
2124	   Parsippany, NJ  07054
2125	   US

2127	   Phone: +1 973 952-5000
2128	   Email: jdrosen@cisco.com
2129	   URI:   http://www.jdrosen.net

2131	   Henning Schulzrinne
2132	   Columbia University
2133	   M/S 0401
2134	   1214 Amsterdam Ave.
2135	   New York, NY  10027
2136	   US

2138	   Email: schulzrinne@cs.columbia.edu
2139	   URI:   http://www.cs.columbia.edu/~hgs

2141	   Orit Levin (editor)
2142	   Microsoft Corporation
2143	   One Microsoft Way
2144	   Redmond, WA  98052
2145	   US

2147	   Email: oritl@microsoft.com

2149	Intellectual Property Statement

2151	   The IETF takes no position regarding the validity or scope of any
2152	   Intellectual Property Rights or other rights that might be claimed to
2153	   pertain to the implementation or use of the technology described in
2154	   this document or the extent to which any license under such rights
2155	   might or might not be available; nor does it represent that it has
2156	   made any independent effort to identify any such rights.  Information
2157	   on the procedures with respect to rights in RFC documents can be
2158	   found in BCP 78 and BCP 79.

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

2167	   The IETF invites any interested party to bring to its attention any
2168	   copyrights, patents or patent applications, or other proprietary
2169	   rights that may cover technology that may be required to implement
2170	   this standard.  Please address the information to the IETF at
2171	   ietf-ipr@ietf.org.

2173	Disclaimer of Validity

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

2183	Copyright Statement

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

2189	Acknowledgment

2191	   Funding for the RFC Editor function is currently provided by the
2192	   Internet Society.