idnits 2.17.1 draft-ietf-sipping-conference-package-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2041. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2018. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2025. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2031. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 56 instances of too long lines in the document, the longest one being 207 characters in excess of 72. ** There are 345 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (February 20, 2005) is 7002 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 1882 == Unused Reference: '11' is defined on line 1936, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1952, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1971, but no explicit reference was found in the text ** 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. '5') ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (ref. '8') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3388 (ref. '11') (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '15') (Obsoleted by RFC 7826) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-03 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-05 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-02 Summary: 14 errors (**), 0 flaws (~~), 10 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: August 24, 2005 H. Schulzrinne 5 Columbia University 6 O. Levin, Ed. 7 Microsoft Corporation 8 February 20, 2005 10 A Session Initiation Protocol (SIP) Event Package for Conference 11 State 12 draft-ietf-sipping-conference-package-09 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 24, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document defines a conference event package for the Session 48 Initiation Protocol (SIP) Events framework, along with a data format 49 used in notifications for this package. The conference package 50 allows users to subscribe to a conference URI. Notifications are 51 sent about changes in the membership of this conference and 52 optionally about changes in the state of additional conference 53 components. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Conference Event Package . . . . . . . . . . . . . . . . . . 5 60 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5 61 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 62 3.3 Subscription Duration . . . . . . . . . . . . . . . . . . 6 63 3.4 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 64 3.5 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 7 65 3.6 Notifier Generation of NOTIFY Requests . . . . . . . . . . 7 66 3.7 Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 67 3.8 Handling of Forked Requests . . . . . . . . . . . . . . . 8 68 3.9 Rate of Notifications . . . . . . . . . . . . . . . . . . 8 69 3.10 State Agents . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Conference Document . . . . . . . . . . . . . . . . . . . . 8 71 4.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.3 Versioning . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.4 State and Partial Notifications . . . . . . . . . . . . . 9 75 4.5 Element Keys . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.6 Constructing Coherent State Procedure . . . . . . . . . . 10 77 5. Conference Data . . . . . . . . . . . . . . . . . . . . . . 11 78 5.1 conference-type . . . . . . . . . . . . . . . . . . . . . 11 79 5.1.1 conference-description of 80 conference-description-type . . . . . . . . . . . . . 12 81 5.1.2 host-info of host-type . . . . . . . . . . . . . . . . 12 82 5.1.3 conference-state of conference-state-type . . . . . . 12 83 5.1.4 users of users-type . . . . . . . . . . . . . . . . . 12 84 5.1.5 sidebars-by-ref of uris-type . . . . . . . . . . . . . 12 85 5.1.6 sidebar-by-val of conference-type . . . . . . . . . . 12 86 5.2 conference-description-type . . . . . . . . . . . . . . . 13 87 5.2.1 display-text of string type . . . . . . . . . . . . . 13 88 5.2.2 subject of string type . . . . . . . . . . . . . . . . 13 89 5.2.3 free-text of string type . . . . . . . . . . . . . . . 13 90 5.2.4 keywords of keywords-type . . . . . . . . . . . . . . 13 91 5.2.5 conf-uris of uris-type . . . . . . . . . . . . . . . . 13 92 5.2.6 service-uris of uris-type . . . . . . . . . . . . . . 14 93 5.2.7 maximum-user-count of user-count-type . . . . . . . . 14 94 5.2.8 available-media of conference-media-type . . . . . . . 14 95 5.3 host-type . . . . . . . . . . . . . . . . . . . . . . . . 14 96 5.3.1 display-text of string type . . . . . . . . . . . . . 15 97 5.3.2 web-page of anyURI type . . . . . . . . . . . . . . . 15 98 5.3.3 uris of uris-type . . . . . . . . . . . . . . . . . . 15 99 5.4 conference-state-type . . . . . . . . . . . . . . . . . . 15 100 5.4.1 user-count of user-count-type . . . . . . . . . . . . 15 101 5.4.2 active of Boolean type . . . . . . . . . . . . . . . . 15 102 5.4.3 locked of Boolean type . . . . . . . . . . . . . . . . 15 103 5.4.4 active-media of conference-media-type . . . . . . . . 15 104 5.5 conference-media-type . . . . . . . . . . . . . . . . . . 16 105 5.5.1 conference-medium-type . . . . . . . . . . . . . . . . 16 106 5.5.1.1 display-text of string type . . . . . . . . . . . 16 107 5.5.1.2 type of string type . . . . . . . . . . . . . . . 16 108 5.5.1.3 label of string type . . . . . . . . . . . . . . . 17 109 5.6 user-type . . . . . . . . . . . . . . . . . . . . . . . . 17 110 5.6.1 display-text of string type . . . . . . . . . . . . . 17 111 5.6.2 associated-aors of anyURI type . . . . . . . . . . . . 17 112 5.6.3 roles of user-roles-type . . . . . . . . . . . . . . . 17 113 5.6.4 language of language type . . . . . . . . . . . . . . 18 114 5.6.5 cascaded-focus of anyURI type . . . . . . . . . . . . 18 115 5.6.6 endpoint of endpoint-type . . . . . . . . . . . . . . 18 116 5.7 endpoint-type . . . . . . . . . . . . . . . . . . . . . . 19 117 5.7.1 display-text of string type . . . . . . . . . . . . . 19 118 5.7.2 referred of execution-type . . . . . . . . . . . . . . 19 119 5.7.3 status of endpoint-status-type . . . . . . . . . . . . 20 120 5.7.4 joining-method of joining-type . . . . . . . . . . . . 21 121 5.7.5 joining-info of execution-type . . . . . . . . . . . . 21 122 5.7.6 disconnection-method of disconnection-type . . . . . . 21 123 5.7.7 disconnection-info of execution-type . . . . . . . . . 22 124 5.7.8 media of media-type . . . . . . . . . . . . . . . . . 22 125 5.7.9 call-info of call-type . . . . . . . . . . . . . . . . 22 126 5.7.10 media-type . . . . . . . . . . . . . . . . . . . . . 23 127 5.7.10.1 display-text of string type . . . . . . . . . . 23 128 5.7.10.2 type of string type . . . . . . . . . . . . . . 23 129 5.7.10.3 label of string type . . . . . . . . . . . . . . 23 130 5.7.10.4 src-id of string type . . . . . . . . . . . . . 24 131 5.7.10.5 status of media-status-type . . . . . . . . . . 24 132 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 24 133 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 134 7.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 32 135 7.2 Rich Example . . . . . . . . . . . . . . . . . . . . . . . 34 136 8. Security Considerations . . . . . . . . . . . . . . . . . . 38 137 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 138 9.1 conference Event Package Registration . . . . . . . . . . 38 139 9.2 application/conference-info+xml MIME Registration . . . . 39 140 9.3 URN Sub-Namespace Registration for 141 urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 39 142 9.4 XML Schema Registration . . . . . . . . . . . . . . . . . 40 143 9.5 URI Purposes Sub-registry Establishment . . . . . . . . . 40 144 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 145 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 146 11.1 Normative References . . . . . . . . . . . . . . . . . . 41 147 11.2 Informative References . . . . . . . . . . . . . . . . . 42 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 149 Intellectual Property and Copyright Statements . . . . . . . 45 151 1. Introduction 153 The Session Initiation Protocol (SIP) [7]Events Framework [8] defines 154 general mechanisms for subscribing to, and receiving notifications 155 of, events within SIP networks. It introduces the notion of a 156 package, which is a specific "instantiation" of the events framework 157 for a well-defined set of events. Here, we define an event package 158 for SIP conferences. This package provides the conference 159 notification service as outlined in the SIP conferencing framework 160 [18]. As described there, subscriptions to a conference URI are 161 routed to the focus that is handling the conference. It acts as the 162 notifier, and provides clients with updates on conference state. 164 The information provided by this package is comprised of conference 165 identifier(s), conference participants (optionally with their 166 statuses and media description), conference sidebars, conference 167 service URIs, etc. 169 2. Terminology 171 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 172 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 173 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 174 indicate requirement levels for compliant implementations. 176 3. Conference Event Package 178 The conference event package allows a user to subscribe to a 179 conference. In SIP, conferences are represented by URIs. These URIs 180 route to a SIP user agent, called a focus, that is responsible for 181 ensuring that all users in the conference can communicate with each 182 other, as described in Conferencing Framework [18]. The focus has 183 sufficient information about the state of the conference to inform 184 subscribers about it. 186 It is possible that a participant in the conference may in fact be 187 another focus. In order to provide a more complete participant list, 188 the focus MAY subscribe to the conference package of the other focus 189 to discover the participant list in the cascaded conference. This 190 information can then be included in notifications by use of the 191 element as specified by this package. 193 This section provides the details for defining a SIP-specific event 194 notification package, as specified by RFC 3265 [8]. 196 3.1 Event Package Name 198 The name of this event package is "conference". This package name is 199 carried in the Event and Allow-Events header, as defined in RFC 3265 200 [8]. 202 3.2 SUBSCRIBE Bodies 204 A SUBSCRIBE for a conference package MAY contain a body. This body 205 defines a filter to apply to the subscription. Filter documents are 206 not specified in this document, and at the time of writing, are 207 expected to be the subject of future standardization activity. 209 A SUBSCRIBE for a conference package MAY be sent without a body. 210 This implies the default subscription filtering policy. The default 211 policy is: 212 o Notifications are generated every time there is any change in the 213 state of the conference. 214 o Notifications do not normally contain full state; rather, they 215 only indicate the state that has changed. The exception is a 216 NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the 217 full state of the information requested by the subscriber. 219 3.3 Subscription Duration 221 The default expiration time for a subscription to a conference is one 222 hour. Once the conference ends, all subscriptions to that particular 223 conference are terminated, with a reason of "noresource" as defined 224 in RFC 3265 [8]. 226 3.4 NOTIFY Bodies 228 As described in RFC 3265 [8], the NOTIFY message will contain bodies 229 that describe the state of the subscribed resource. This body is in 230 a format listed in the Accept header field of the SUBSCRIBE, or a 231 package-specific default if the Accept header field was omitted from 232 the SUBSCRIBE. 234 In this event package, the body of the notification contains a 235 conference information document. This document describes the state 236 of a conference. All subscribers and notifiers MUST support the 237 "application/conference-info+xml" data format described in Section 5. 238 The subscribe request MAY contain an Accept header field. If no such 239 header field is present, it has a default value of 240 "application/conference-info+xml". If the header field is present, 241 it MUST include "application/conference-info+xml", and MAY include 242 any other types. 244 Of course, the notifications generated by the server MUST be in one 245 of the formats specified in the Accept header field in the SUBSCRIBE 246 request. 248 3.5 Notifier Processing of SUBSCRIBE Requests 250 The conference information contains very sensitive information. 251 Therefore, all subscriptions SHOULD be authenticated and then 252 authorized before approval. Authorization policy is at the 253 discretion of the administrator, as always. However, a few 254 recommendations can be made. 256 It is RECOMMENDED that all users in the conference be allowed to 257 subscribe to the conference event package. 259 3.6 Notifier Generation of NOTIFY Requests 261 Notifications SHOULD be generated for the conference state when a new 262 participant joins (i.e. gets "connected" to) or a participant leaves 263 (i.e. gets "disconnected" from) the conference. 265 Subject to a local focus policy, additional changes in participants' 266 status, changes in their media types, and other optional information 267 MAY be reported by the focus. 269 Changes in sidebar rosters SHOULD be reported by the focus to their 270 participants and MAY be reported to others, subject to local policy. 272 Changes in conference identifiers and service URIs SHOULD be reported 273 by the focus to the Conference package subscribers. 275 Changes in other conference state information MAY be reported by the 276 focus to the Conference package subscribers. 278 3.7 Subscriber Processing of NOTIFY Requests 280 The SIP Events framework expects packages to specify how a subscriber 281 processes NOTIFY requests in any package specific ways, and in 282 particular, how it uses the NOTIFY requests to construct a coherent 283 view of the state of the subscribed resource. 285 Typically, the NOTIFY for the conference package will only contain 286 information about those users whose state in the conference has 287 changed. To construct a coherent view of the total state of all 288 users, a subscriber to the conference package will need to combine 289 NOTIFYs received over time. 291 Notifications within this package can convey partial information; 292 that is, they can indicate information about a subset of the state 293 associated with the subscription. This means that an explicit 294 algorithm needs to be defined in order to construct coherent and 295 consistent state. The details of this mechanism are specific to the 296 particular document type. See Section 4.6 for information on 297 constructing coherent information from an 298 application/conference-info+xml document. 300 3.8 Handling of Forked Requests 302 By their nature, the conferences supported by this package are 303 centralized. Therefore, SUBSCRIBE requests for a conference should 304 not generally fork. Users of this package MUST NOT install more than 305 a single subscription as a result of a single SUBSCRIBE request. 307 3.9 Rate of Notifications 309 For reasons of congestion control, it is important that the rate of 310 notifications not become excessive. As a result, it is RECOMMENDED 311 that the server doesn't generate notifications for a single 312 subscriber at a rate faster than once every 5 seconds. 314 3.10 State Agents 316 Conference state is ideally maintained in the element in which the 317 conference resides. Therefore, the elements that maintain the 318 conference are the ones best suited to handle subscriptions to it. 319 Therefore, the usage of state agents is NOT RECOMMENDED for this 320 package. 322 4. Conference Document 324 4.1 Format 326 Conference information is an XML document that MUST be well-formed 327 and valid. It MUST be based on Extensible Markup Language (XML) 1.0 328 and MUST be encoded using UTF-8 [13]. 330 4.2 Namespace 332 This specification makes use of XML namespaces for identifying 333 conference information documents and document fragments. The 334 namespace URI for elements defined by this specification is a URN 335 [2], using the namespace identifier 'ietf' defined by [5] and 336 extended by RFC 3688 [14]. This URN is: 338 urn:ietf:params:xml:ns:conference-info 340 4.3 Versioning 342 The conference information is described by a hierarchal XML structure 343 with the root element . The root element is the 344 only element in the schema that carries meaningful version number for 345 all the elements in the document. The whole conference information 346 is associated with this version number. 348 The 'version' attribute MUST be included in the root 349 element. 351 4.4 State and Partial Notifications 353 All sub-elements in the hierarchal XML structure 354 can be classified in two groups: those that carry relatively small 355 amount of data and those that can potentially carry a lot of data. 356 During partial notifications, the light elements are updated as 357 atomic pieces of data. On the other hand, elements that can carry a 358 substantial amount of data have the general 'state' attribute 359 attached to them. That is in order to support partial notifications 360 for their content. 362 The 'state' attribute indicates whether the reported information 363 about the element is "full", "partial" or the element is "deleted" 364 from the conference state document. The default value of any 'state' 365 attribute is "full". 367 A 'state' attribute of a child element in the document MUST adhere to 368 its parent 'state'. It means that if the parent's 'state' is "full", 369 the state of its children MUST be "full". If the parent's 'state' is 370 "partial", the state of its children MAY be either "partial", "full", 371 or "deleted". 373 4.5 Element Keys 375 In the context of this specification, the element key is the set of 376 mandatory attributes or sub-elements of the element. The key value 377 MUST be unique for the element among its siblings of the same type. 379 In a partial notification event it must be possible to uniquely 380 identify each sub-element among others of the same type under a 381 common parent element. In order to achieve this property, all 382 sub-elements, with possible multiple appearances under a common 383 parent (which has the attribute 'state') have keys defined to them. 385 Below is the list of the elements with their keys as defined by this 386 specification: 388 o Elements and use as the key 'entity' 389 o Element uses as the key 'entity' and optionally 390 'call-id' 392 o Element uses as the key 'id' 393 o Sub-element of uris-type contained in elements 394 and uses as the key 395 o Elements and of 396 conference-media-type use as the key 'id' 397 o Elements and of count-type use 398 as the key 'role' 399 o Sub-element of conference-type contained in element 400 uses as the key 'entity' 401 o Elements and of uris-type use 402 as the key 404 4.6 Constructing Coherent State Procedure 406 A conference package subscriber locally maintains a local version 407 number, a local element for each element in the schema, and a table 408 for each element with key(s) in the schema. 410 For first time a NOTIFY with a "full" document is received (as 411 indicated by the value of the 'state' attribute in the 412 element), the conference package subscriber MUST 413 set the local 'version' number to the value of the 'version' 414 attribute from the received and populate local data 415 with the received information. 417 Each time a new NOTIFY is received, the value of the local version 418 number and the value of the 'version' attribute in the new received 419 document are compared. If the value in the document is equal or less 420 than the local version, the document is discarded without processing. 422 Otherwise, if the received NOTIFY contains a "full" or "deleted" 423 state, the conference package subscriber MUST set the local 'version' 424 number to the value of the 'version' attribute from the received 425 and replace the local information with the received 426 document. Receiving "deleted" state means that the conference ceased 427 to exist and the subscriber SHOULD terminate the subscription by 428 sending the SUBSCRIBE with Expires = 0. 430 Otherwise (i.e. if the received NOTIFY contains "partial" state), if 431 the 'version' number in the received document is more than one number 432 higher than the previous local version number, the subscriber MUST 433 generate a refresh request to trigger a full state notification. If 434 the 'version' number in the document is one higher than the local 435 version number, the local version number is increased by one and the 436 document is used to update the local content as described below. 438 For each sub-element of the element in the received 439 document, 440 1. If the element contains "full" state, the whole local element 441 content is flushed and repopulated from the document. 443 2. Otherwise, if the element contains "deleted" state, the whole 444 element MUST be removed from the local content. 446 3. Otherwise, if the element contains "partial" state: 448 3.1 For elements with keys, the subscriber compares the keys received 449 in the update with the keys in the local tables. 451 3.1.1 If a key does not exist in the local table, a row is added, and 452 its content is set to the element information from the update. 454 3.1.2 Otherwise, if a key of the same value does exist, for each 455 sub-element in the row the algorithm is applied from step 3.2. 457 3.2 For each atomic element received in the schema, the element is 458 replaced with the new information as a whole. Also, for each 459 non-atomic element received in the schema with either no 'state' 460 attribute included or the state attribute is set to "full", the 461 element is replaced with the new information as a whole. 463 3.3 For each non-atomic element with the state attribute set to 464 "partial", the algorithm is applied recursively starting from step 465 3.1. 467 5. Conference Data 469 A conference information document begins with the root element tag 470 of conference-type. Sections below describe the 471 complex types composing the hierarchal conference-type. The full XML 472 schema is defined in Section 6. 474 5.1 conference-type 476 This type defines the following attributes: 478 entity: This attribute contains the conference URI that identifies 479 the conference being described in the document. 481 state: This attribute indicates whether the document contains the 482 whole conference information ("full"), only the information that 483 has changed since the previous document ("partial"), or the 484 conference ceased to exist ("deleted"). For more details see 485 Section 4. 487 version: This attribute allows the recipient of conference 488 information documents to properly order them and it MUST be 489 included when used in the root element. Version 490 number is a 32 bit monotonically increasing integer scoped within 491 a subscription. A server MUST increment the version number by one 492 for each new partial notification being sent to a subscriber. 494 The conference-type defines an extendable sequence of child elements. 495 A "full" conference document MUST at least include the following 496 sub-elements: , , and 497 . 499 The child elements are described in details below: 501 5.1.1 conference-description of conference-description-type 503 This element contains conference information that is derived from 504 system conference policies, is set before the conference activation, 505 and is rarely changed during the conference lifetime. 507 5.1.2 host-info of host-type 509 This element contains information about the entity that hosts the 510 conference. This information is set before the conference 511 activation, and is rarely changed during the conference lifetime, 512 unless the whole conference is moved to be hosted by another entity. 514 5.1.3 conference-state of conference-state-type 516 This element contains the dynamic information about the current state 517 of the conference. 519 5.1.4 users of users-type 521 This element can contain an unbounded number of sub-elements 522 of user-type each containing the information about a participant in 523 the conference. 525 5.1.5 sidebars-by-ref of uris-type 527 This element contains sub-elements of uri-type which provide 528 pointers to sidebar information through sidebar URIs. The recipient 529 of the information can then subscribe to sidebar information 530 independently from the main conference package subscription. 532 5.1.6 sidebar-by-val of conference-type 534 This element provides sidebar information as a part of the main 535 conference package information. 537 5.2 conference-description-type 539 This type defines the 'state' attribute which can contain the values 540 "full", "partial", or "deleted". 542 This type defines an extendable sequence of the following child 543 elements: 545 5.2.1 display-text of string type 547 This element contains text description of the conference. 549 5.2.2 subject of string type 551 This element contains the subject of the conference. 553 5.2.3 free-text of string type 555 This element contains free form text about the conference. 557 5.2.4 keywords of keywords-type 559 This element contains a list of words that can be used by automatic 560 search engines to better classify the conference. 562 5.2.5 conf-uris of uris-type 564 This element contains a set of sub-elements - each containing 565 the information about an additional conference URI that this 566 conference can be accessed by. The value of the URI is included in 567 the sub-element and its description MAY be included in the 568 sub-element. 570 The purpose of the URI SHOULD be included in the 571 sub-element. The currently defined values to be used with 572 the are: 574 participation: Indicates that dialing into this URI will bring the 575 party into the conference 576 streaming: Indicates that "listening" to this URI will provide the 577 conference live content 579 Future extensions to this schema may define new values and register 580 them with IANA under the registry established by this specification. 582 Examples of such URIs include sip: / sips: [7], h323: [17], and tel: 584 [16] URIs. 586 5.2.6 service-uris of uris-type 588 This element contains a set of sub-elements - each containing 589 the URI to be used in order to access different services available 590 for the particular conference. The value of the URI is included in 591 the sub-element and its description MAY be included in the 592 sub-element. 594 The purpose of the URI SHOULD be included in the 595 sub-element. The currently defined values to be used with 596 the are: 598 web-page: Indicates the web page containing the additional 599 information about the conference 600 recording: Indicates the link at which the recorded conference 601 context can be retrieved 602 event: Indicates the URI to which the subscription to the conference 603 event package needs to be performed 605 Future extensions to this schema may define new values and register 606 them with IANA under the registry established by this specification. 608 5.2.7 maximum-user-count of user-count-type 610 This element, if used, specifies the maximum number of users 611 permitted in the conference and SHOULD include the counter for all 612 participants in the conference in total by populating the attribute 613 'role' with value "any". Counters for users with specific roles MAY 614 be additionally provided. 616 5.2.8 available-media of conference-media-type 618 This element contains information about the media streams with their 619 types available to the participants in the conference. The entries 620 in the container are of conference-medium-type and 621 are indexed by attribute 'id'. 623 5.3 host-type 625 This type defines the 'state' attribute which can contain the values 626 "full", "partial", or "deleted". 628 This type defines an extendable sequence of the following child 629 elements: 631 5.3.1 display-text of string type 633 This element contains display text information about the entity 634 hosting the conference. 636 5.3.2 web-page of anyURI type 638 This element contains a web page URI about the user hosting the 639 conference. 641 5.3.3 uris of uris-type 643 The sub-element contains additional URIs pointing to the 644 conference host. 646 5.4 conference-state-type 648 This type defines the 'state' attribute which can contain the values 649 "full", "partial", or "deleted". 651 This type defines an extendable sequence of the following child 652 elements. 654 5.4.1 user-count of user-count-type 656 This element is used to specify the current number of users in the 657 conference. The number SHOULD be provided for all participants in 658 total by populating the sub-element with value "any". 659 Additionally counters for users with certain roles in the conference 660 MAY be separately provided. 662 5.4.2 active of Boolean type 664 This element says whether the conference is currently active or not. 665 A conference is active if dialing into one of the results 666 in successful establishment of a call signaling session between the 667 dialed user and the conference focus. 669 5.4.3 locked of Boolean type 671 This element contains information about whether the conference is 672 currently locked. In this context, "locked" means that the 673 conference roster can not be added to (although participants may 674 leave or be removed from the conference). 676 5.4.4 active-media of conference-media-type 678 This element contains information about the media streams being 679 currently active in the conference, which is a subset of those listed 680 in the container. The entries in the 681 container are of conference-medium-type and are 682 indexed by attribute 'id'. 684 Note, that correlation between media streams in both containers is 685 achieved by matching the values of