idnits 2.17.1 draft-ietf-sipping-conference-package-06.txt: -(425): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1867. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1880. ** 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 33 longer pages, the longest (page 15) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 49 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 110 instances of too long lines in the document, the longest one being 207 characters in excess of 72. 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 (October 25, 2004) is 7122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 1794, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1816, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1820, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '4') ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (ref. '7') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3388 (ref. '9') (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '11') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '12') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2806 (ref. '13') (Obsoleted by RFC 3966) == 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-04 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-02 == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sdp-media-label-00 Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: April 25, 2005 H. Schulzrinne 4 Columbia University 5 O. Levin, Ed. 6 Microsoft Corporation 7 October 25, 2004 9 A Session Initiation Protocol (SIP) Event Package for Conference 10 State 11 draft-ietf-sipping-conference-package-06 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 25, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document defines a conference event package for the Session 47 Initiation Protocol (SIP) Events framework, along with a data format 48 used in notifications for this package. The conference package 49 allows users to subscribe to a conference URI. Notifications are 50 sent about changes in the membership of this conference and 51 optionally about changes in the state of additional conference 52 components. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Conference Event Package . . . . . . . . . . . . . . . . . . . 7 59 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 7 60 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 7 61 3.3 Subscription Duration . . . . . . . . . . . . . . . . . . 7 62 3.4 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8 63 3.5 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8 64 3.6 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 65 3.7 Subscriber Processing of NOTIFY Requests . . . . . . . . . 9 66 3.8 Handling of Forked Requests . . . . . . . . . . . . . . . 9 67 3.9 Rate of Notifications . . . . . . . . . . . . . . . . . . 9 68 3.10 State Agents . . . . . . . . . . . . . . . . . . . . . . . 9 69 4. Conference Data Model . . . . . . . . . . . . . . . . . . . . 11 70 5. Constructing Coherent State . . . . . . . . . . . . . . . . . 12 71 6. Conference Data . . . . . . . . . . . . . . . . . . . . . . . 14 72 6.1 Conference Information . . . . . . . . . . . . . . . . . . 14 73 6.1.1 Conference Type . . . . . . . . . . . . . . . . . . . 14 74 6.1.1.1 conference-description of 75 conference-description-type . . . . . . . . . . . 14 76 6.1.1.2 host-info of host-type . . . . . . . . . . . . . . 14 77 6.1.1.3 conference-state of conference-state-type . . . . 15 78 6.1.1.4 user of user-type . . . . . . . . . . . . . . . . 15 79 6.1.1.5 sidebars-by-ref of uris-type . . . . . . . . . . . 15 80 6.1.1.6 sidebar-by-val of conference-type . . . . . . . . 15 81 6.1.2 Conference Description Type . . . . . . . . . . . . . 15 82 6.1.2.1 display-text of string type . . . . . . . . . . . 15 83 6.1.2.2 subject of string type . . . . . . . . . . . . . . 15 84 6.1.2.3 free-text of string type . . . . . . . . . . . . . 15 85 6.1.2.4 keywords of keywords-type . . . . . . . . . . . . 16 86 6.1.2.5 web-page of anyURI type . . . . . . . . . . . . . 16 87 6.1.2.6 conf-uris of uris-type . . . . . . . . . . . . . . 16 88 6.1.2.7 service-uris of uris-type . . . . . . . . . . . . 16 89 6.1.2.8 maximum-user-count of user-count-type . . . . . . 16 90 6.1.2.9 available-media of conference-medias-type . . . . 16 91 6.1.3 Host Type . . . . . . . . . . . . . . . . . . . . . . 16 92 6.1.3.1 display-text of string type . . . . . . . . . . . 16 93 6.1.3.2 web-page of anyURI type . . . . . . . . . . . . . 17 94 6.1.3.3 uris of uris-type . . . . . . . . . . . . . . . . 17 95 6.1.4 Conference State Type . . . . . . . . . . . . . . . . 17 96 6.1.4.1 user-count of user-count-type . . . . . . . . . . 17 97 6.1.4.2 security-level of security-level-type . . . . . . 17 98 6.1.4.3 active of Boolean type . . . . . . . . . . . . . . 17 99 6.1.4.4 locked of Boolean type . . . . . . . . . . . . . . 17 100 6.1.4.5 recording of uris-type . . . . . . . . . . . . . . 17 101 6.1.4.6 active-media of conference-medias-type . . . . . . 18 102 6.1.5 User Type . . . . . . . . . . . . . . . . . . . . . . 18 103 6.1.5.1 display-text of string type . . . . . . . . . . . 18 104 6.1.5.2 associated-aors of anyURI type . . . . . . . . . . 18 105 6.1.5.3 roles of user-roles-type . . . . . . . . . . . . . 18 106 6.1.5.4 language of language type . . . . . . . . . . . . 19 107 6.1.5.5 cascaded-focus of anyURI type . . . . . . . . . . 19 108 6.1.5.6 endpoint of endpoint-type . . . . . . . . . . . . 19 109 6.1.6 Endpoint Type . . . . . . . . . . . . . . . . . . . . 19 110 6.1.6.1 display-text of string type . . . . . . . . . . . 20 111 6.1.6.2 referred of execution-type . . . . . . . . . . . . 20 112 6.1.6.3 state of endpoint-state-type . . . . . . . . . . . 20 113 6.1.6.4 joining-method of joining-type . . . . . . . . . . 21 114 6.1.6.5 joining-info of execution-type . . . . . . . . . . 21 115 6.1.6.6 disconnection-method of disconnection-type . . . . 22 116 6.1.6.7 disconnection-info of disconnection-type . . . . . 22 117 6.1.6.8 whispering-to of uris-type . . . . . . . . . . . . 22 118 6.1.6.9 media of media-type . . . . . . . . . . . . . . . 22 119 6.1.7 Media Type . . . . . . . . . . . . . . . . . . . . . . 23 120 6.1.7.1 display-text of string type . . . . . . . . . . . 23 121 6.1.7.2 proto of string type . . . . . . . . . . . . . . . 23 122 6.1.7.3 ssrc of string type . . . . . . . . . . . . . . . 23 123 6.1.7.4 label of string type . . . . . . . . . . . . . . . 24 124 6.1.7.5 state of media-state-type . . . . . . . . . . . . 24 125 6.1.7.6 snd-status of media-state-type . . . . . . . . . . 24 126 6.1.7.7 rcv-status state of media-state-type . . . . . . . 24 127 6.1.7.8 call of call-type . . . . . . . . . . . . . . . . 24 128 7. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 129 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 130 8.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 33 131 8.2 Rich Example . . . . . . . . . . . . . . . . . . . . . . . 35 132 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 133 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41 134 10.1 conference Event Package Registration . . . . . . . . . . 41 135 10.2 application/conference-info+xml MIME Registration . . . . 41 136 10.3 URN Sub-Namespace Registration for 137 urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 41 138 10.4 XML Schema Registration . . . . . . . . . . . . . . . . . 42 139 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 140 12. Changes History . . . . . . . . . . . . . . . . . . . . . . 44 141 12.1 Changes since -05 . . . . . . . . . . . . . . . . . . . . 44 142 12.2 Changes since -04 . . . . . . . . . . . . . . . . . . . . 44 143 12.3 Changes since -03 . . . . . . . . . . . . . . . . . . . . 44 144 12.4 Changes since -02 . . . . . . . . . . . . . . . . . . . . 44 145 12.5 Changes since -01 . . . . . . . . . . . . . . . . . . . . 45 146 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 147 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 46 148 13.2 Informative References . . . . . . . . . . . . . . . . . . . 46 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47 150 Intellectual Property and Copyright Statements . . . . . . . . 49 152 1. Introduction 154 The Session Initiation Protocol (SIP) [6] Events framework Events 155 Framework [7] defines general mechanisms for subscribing to, and 156 receiving notifications of, events within SIP networks. It 157 introduces the notion of a package, which is a specific 158 "instantiation" of the events framework for a well-defined set of 159 events. Here, we define an event package for SIP conferences. This 160 package provides the conference notification service as outlined in 161 the SIP conferencing framework [15]. As described there, 162 subscriptions to a conference URI are routed to the focus that is 163 handling the conference. It acts as the notifier, and provides 164 clients with updates on conference state. 166 The information provided by this package is comprised of conference 167 identifier(s), conference participants (optionally with their 168 statuses and media description), conference sidebars, conference 169 service URIs, etc. 171 2. Terminology 173 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 174 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 175 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 176 indicate requirement levels for compliant implementations. 178 3. Conference Event Package 180 The conference event package allows a user to subscribe to a 181 conference. In SIP, conferences are represented by URIs. These URIs 182 route to a SIP user agent, called a focus, that is responsible for 183 ensuring that all users in the conference can communicate with each 184 other, as described in Conferencing Framework [15]. The focus has 185 sufficient information about the state of the conference to inform 186 subscribers about it. 188 It is possible a participant in the conference may in fact be another 189 focus. In order to provide a more complete participant list, the 190 focus MAY subscribe to the conference package of the other focus to 191 discover the participant list in the cascaded conference. This 192 information can then be included in notifications by using of the 193 "cascaded-focus" element as specified by this package. 195 This section provides the details for defining a SIP Events package, 196 as specified by RFC 3265 [7]. 198 3.1 Event Package Name 200 The name of this event package is "conference". This package name is 201 carried in the Event and Allow-Events header, as defined in RFC 3265 202 [7]. 204 3.2 SUBSCRIBE Bodies 206 A SUBSCRIBE for a conference package MAY contain a body. This body 207 defines a filter to apply to the subscription. Filter documents are 208 not specified in this document, and at the time of writing, are 209 expected to be the subject of future standardization activity. 211 A SUBSCRIBE for a conference package MAY be sent without a body. 212 This implies the default subscription filtering policy. The default 213 policy is: 214 o Notifications are generated every time there is any change in the 215 state of the conference. 216 o Notifications do not normally contain full state; rather, they 217 only indicate the state that has changed. The exception is a 218 NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the 219 full state of the information requested by the subscriber. 221 3.3 Subscription Duration 223 The default expiration time for a subscription to a conference is one 224 hour. Once the conference ends, all subscriptions to that particular 225 conference are terminated, with a reason of "noresource" RFC 3265 227 [7]. 229 3.4 NOTIFY Bodies 231 As described in RFC 3265 [7], the NOTIFY message will contain bodies 232 that describe the state of the subscribed resource. This body is in 233 a format listed in the Accept header field of the SUBSCRIBE, or a 234 package-specific default if the Accept header field was omitted from 235 the SUBSCRIBE. 237 In this event package, the body of the notification contains a 238 conference information document. This document describes the state 239 of a conference. All subscribers and notifiers MUST support the 240 "application/conference-info+xml" data format described in Section 6. 241 The subscribe request MAY contain an Accept header field. If no such 242 header field is present, it has a default value of 243 "application/conference-info+xml". If the header field is present, 244 it MUST include "application/conference-info+xml", and MAY include 245 any other types. 247 Of course, the notifications generated by the server MUST be in one 248 of the formats specified in the Accept header field in the SUBSCRIBE 249 request. 251 3.5 Notifier Processing of SUBSCRIBE Requests 253 The conference information contains very sensitive information. 254 Therefore, all subscriptions SHOULD be authenticated and then 255 authorized before approval. Authorization policy is at the 256 discretion of the administrator, as always. However, a few 257 recommendations can be made. 259 It is RECOMMENDED that all users in the conference be allowed to 260 subscribe to the conference. 262 3.6 Notifier Generation of NOTIFY Requests 264 Notifications MUST be generated for the conference state when a new 265 participant joins (i.e. gets "connected" to) or a participant leaves 266 (i.e. gets "disconnected" from) the conference. 268 Subject to a local focus policy, additional changes in participants' 269 status, changes in their media types, and other optional information 270 MAY be reported by the focus. 272 Changes in sidebar rosters SHOULD be reported by the focus to their 273 participants and MAY be reported to others, subject to local policy. 275 Changes in conference identifiers and service URIs SHOULD be reported 276 by the focus to the Conference package subscribers. 278 Changes in other conference state information MAY be reported by the 279 focus to the Conference package subscribers. 281 3.7 Subscriber Processing of NOTIFY Requests 283 The SIP Events framework expects packages to specify how a subscriber 284 processes NOTIFY requests in any package specific ways, and in 285 particular, how it uses the NOTIFY requests to construct a coherent 286 view of the state of the subscribed resource. 288 Typically, the NOTIFY for the conference package will only contain 289 information about those users whose state in the conference has 290 changed. To construct a coherent view of the total state of all 291 users, a subscriber to the conference package will need to combine 292 NOTIFYs received over time. 294 Notifications within this package can convey partial information; 295 that is, they can indicate information about a subset of the state 296 associated with the subscription. This means that an explicit 297 algorithm needs to be defined in order to construct coherent and 298 consistent state. The details of this mechanism are specific to the 299 particular document type. See Section 5 for information on 300 constructing coherent information from an 301 application/conference-info+xml document. 303 3.8 Handling of Forked Requests 305 By their nature, the conferences supported by this package are 306 centralized. Therefore, SUBSCRIBE requests for a conference should 307 not generally fork. Users of this package MUST NOT install more than 308 a single subscription as a result of a single SUBSCRIBE request. 310 3.9 Rate of Notifications 312 For reasons of congestion control, it is important that the rate of 313 notifications not become excessive. As a result, it is RECOMMENDED 314 that the server not generate notifications for a single subscriber at 315 a rate faster than once every 5 seconds. 317 3.10 State Agents 319 Conference state is ideally maintained in the element in which the 320 conference resides. Therefore, the elements that maintain the 321 conference are the ones best suited to handle subscriptions to it. 322 Therefore, the usage of state agents is NOT RECOMMENDED for this 323 package. 325 4. Conference Data Model 327 Conference information is an XML document that MUST be well-formed 328 and SHOULD be valid. Dialog information documents MUST be based on 329 XML 1.0 and MUST be encoded using UTF-8. This specification makes 330 use of XML namespaces for identifying dialog information documents 331 and document fragments. The namespace URI for elements defined by 332 this specification is a URN [3], using the namespace identifier 333 'ietf' defined by [4] and extended by [1]. This URN is: 335 The conference information is described by a hierarchal XML structure 336 with the root element "conference-info". The root element is the 337 only element in the schema that carries meaningful version number for 338 all the elements in the document. The whole conference information 339 is associated with this version number. 341 All sub-elements in the "conference-info" hierarchal XML structure 342 can be classified in two groups: those that carry relatively small 343 amount of data and those that can potentially carry a lot of data. 344 During partial notifications, the light elements are updated as 345 atomic pieces of data. On the other hand, elements that can carry a 346 substantial amount of data have the general "state" attribute 347 attached to them. That is in order to support partial notifications 348 for their content. 350 A "state" attribute of a child element in the document MUST adhere to 351 its parent "state". It means that if the parent's "state" is "full", 352 the state of its children MUST be "full". If the parent's "state" is 353 "partial", the state of its children MAY be either "partial", "full", 354 or "deleted". 356 For elements with the optional "state" attribute, if the attribute is 357 omitted from the notification for the element, it means that the 358 reported element's state is "full". 360 All sub-elements, with possible multiple appearances under a common 361 parent, have keys defined to them in order to uniquely identify each 362 element among others of the same type in the partial notification 363 event. 365 5. Constructing Coherent State 367 A Conference package subscriber MUST initialize the "version" 368 attribute from the "conference-info" element with the value in the 369 first document received. 371 The conference package subscriber locally maintains a local element 372 for each element in the schema and a table for each element with 373 key(s) in the schema and indexed by these key(s). 375 Each time a new NOTIFY is received, the value of the local version 376 number and the "version" attribute in the new received document are 377 compared. If the value in the new document is one higher than the 378 local version number, the local version number is increased by one, 379 and the document is processed. If the value in the document is more 380 than one higher than the local version number, the local version 381 number is set to the value in the new document, the document is 382 processed, and the subscriber SHOULD generate a refresh request to 383 trigger a full state notification. If the value in the document is 384 less than the local version, the document is discarded without 385 processing. 387 Further processing of the conference information document depends on 388 whether it contains full or partial state. If it contains full 389 state, indicated by the value of the "state" attribute in the 390 "conference-info" element, the whole local content is flushed and 391 repopulated from the document. If it contains "deleted" state, 392 indicated by the value of the "state" attribute in the 393 "conference-info" element, it means that the conference ceased to 394 exist and the subscriber SHOULD terminate the SUBSCRIBE dialog. 396 If the document contains partial state, as indicated by the value of 397 the "state" attribute in the "conference-info" element, the document 398 is used to update the local content as described below. 400 Starting from outer elements in the received document, 402 1. If the parent element contains "full" state, the whole local 403 element content is flushed and repopulated from the document. 405 2. Otherwise, if the parent element contains "deleted" state, the 406 whole element MUST be removed from the local content. 408 3. Otherwise, if the parent element contains "partial" state: 410 3.1 For elements with keys, the subscriber compares the keys received 411 in the update with the keys in the local tables. 413 3.1.1 If a key does not exist in the local table, a row is added, and 414 its content is set to the element information from the update. 416 3.1.2 Otherwise, if a key of the same value does exist, for each 417 sub-element in the row the algorithm is applied from step 2.2. 419 3.2 For each atomic element received in the schema, the element is 420 replaced with the new information as a whole. Also, for each 421 non-atomic element received in the schema with either no "state" 422 attribute included or the state attribute is set to "full", the 423 element is replaced with the new information as a whole. 425 3.2.1 If an element, which doesn�t have key(s), is updated or created 426 such that its content is empty, that element MAY be removed from the 427 local content at any time. 429 3.3 For each non-atomic element with the state attribute set to 430 "partial", the algorithm is applied recursively starting from step 3. 432 6. Conference Data 434 urn:ietf:params:xml:ns:conference-info 436 A conference information document begins with the root element tag 437 "conference-info". 439 6.1 Conference Information 441 A conference instance is defined as a top level element 442 "conference-info" of a type "conference-type". Sections below 443 describe the complex types composing the hierarchal 444 "conference-type". The full XML schema is defined in Section 7. 446 6.1.1 Conference Type 448 This type has the following attributes: 450 version: This mandatory attribute allows the recipient of conference 451 information documents to properly order them. Versions start at 0 452 and increment by one for each new document sent to a subscriber. 453 Versions are scoped within a subscription. Versions MUST be 454 represented using a 32 bit integer. 456 entity: This mandatory attribute contains the conference URI that 457 identifies the conference being described in the document. 459 state: This mandatory attribute indicates whether the document 460 contains the whole conference information ("full"), only the 461 information that has changed since the previous document 462 ("partial"), or the conference ceased to exist ("deleted"). For 463 more details see Section 5. 465 This type defines an extendable sequence of the following optional 466 child elements: 468 6.1.1.1 conference-description of conference-description-type 470 This element contains conference information that is derived from 471 system conference policies, is set before the conference activation, 472 and is rarely changed during the conference lifetime. 474 6.1.1.2 host-info of host-type 476 This element contains information about the entity that hosts the 477 conference. This information is set before the conference 478 activation, and is rarely changed during the conference lifetime, 479 unless the whole conference is moved to be hosted by another entity. 481 6.1.1.3 conference-state of conference-state-type 483 This element contains the dynamic information about the current state 484 of the focus. 486 6.1.1.4 user of user-type 488 This element contains the information about a participant in the 489 conference. The element of the user-type can have unbounded number 490 of appearance in the conference-type for each participant in the 491 conference. 493 6.1.1.5 sidebars-by-ref of uris-type 495 This element provides a pointer to sidebar information through 496 sidebar URIs. The recipient of the information can then subscribe to 497 sidebar information independently from the main Conference package 498 subscription. 500 6.1.1.6 sidebar-by-val of conference-type 502 This element provides sidebar information as a part of the main 503 Conference package information. 505 6.1.2 Conference Description Type 507 This element contains the "state" attribute which can contain the 508 values "full", "partial", or deleted". 510 This type defines an extendable sequence of the following optional 511 child elements: 513 6.1.2.1 display-text of string type 515 This element contains text information about the conference. 517 6.1.2.2 subject of string type 519 This element contains information about the subject of a conference. 521 6.1.2.3 free-text of string type 523 This element contains free form text about the conference. 525 6.1.2.4 keywords of keywords-type 527 This element contains a list of keywords which describe the 528 conference topic. 530 6.1.2.5 web-page of anyURI type 532 This element contains a URI of a web page that contains information 533 related to the conference. 535 6.1.2.6 conf-uris of uris-type 537 This element contains information about additional conference URIs 538 that this conference can be accessed by. Examples of such URIs 539 include h323: [14] and tel: [13] URIs. 541 6.1.2.7 service-uris of uris-type 543 This element contains the service-related URIs. These URIs can be 544 used to manipulate the conference policies or state, for example. 546 6.1.2.8 maximum-user-count of user-count-type 548 This element contains a count of the maximum number of users 549 permitted in the conference. The count can be specified for all 550 participants in total (using the sub-element with value "any") or 551 count the users by their roles in the conference. 553 6.1.2.9 available-media of conference-medias-type 555 This element contains information about the media types available in 556 a conference. The "entry" sub-element MUST be a value registered for 557 "proto" of SDP [12]. 559 6.1.3 Host Type 561 This element contains the "state" attribute which can contain the 562 values "full", "partial", or deleted". 564 This type defines an extendable sequence of the following optional 565 child elements: 567 6.1.3.1 display-text of string type 569 This element contains display text information about the user hosting 570 the conference. 572 6.1.3.2 web-page of anyURI type 574 This element contains a web page URI about the user hosting the 575 conference. 577 6.1.3.3 uris of uris-type 579 The "entity" sub-element contains additional URIs relating to the 580 user hosting the conference. 582 6.1.4 Conference State Type 584 This element contains the "state" attribute which can contain the 585 values "full", "partial", or deleted". 587 This type defines an extendable sequence of the following optional 588 child elements. 590 6.1.4.1 user-count of user-count-type 592 This element contains a count of the current number of users in the 593 conference. The count can be specified for all participants in total 594 (using the sub-element with value "any") or count the users by their 595 roles in the conference. 597 6.1.4.2 security-level of security-level-type 599 This element contains information about the conference security 600 level. The values can be "none", "low", "medium", or "high". 602 6.1.4.3 active of Boolean type 604 This element contains information about whether the conference is 605 currently active or not. 607 6.1.4.4 locked of Boolean type 609 This element contains information about whether the conference is 610 currently locked. In this context, locked means that the conference 611 roster can not be added to (although participants may leave or be 612 removed from the conference). 614 6.1.4.5 recording of uris-type 616 The "entry" sub-element contains URIs related to the recording of the 617 conference. 619 6.1.4.6 active-media of conference-medias-type 621 This element contains information about the media types currently 622 active in the conference which is a subset of those listed in the 623 "available-media" element. 625 6.1.5 User Type 627 This type has the following attributes: 629 entity: The mandatory attribute contains the URI for the user in the 630 conference. This is a logical identifier, which corresponds to 631 the authenticated identity of the participant. The "entity" 632 attribute MUST be unique in the user element list because it is 633 used as the key in partial notifications about users' state. An 634 anonymous participant in a conference SHOULD be represented by an 635 anonymous URI generated by the focus. For multiple anonymous 636 participants, the focus must ensure that each anonymous URI is 637 unique. The guidelines for generating anonymous URIs in RFC 3323 638 [8] should be followed. For example, 640 "Anonymous1" 642 could be used for a participant requesting privacy. 644 state: This mandatory attribute indicates whether the document 645 contains the whole conference information ("full"), only the 646 information that has changed since the previous document 647 ("partial"), or the conference ceased to exist ("deleted"). 649 This type defines an extendable sequence of the following optional 650 child elements. 652 6.1.5.1 display-text of string type 654 This element contains the display text for the user. 656 6.1.5.2 associated-aors of anyURI type 658 This element contains associated URIs of the user. Usually this 659 information will be manually provided by a system administrator 660 showing the logical association between signaling entities otherwise 661 independent. 663 6.1.5.3 roles of user-roles-type 665 This element contains the roles of the user. 667 6.1.5.4 language of language type 669 This element contains the language used by the user. 671 6.1.5.5 cascaded-focus of anyURI type 673 This element contains a conference URI (different from the main 674 conference URI) for users that are connected to the main conference 675 as a result of focus cascading. In accordance with the SIP 676 conferencing framework [15], this package allows for representation 677 of peer-to-peer (i.e. "flat") focus cascading only. The actual 678 cascading graph can not be deduced from the information provided in 679 the package alone. Advanced applications can construct the graph by 680 subscribing to both this package and the Dialog Package [16] of the 681 cascaded foci and correlating the relevant information. 683 6.1.5.6 endpoint of endpoint-type 685 This element contains information about an endpoint of the user. The 686 element of the endpoint-type can have unbounded number of appearance 687 in the user-type for each endpoint of the user participating in the 688 conference. In a case when authentication is performed per endpoint 689 (rather than per user) in a system, a focus can be not aware of the 690 logical association among endpoints being used by the same user. In 691 this case the focus MAY present the endpoints as belonging to 692 separate users in the conference schema. 694 In a different case, due to privacy concerns for a user the focus may 695 want to shield the information about multiple endpoints from the 696 recipients of the Conference document. To do so the focus MAY 697 aggregate the multiple endpoint information into a single endpoint 698 element under this user. 700 6.1.6 Endpoint Type 702 This type has the following attributes: 704 entity: The mandatory attribute contains the endpoint URI for the 705 user in the conference. In SIP terms, this is the Contact URI or 706 GRUU. The "entity" attribute MUST be unique in the endpoint 707 element list because it is used as the key in partial 708 notifications about users' endpoints. An anonymous participant in 709 a conference SHOULD be represented by an anonymous URI generated 710 by the focus. For multiple anonymous participants, the focus must 711 ensure that each anonymous URI is unique. The guidelines for 712 generating anonymous URIs in RFC 3323 [8] should be followed. 714 state: This mandatory attribute indicates whether the element 715 contains the whole endpoint information ("full"), only the 716 information that has changed since the previous document 717 ("partial"), or the endpoint has been deleted from the conference 718 ("deleted"). 720 This type defines an extendable sequence of the following optional 721 child elements. 723 6.1.6.1 display-text of string type 725 This element contains the display text for the endpoint. 727 6.1.6.2 referred of execution-type 729 This element contains the URI of the user who's action resulted in 730 this endpoint being brought into the conference (e.g. the user 731 identified by this URI sent a REFER to the focus). 733 6.1.6.3 state of endpoint-state-type 735 This element contains the state of the endpoint, and can assume the 736 following values: 738 connected: The endpoint is a participant in the conference. 739 Depending on the media policies, he/she can send and receive media 740 to and from other participants. 742 disconnected: The endpoint is not a participant in the conference and 743 no active dialog exists between the endpoint and the focus. 745 on-hold: Active SIP dialog exists between an endpoint and a focus, 746 but endpoint is "on-hold" for this conference, i.e. neither 747 he/she is "hearing" the conference mix, nor is his/her media being 748 mixed in the conference. As an example, the endpoint has asked to 749 join the conference using SIP, but his/her participation is 750 pending based on moderator approval. In the meantime he/she is 751 hearing music-on-hold or some other kind of related content. 753 muted-via-focus: Active SIP dialog exists between an endpoint and a 754 focus and the endpoint can "listen" to the conference, but 755 endpoint's media is not being mixed into the conference. Note 756 that sometimes a subset of endpoint media streams can be muted by 757 focus (such as poor quality video) while others (such as voice or 758 IM) can still be active. In this case, it is RECOMMENDED that the 759 "aggregated" endpoint connectivity "status" reflects the status of 760 the mostly active media. 762 pending: Endpoint is not yet in the session, but it is anticipated 763 that he/she will join in the near future. 765 alerting: A PSTN ALERTING or SIP 180 Ringing was returned for the 766 outbound call, endpoint is being alerted. 768 dialing-in: Endpoint is dialing into the conference, not yet in the 769 roster (probably being authenticated). 771 dialing-out: Focus has dialed out to connect the endpoint to the 772 conference, but the endpoint is not yet in the roster (probably 773 being authenticated). 775 disconnecting: Focus is in the process of disconnecting endpoint 776 (either DISCONNECT or BYE was sent to the endpoint's device). 778 Note that the defined transient states (e.g., disconnecting, 779 alerting, etc.) could generate a lot of notifications. 780 Implementations MAY choose not to generate notifications on these to 781 all participants if it will generate too much traffic. 783 6.1.6.4 joining-method of joining-type 785 This element contains method by which the endpoint joined the 786 conference, and can assume the following values: 788 dialed-in: The endpoint dialed into the conference, i.e. sent INVITE 789 to the focus, which resulted in successful dialog establishment. 791 dialed-out: The focus has brought the endpoint into the conference by 792 sending a successful INVITE to the endpoint. 794 focus-owner: The endpoint is the focus for this conference. This 795 status is used only when a participant UA acts as a conference 796 focus. 798 6.1.6.5 joining-info of execution-type 800 This element contains information about how the endpoint joined and 801 can contain the following sub-elements: 803 when: This element contains the date and time that the endpoint 804 joined the conference. 806 reason: This element contains the reason the endpoint joined the 807 conference. 809 by: This element contains the URI of the entity who caused the 810 endpoint to join the conference. 812 6.1.6.6 disconnection-method of disconnection-type 814 This element contains method by which the endpoint departed the 815 conference, and can assume the following values: 817 departed: The endpoint sent a BYE, thus leaving the conference. 819 booted: The endpoint was sent a BYE by the focus, booting him/her out 820 of the conference. Alternatively, the endpoint tried to dial into 821 to conference without success because was rejected by the focus 822 according to local policy decisions. 824 failed: The server tried to bring the endpoint into the conference, 825 but its attempt to contact the specific endpoint resulted in a 826 non-200 class final response. Alternatively, the endpoint tried 827 to dial into the conference without success due to technical 828 reasons. 830 6.1.6.7 disconnection-info of disconnection-type 832 This element contains information about the endpoint's departure from 833 the conference and can contain the following sub-elements: 835 when: This element contains the date and time that the endpoint 836 departed the conference. 838 reason: This element contains the reason the endpoint departed the 839 conference. 841 by: This element contains the URI of the entity who caused the 842 endpoint to depart the conference. 844 6.1.6.8 whispering-to of uris-type 846 If an endpoint is participating in a whisper session with other 847 entities, the URIs of these other entities MAY be contained in this 848 element. 850 6.1.6.9 media of media-type 852 This element contains information about a media stream of this 853 endpoint. The element of the media-type can have unbounded number of 854 appearance in the endpoint-type for each media stream of the 855 endpoint. Note that it is possible that media streams listed under a 856 common endpoint MAY be established by separate signaling means and 857 consequently belong to different signaling "calls". 859 6.1.7 Media Type 861 This type has the following attributes: 863 entity: The mandatory attribute is a unique identifier of a media 864 stream on a per endpoint basis. This attribute is used as a key 865 to identify media streams which may be added and deleted on a 866 dynamic basis during the conference. The value of this element 867 SHOULD correspond to the "mid" value in the SDP document as 868 defined in Grouping of Media Lines in the SDP [9]. 870 state: This mandatory attribute indicates whether the element 871 contains the whole media information ("full"), only the 872 information that has changed since the previous document 873 ("partial"), or the media element has been deleted from the 874 conference document ("deleted"). 876 This type defines an extendable sequence of the following optional 877 child elements. 879 6.1.7.1 display-text of string type 881 This element contains the display text for the media stream. 883 6.1.7.2 proto of string type 885 This element contains the media type for the media stream. The value 886 of this element MUST be a value registered for "proto" of SDP [12]. 888 6.1.7.3 ssrc of string type 890 The "ssrc" element carries the value of SSRC (defined in RTP/RTCP 891 [10]) as generated by the endpoint for the stream it sends. When an 892 RTP mixer generates a CSRC list according to RTP/RTCP [10], it 893 inserts a list of the SSRC identifiers of the sources that 894 contributed to the generation of a particular packet into the RTP 895 header of that packet. "An example application is audio conferencing 896 where a mixer indicates all the talkers whose speech was combined to 897 produce the outgoing packet, allowing the receiver to indicate the 898 current talker, even though all the audio packets contain the same 899 SSRC identifier (that of the mixer)." 901 6.1.7.4 label of string type 903 The element "label" carries a unique identifier for this stream among 904 all streams in the conference and is assigned by the focus. The 905 value of this element corresponds to the "label" media attribute in 906 SDP [12] and defined in [19]. 908 6.1.7.5 state of media-state-type 910 The element "state" contains the state of the media stream and can 911 have the values "active", "inactive", or "muted". 913 6.1.7.6 snd-status of media-state-type 915 The element "state" contains the state of the sending media stream 916 (from the perspective of the endpoint) and can have the values 917 "active", "inactive", or "muted". 919 6.1.7.7 rcv-status state of media-state-type 921 The element "state" contains the state of the receiving media stream 922 (from the perspective of the endpoint) and can have the values 923 "active", "inactive", or "muted". 925 6.1.7.8 call of call-type 927 The "call" element contains the "sip" sub-element which contains the 928 SIP dialog identifier of the endpoint's dialog with the focus. The 929 "sip" element includes sub-elements "display-text", "call-id", 930 "to-tag", "from-tag" 932 7. Schema 934 935 936 939 941 944 945 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 966 967 968 969 970 971 972 973 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1023 1024 1025 1027 1028 1029 1030 1031 1034 1035 1036 1037 1038 1039 1040 1041 1044 1045 1046 1047 1049 1050 1051 1052 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1067 1068 1069 1070 1071 1072 1073 1074 1077 1078 1079 1080 1081 1082 1083 1084 1085 1088 1089 1090 1091 1092 1093 1094 1095 1096 1099 1100 1101 1102 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1122 1123 1124 1125 1126 1127 1128 1129 1132 1133 1134 1135 1136 1137 1138 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1152 1153 1154 1155 1156 1157 1158 1159 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1178 1179 1180 1182 1183 1184 1185 1186 1189 1190 1191 1192 1193 1194 1195 1196 1199 1200 1201 1202 1203 1204 1205 1206 1207 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1229 1230 1231 1232 1233 1234 1235 1236 1239 1240 1241 1242 1243 1244 1245 1246 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1262 1263 1264 1265 1266 1268 1269 1271 8. Examples 1273 8.1 Basic Example 1275 The following is an example conference information document: 1277 1278 1281 1282 Agenda: This month's target 1283 1284 1285 http://salesgroup.example.com/conference-policies/sales-weekly-meeting.xml 1286 1287 1288 1289 1290 1293 1294 1295 1296 1297 1298 1299 33 1300 1301 1302 1303 1304 audio 1305 1306 1307 1309 1312 1313 Bob Hoskins 1314 1317 1318 Bob's Laptop 1319 disconnected 1320 departed 1321 1322 2005-03-04T20:00:00Z 1323 bad voice quality 1324 sip:mike@example.com 1325 1327 1330 1331 main audio 1332 audio 1333 432424 1334 1335 active 1336 1337 1338 1340 1343 1344 Alice 1345 1348 1349 connected 1350 dialed-out 1351 1353 2005-03-04T20:00:00Z 1354 sip:mike@example.com 1355 1356 1359 1360 main audio 1361 audio 1362 534232 1363 1364 active 1365 1367 1368 1369 1371 8.2 Rich Example 1373 The following is an example conference information document. In this 1374 example of a partial state notification, there are 32 participants in 1375 a voice conference. The user Bob has been booted from the conference 1376 by Mike due to bad voice quality. Note that there are three sidebars 1377 in the conference, two are referenced just by their sidebar URI and 1378 information about the third sidebar is included in this notification. 1379 Also note that while this conference offers both audio and video 1380 capabilities, only audio is currently in use. 1382 1383 1386 1387 Weekly Sales Meeting 1388 Agenda: This month's target 1389 xyz 1390 sales, meeting, weekly 1391 http://sharepoint/salesgroup/ 1392 1393 1394 tel:+18005671234 1395 1396 1397 1398 h323:conf545@h323.example.com 1399 1400 1401 1402 1403 http://salesgroup.example.com/conference-policies/sales-weekly-meeting.xml 1404 1405 1406 1407 1408 1409 1410 1411 1412 52 1414 1415 1416 1417 1418 1419 50 1420 1421 1422 1423 1424 audio 1425 1426 1427 video 1428 1429 1430 1431 1434 1435 Sales Host 1436 http://sharepoint/salesgroup/hosts/ 1437 1438 1439 sip:sales@example.com 1440 1441 1442 1443 1446 1447 1448 1449 1450 1451 1452 33 1453 1454 1455 1456 1457 1458 32 1459 1460 1461 medium 1462 true 1463 false 1464 1465 1466 http://quicktime.streaming.com/54634/recording.mov 1467 1468 1469 1470 http://real.streaming.com/54634/recording.ram 1471 1472 1473 1474 1475 audio 1476 1477 1478 1480 1483 1484 Bob Hoskins 1485 1486 1487 mailto:bob@example.com 1488 1489 1490 1491 1492 1493 1494 1495 1496 en 1497 1500 1501 Bob's Laptop 1502 1503 2005-03-04T20:00:00Z 1504 sip:mike@example.com 1505 1506 disconnecting 1507 1508 1509 sip:rob@example.com 1511 1512 1513 sip:helen@example.com 1514 1515 1516 dialed-out 1517 1518 2005-03-04T20:00:00Z 1519 invitation 1520 sip:mike@example.com 1521 1522 booted 1523 1524 2005-03-04T20:00:00Z 1525 bad voice quality 1526 sip:mike@example.com 1527 1529 1532 1533 main audio 1534 audio 1535 432424 1536 1537 active 1538 1539 1540 full info 1541 hsjh8980vhsb78 1542 vav738dvbs 1544 8954jgjg8432 1545 1546 1547 1549 1551 1553 1556 1557 1558 sips:conf233@example.com; grid=45 1559 1560 1561 1562 sips:conf233@example.com; grid=21 1563 1564 1565 1566 1569 1570 1571 1572 1573 1575 1577 9. Security Considerations 1579 Subscriptions to conference state can reveal very sensitive 1580 information. For this reason, the document recommends authentication 1581 and authorization, and provides guidelines on sensible authorization 1582 policies. 1584 Since the data in notifications is sensitive as well, end-to-end SIP 1585 encryption mechanisms using S/MIME SHOULD be used to protect it. 1587 Since a focus provides participants identity information using this 1588 event package, participant privacy needs to be taken into account. A 1589 focus MUST support requests by participants for privacy. Privacy can 1590 be indicated by the conference policy - for every participant or 1591 select participants. It can also be indicated in the session 1592 signaling. In SIP this can be done using the Privacy header field 1593 described in RFC 3323 [8]. For a participant requesting privacy, no 1594 identity information SHOULD be revealed by the focus such as a URI 1595 (e.g. the Address of Record, Contact, or GRUU). For these cases, 1596 the anonymous URI generation method outlined in section "User 1597 Element" of this document MUST be followed. 1599 10. IANA Considerations 1601 This document registers a SIP event package, a new MIME type, 1602 application/conference-info+xml, a new XML namespace, and a new XML 1603 schema. 1605 10.1 conference Event Package Registration 1607 This specification registers an event package, based on the 1608 registration procedures defined in RFC 3265 [7]. The following is 1609 the information required for such a registration: 1610 Package Name: conference 1611 Package or Template-Package: This is a package. 1612 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX 1613 with the RFC number of this specification). 1614 Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net. 1616 10.2 application/conference-info+xml MIME Registration 1617 MIME media type name: application 1618 MIME subtype name: conference-info+xml 1619 Mandatory parameters: none 1620 Optional parameters: Same as charset parameter application/xml as 1621 specified in RFC 3023 [5]. 1622 Encoding considerations: Same as encoding considerations of 1623 application/xml as specified in RFC 3023 [5]. 1624 Security considerations: See Section 10 of RFC 3023 [5] and Section 9 1625 of this specification. 1626 Interoperability considerations: none. 1627 Published specification: This document. 1628 Applications which use this media type: This document type has been 1629 used to support SIP conferencing applications. 1630 Additional Information: 1631 Magic Number: None 1632 File Extension: .cif or .xml 1633 Macintosh file type code: "TEXT" 1634 Personal and email address for further information: Jonathan 1635 Rosenberg, 1636 Intended usage: COMMON 1637 Author/Change controller: The IETF. 1639 10.3 URN Sub-Namespace Registration for 1640 urn:ietf:params:xml:ns:conference-info 1642 This section registers a new XML namespace, as per the guidelines in 1643 [1]. 1645 URI: The URI for this namespace is 1646 urn:ietf:params:xml:ns:conference-info. 1647 Registrant Contact: IETF, SIPPING working group, , 1648 Jonathan Rosenberg . 1649 XML: 1651 BEGIN 1652 1653 1655 1656 1657 1659 Conference Information Namespace 1660 1662

Namespace for Conference Information

1663

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

1664

See RFCXXXX.

1665 1666 1667 END 1669 10.4 XML Schema Registration 1671 This specification registers a schema, as per the guidelines in in 1672 [1]. 1673 URI: please assign. 1674 Registrant Contact: IETF, SIPPING Working Group 1675 (sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). 1676 XML: The XML can be found as the sole content of Section 7. 1678 11. Acknowledgements 1680 The authors would like to thank Dan Petrie, Sean Olson, Alan 1681 Johnston, and Rohan Mahy for their comments and inputs. 1683 12. Changes History 1685 12.1 Changes since -05 1686 o General schema clean-up. 1687 o Definition of common types being used by multiple elements. 1688 o Introduction of an "endpoint" element as a part of hierarchy: 1689 user/endpoint/media. 1691 12.2 Changes since -04 1692 o 1693 o "Sidebar-type" has been removed. "Sidebar" conference element is 1694 defined using the general "conference-type". 1695 o "Recording" conference attribute has been replaced with 1696 "recording" and "streaming" elements within "conference-type". 1697 New "recording-type" and "streaming-type" have been introduced. 1698 o Attribute "state" has been added to "user-type". 1699 o Element "media-stream" within "user-type" has been renamed to 1700 "media". 1701 o Element "role" within "user-type" has been introduced. 1702 o The following statuses have been added to "user-status-type": 1703 blocked, pending, calling, ringing, dialing-in, disconnecting, 1704 removed. 1705 o User status "muted-by-focus" has been renamed to 1706 "muted-via-focus". 1707 o Attributes "id" and "state" have been added to "media-type". 1708 o Elements "status", "snd-status" and "rcv-status" have been added 1709 to "media-type". 1710 o Element "dialog-id" has been renamed to "instance". 1711 o "Constructing Coherent State" section has been updated to include 1712 user and media partial notifications. 1714 12.3 Changes since -03 1715 o "Constructing Coherent State" section has been updated. 1716 o In order to support partial notifications, two placeholders 1717 "conference-ids" and "policy-ids" (for "conf-uri" and "policy-uri" 1718 elements, correspondingly) are created. 1719 o Discussion and security considerations regarding anonymous 1720 participation have been added. 1721 o Optional elements "dialog-uri", "info" and "label" per media 1722 stream are added. 1724 12.4 Changes since -02 1725 o State "muted-by-focus" is added to user's status. 1726 o Optional conference attribute "recording" is added. 1727 o Policy URI placeholder (i.e. element "policy-uri") is created. 1728 o Example's syntax is corrected. 1729 o Optional attribute "cascaded-focus" URI per user is added. 1731 o Optional additional conference identifiers (i.e. element 1732 "conf-uri") are added. 1733 o In order to cover all possible cases, participant's status is 1734 expressed using three optional statuses: "status", "joining-mode" 1735 and "disconnection-reason". That is instead of "activity-status", 1736 "history-status" and "is-on-dial-out-list". 1738 12.5 Changes since -01 1739 o Package parameters are removed. Decision about performing 1740 "recursive" membership algorithm is perceived as a focus local 1741 policy. 1742 o General information (i.e. pointers to additional available 1743 services) is removed. The defined XML schema can be extended in 1744 future to include those when XCON work matures. 1745 o Dialog information is removed. It can be obtained by direct 1746 subscription to a dialog package of a participant. 1747 o Media stream information is aligned with SDP definitions (media 1748 and proto) and SSRC attribute is added. 1749 o Participant's status is expressed using two optional statuses: 1750 "activity" and "history". Optional "is-on-a-dial-out-list" 1751 indication is added. 1752 o Normative references to XCON work are removed. 1753 o Optional sidebar rosters are added. 1755 13. References 1757 13.1 Normative References 1759 [1] Mealling, M., "The IETF XML Registry", 1760 draft-mealling-iana-xmlns-registry-05 (work in progress), June 1761 2003. 1763 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1764 Levels", BCP 14, RFC 2119, March 1997. 1766 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 1768 [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1769 August 1999. 1771 [5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1772 3023, January 2001. 1774 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1775 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1776 Session Initiation Protocol", RFC 3261, June 2002. 1778 [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1779 Notification", RFC 3265, June 2002. 1781 [8] Peterson, J., "A Privacy Mechanism for the Session Initiation 1782 Protocol (SIP)", RFC 3323, November 2002. 1784 [9] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, 1785 "Grouping of Media Lines in the Session Description Protocol 1786 (SDP)", RFC 3388, December 2002. 1788 [10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1789 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1790 RFC 3550, July 2003. 1792 13.2 Informative References 1794 [11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1795 Protocol (RTSP)", RFC 2326, April 1998. 1797 [12] Handley, M. and V. Jacobson, "SDP: Session Description 1798 Protocol", RFC 2327, April 1998. 1800 [13] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 1801 2000. 1803 [14] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme 1804 Registration", RFC 3508, April 2003. 1806 [15] Rosenberg, J., "A Framework for Conferencing with the Session 1807 Initiation Protocol", 1808 draft-ietf-sipping-conferencing-framework-03 (work in 1809 progress), October 2004. 1811 [16] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 1812 Event Package for the Session Initiation Protocol (SIP)", 1813 draft-ietf-sipping-dialog-package-04 (work in progress), 1814 February 2004. 1816 [17] Koskelainen, P. and H. Khartabil, "Requirements for Conference 1817 Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in 1818 progress), August 2004. 1820 [18] Rosenberg, J., "Obtaining and Using Globally Routable User 1821 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1822 (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. 1824 [19] Levin, O. and G. Camarillo, "The SDP (Session Description 1825 Protocol) Label Attribute", 1826 draft-ietf-mmusic-sdp-media-label-00 (work in progress), 1827 September 2004. 1829 Authors' Addresses 1831 Jonathan Rosenberg 1832 dynamicsoft 1833 600 Lanidex Plaza 1834 Parsippany, NJ 07054 1835 US 1837 Phone: +1 973 952-5000 1838 EMail: jdrosen@dynamicsoft.com 1839 URI: http://www.jdrosen.net 1840 Henning Schulzrinne 1841 Columbia University 1842 M/S 0401 1843 1214 Amsterdam Ave. 1844 New York, NY 10027 1845 US 1847 EMail: schulzrinne@cs.columbia.edu 1848 URI: http://www.cs.columbia.edu/~hgs 1850 Orit Levin (editor) 1851 Microsoft Corporation 1852 One Microsoft Way 1853 Redmond, WA 98052 1854 USA 1856 EMail: oritl@microsoft.com 1858 Intellectual Property Statement 1860 The IETF takes no position regarding the validity or scope of any 1861 Intellectual Property Rights or other rights that might be claimed to 1862 pertain to the implementation or use of the technology described in 1863 this document or the extent to which any license under such rights 1864 might or might not be available; nor does it represent that it has 1865 made any independent effort to identify any such rights. Information 1866 on the procedures with respect to rights in RFC documents can be 1867 found in BCP 78 and BCP 79. 1869 Copies of IPR disclosures made to the IETF Secretariat and any 1870 assurances of licenses to be made available, or the result of an 1871 attempt made to obtain a general license or permission for the use of 1872 such proprietary rights by implementers or users of this 1873 specification can be obtained from the IETF on-line IPR repository at 1874 http://www.ietf.org/ipr. 1876 The IETF invites any interested party to bring to its attention any 1877 copyrights, patents or patent applications, or other proprietary 1878 rights that may cover technology that may be required to implement 1879 this standard. Please address the information to the IETF at 1880 ietf-ipr@ietf.org. 1882 Disclaimer of Validity 1884 This document and the information contained herein are provided on an 1885 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1886 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1887 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1888 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1889 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1890 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1892 Copyright Statement 1894 Copyright (C) The Internet Society (2004). This document is subject 1895 to the rights, licenses and restrictions contained in BCP 78, and 1896 except as set forth therein, the authors retain all their rights. 1898 Acknowledgment 1900 Funding for the RFC Editor function is currently provided by the 1901 Internet Society.