idnits 2.17.1 draft-ietf-sipping-conference-package-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 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 (May 21, 2004) is 7273 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: '9' is defined on line 911, 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 2327 (ref. '11') (Obsoleted by RFC 4566) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-01 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-04 == Outdated reference: A later version (-04) exists of draft-ietf-xcon-cpcp-reqs-03 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-01 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: November 19, 2004 H. Schulzrinne 5 Columbia University 6 O. Levin, Ed. 7 Microsoft Corporation 8 May 21, 2004 10 A Session Initiation Protocol (SIP) Event Package for Conference 11 State 12 draft-ietf-sipping-conference-package-04 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 19, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document defines a conference event package for the Session 44 Initiation Protocol (SIP) Events framework, along with a data format 45 used in notifications for this package. The conference package 46 allows users to subscribe to a conference URI. Notifications are 47 sent about changes in the membership of this conference and 48 optionally about changes in the state of additional conference 49 components. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Conference Event Package . . . . . . . . . . . . . . . . . . . 5 56 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5 57 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 58 3.3 Subscription Duration . . . . . . . . . . . . . . . . . . 5 59 3.4 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 60 3.5 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 6 61 3.6 Notifier Generation of NOTIFY Requests . . . . . . . . . . 6 62 3.7 Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 63 3.8 Handling of Forked Requests . . . . . . . . . . . . . . . 7 64 3.9 Rate of Notifications . . . . . . . . . . . . . . . . . . 7 65 3.10 State Agents . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Conference Data Format . . . . . . . . . . . . . . . . . . . . 9 67 4.1 Conference Information . . . . . . . . . . . . . . . . . . 9 68 4.1.1 User Element . . . . . . . . . . . . . . . . . . . . . 9 69 4.1.1.1 User Attributes . . . . . . . . . . . . . . . . . 10 70 4.1.1.2 User Status Elements . . . . . . . . . . . . . . . 10 71 4.1.1.3 Media Stream Information . . . . . . . . . . . . . 12 72 4.1.2 Sidebar Element . . . . . . . . . . . . . . . . . . . 13 73 4.1.3 Additional Conference Identifiers . . . . . . . . . . 13 74 4.1.4 Policy URIs . . . . . . . . . . . . . . . . . . . . . 13 75 4.2 Constructing Coherent State . . . . . . . . . . . . . . . 13 76 4.2.1 User and Sidebar Updates . . . . . . . . . . . . . . . 14 77 4.2.2 Conference and Policy Identifiers Updates . . . . . . 14 78 4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 6.1 conference Event Package Registration . . . . . . . . . . 20 83 6.2 application/conference-info+xml MIME Registration . . . . 20 84 6.3 URN Sub-Namespace Registration for 85 urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 20 86 6.4 XML Schema Registration . . . . . . . . . . . . . . . . . 21 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 88 8. Changes History . . . . . . . . . . . . . . . . . . . . . . . 23 89 8.1 Changes since -03 . . . . . . . . . . . . . . . . . . . . 23 90 8.2 Changes since -02 . . . . . . . . . . . . . . . . . . . . 23 91 8.3 Changes since -01 . . . . . . . . . . . . . . . . . . . . 23 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 94 9.2 Informative References . . . . . . . . . . . . . . . . . . . 24 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 96 Intellectual Property and Copyright Statements . . . . . . . . 27 98 1. Introduction 100 The Session Initiation Protocol (SIP) [6] Events framework Events 101 Framework [7] defines general mechanisms for subscribing to, and 102 receiving notifications of, events within SIP networks. It 103 introduces the notion of a package, which is a specific 104 "instantiation" of the events framework for a well-defined set of 105 events. Here, we define an event package for SIP conferences. This 106 package provides the conference notification service as outlined in 107 the SIP conferencing framework [13]. As described there, 108 subscriptions to a conference URI are routed to the focus that is 109 handling the conference. It acts as the notifier, and provides 110 clients with updates on conference state. 112 The information provided by this package is comprised of conference 113 identifier(s), conference participants (optionally with their 114 statuses and media description), conference sidebars, and conference 115 policy URIs. 117 2. Terminology 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 121 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 122 indicate requirement levels for compliant implementations. 124 3. Conference Event Package 126 The conference event package allows a user to subscribe to a 127 conference. In SIP, conferences are represented by URIs. These URIs 128 route to a SIP user agent, called a focus, that is responsible for 129 ensuring that all users in the conference can communicate with each 130 other, as described in Conferencing Framework [13]. The focus has 131 sufficient information about the state of the conference to inform 132 subscribers about it. 134 It is possible a participant in the conference may in fact be another 135 focus. In order to provide a more complete participant list, the 136 focus MAY subscribe to the conference package of the other focus to 137 discover the participant list in the cascaded conference. This 138 information can then be included in notifications by using of the 139 "cascaded-focus" attribute as specified by this package. 141 This section provides the details for defining a SIP Events package, 142 as specified by RFC 3265 [7]. 144 3.1 Event Package Name 146 The name of this event package is "conference". This package name is 147 carried in the Event and Allow-Events header, as defined in RFC 3265 148 [7]. 150 3.2 SUBSCRIBE Bodies 152 A SUBSCRIBE for a conference package MAY contain a body. This body 153 defines a filter to apply to the subscription. Filter documents are 154 not specified in this document, and at the time of writing, are 155 expected to be the subject of future standardization activity. 157 A SUBSCRIBE for a conference package MAY be sent without a body. 158 This implies the default subscription filtering policy. The default 159 policy is: 160 o Notifications are generated every time there is any change in the 161 state of the conference. 162 o Notifications do not normally contain full state; rather, they 163 only indicate the state that has changed. The exception is a 164 NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the 165 full state of the information requested by the subscriber. 167 3.3 Subscription Duration 169 The default expiration time for a subscription to a conference is one 170 hour. Once the conference ends, all subscriptions to that particular 171 conference are terminated, with a reason of "noresource" RFC 3265 173 [7]. 175 3.4 NOTIFY Bodies 177 As described in RFC 3265 [7], the NOTIFY message will contain bodies 178 that describe the state of the subscribed resource. This body is in 179 a format listed in the Accept header field of the SUBSCRIBE, or a 180 package-specific default if the Accept header field was omitted from 181 the SUBSCRIBE. 183 In this event package, the body of the notification contains a 184 conference information document. This document describes the state 185 of a conference. All subscribers and notifiers MUST support the 186 "application/conference-info+xml" data format described in Section 4. 187 The subscribe request MAY contain an Accept header field. If no such 188 header field is present, it has a default value of "application/ 189 conference-info+xml". If the header field is present, it MUST 190 include "application/conference-info+xml", and MAY include any other 191 types capable of representing dialog state. 193 Of course, the notifications generated by the server MUST be in one 194 of the formats specified in the Accept header field in the SUBSCRIBE 195 request. 197 3.5 Notifier Processing of SUBSCRIBE Requests 199 The conference information contains very sensitive information. 200 Therefore, all subscriptions SHOULD be authenticated and then 201 authorized before approval. Authorization policy is at the 202 discretion of the administrator, as always. However, a few 203 recommendations can be made. 205 It is RECOMMENDED that all users in the conference be allowed to 206 subscribe to the conference. 208 3.6 Notifier Generation of NOTIFY Requests 210 Notifications SHOULD be generated for the conference whenever there 211 is a change in the state in any of the information delivered to the 212 subscriber. 214 The changes generally occur when a new participant joins (i.e. gets 215 "connected" to) or a participant leaves (i.e. gets "disconnected" 216 from) the conference. 218 Subject to a local focus policy, additional changes in participant's 219 status, changes in its media types, and other optional media 220 attributes MAY be reported by the focus. 222 Changes in sidebar rosters SHOULD be reported by the focus to their 223 participants and MAY be reported to others, subject to local policy. 225 Changes in conference identifiers and policy URIs SHOULD be reported 226 by the focus to the conference participants. 228 3.7 Subscriber Processing of NOTIFY Requests 230 The SIP Events framework expects packages to specify how a subscriber 231 processes NOTIFY requests in any package specific ways, and in 232 particular, how it uses the NOTIFY requests to contruct a coherent 233 view of the state of the subscribed resource. 235 Typically, the NOTIFY for the conference package will only contain 236 information about those users whose state in the conference has 237 changed. To construct a coherent view of the total state of all 238 users, a subscriber to the conference package will need to combine 239 NOTIFYs received over time. 241 Notifications within this package can convey partial information; 242 that is, they can indicate information about a subset of the state 243 associated with the subscription. This means that an explicit 244 algorithm needs to be defined in order to construct coherent and 245 consistent state. The details of this mechanism are specific to the 246 particular document type. See Section 4.2 for information on 247 constructing coherent information from an application/ 248 conference-info+xml document. 250 3.8 Handling of Forked Requests 252 By their nature, the conferences supported by this package are 253 centralized. Therefore, SUBSCRIBE requests for a conference should 254 not generally fork. Users of this package MUST NOT install more than 255 a single subscription as a result of a single SUBSCRIBE request. 257 3.9 Rate of Notifications 259 For reasons of congestion control, it is important that the rate of 260 notifications not become excessive. As a result, it is RECOMMENDED 261 that the server not generate notifications for a single subscriber at 262 a rate faster than once every 5 seconds. 264 3.10 State Agents 266 Conference state is ideally maintained in the element in which the 267 conference resides. Therefore, the elements that maintain the 268 conference are the ones best suited to handle subscriptions to it. 269 Therefore, the usage of state agents is NOT RECOMMENDED for this 270 package. 272 4. Conference Data Format 274 Conference information is an XML document that MUST be well-formed 275 and SHOULD be valid. Dialog information documents MUST be based on 276 XML 1.0 and MUST be encoded using UTF-8. This specification makes 277 use of XML namespaces for identifying dialog information documents 278 and document fragments. The namespace URI for elements defined by 279 this specification is a URN [3], using the namespace identifier 280 'ietf' defined by [4] and extended by [1]. This URN is: 282 urn:ietf:params:xml:ns:conference-info 284 A conference information document begins with the root element tag 285 "conference-info". 287 4.1 Conference Information 289 Conference information begins with the top level element 290 "conference-info". This element has three mandatory and one optional 291 attributes: 292 version: This mandatory attribute allows the recipient of conference 293 information documents to properly order them. Versions start at 0 294 and increment by one for each new document sent to a subscriber. 295 Versions are scoped within a subscription. Versions MUST be 296 represented using a 32 bit integer. 297 state: This mandatory attribute indicates whether the document 298 contains the full conference information, or whether it contains 299 only the information that has changed since the previous document 300 (partial). 301 entity: This mandatory attribute contains the conference URI that 302 identifies the conference being described in the document. 303 recording: This optional attribute indicates whether the conference 304 is being recorded at this moment ("on") or not ("off"). 306 The "conference-info" element has zero or more "user" sub-elements 307 which contain information on the users in the conference. This is 308 followed by zero or more "sidebar" sub-elements which contain 309 information on the sidebars in the conference. This is followed by 310 zero or more "conf-uri" sub-elements which contain information on 311 additional URIs that the conference can be accessed by. This is 312 followed by zero or more "policy-uri" sub-elements which contain 313 information on additional URIs that the conference policies can be 314 accessed by. 316 4.1.1 User Element 317 4.1.1.1 User Attributes 319 The user element has one mandatory attribute, "uri" that indicates 320 the URI for the user in the conference. This is a logical 321 identifier, which corresponds to the authenticated identity of the 322 participant. The "uri" attribute MUST be unique in the user element 323 list because it is used as the key in partial notifications about 324 users' state. 326 If a conference participant has more than a single signaling dialog 327 associated with the conference, the conference focus MAY present the 328 user's aggregated information (e.g. the statuses) and display all 329 its media streams under a single user element. 331 Note, that the optional element "dialog-uri" of "media-stream" (see 332 below) MAY be used in this case to specify the actual signaling 333 dialog for each media stream. 335 An anonymous participant in a conference SHOULD be represented by an 336 anonymous URI generated by the focus. For multiple anonymous 337 participants, the focus must ensure that each anonymous URI is 338 unique. The guidelines for generating anonymous URIs in RFC 3323 [8] 339 should be followed. For example, 341 "Anonymous1" 343 could be used for a participant requesting privacy. 345 The optional attribute "display-name" contains a display name for the 346 user. The standard "xml:lang" language attribute can also be present 347 to indicate the language of the display-name. 349 The optional attribute "cascaded-focus" contains a conference URI 350 (different from the main conference URI) for users that are connected 351 to the main conference as a result of focus cascading. In accordance 352 with the SIP conferencing framework [13], this package allows for 353 representation of peer-to-peer (i.e. "flat") focus cascading only. 354 The actual cascading graph can not be deduced from the information 355 provided in the package alone. Advanced applications can construct 356 the graph by subscribing to both this package and the Dialog Package 357 [14] of the cascaded foci and correlating the relevant information. 359 4.1.1.2 User Status Elements 361 Three optional status elements are defined: status, joining-mode, and 362 disconnection-reason. 363 o "status": provides information about user's current level of 364 participation in the conference. 366 o "joining-mode": if present, provides information about the way the 367 user joined the conference. 368 o "disconnection-reason": if present, provides information about the 369 way the user left the conference. 371 The following statuses are defined for the "status" element: 372 connected: The user is a participant in the conference. Depending on 373 the media policies, he/she can send and receive media to and from 374 other participants. 375 disconnected: The user is not a participant in the conference and no 376 active dialog exists between the user and the focus. 377 on-hold: Active SIP dialog exists between a user and a focus, but 378 user is "on-hold" for this conference, i.e. neither he/she is 379 "hearing" the conference mix, nor is his/her media being mixed in 380 the conference. As an example, the user has asked to join the 381 conference using SIP, but his/her participation is pending based 382 on moderator approval. In the meantime he/she is hearing 383 music-on-hold or some other kind of related content. 384 muted-by-focus: Active SIP dialog exists between a user and a focus 385 and the user can "listen" to the conference, but user's media is 386 not being mixed into the conference. Note that sometimes a subset 387 of user media streams can be muted by focus (such as poor quality 388 video) while others (such as voice or IM) can still be active. In 389 this case, it is RECOMMENDED that the "aggregated" user 390 connectivity "status" reflects the status of the active media. 392 The following statuses are defined for the "joining-mode" element: 393 dialed-in: The user dialed into the conference, i.e. sent INVITE to 394 the focus, which resulted in successful dialog establishment. 395 dialed-out: The focus has brought the user into the conference by 396 sending a successful INVITE to the user. 397 focus-owner: The user is the focus for this conference. This status 398 is used only when a participant UA acts as a conference focus 399 being identified by its own AOR or GRUU. 401 The following statuses are defined for the disconnection-reason 402 element: 403 departed: The user sent a BYE, thus leaving the conference. 404 booted: The user was sent a BYE by the focus, booting him/her out of 405 the conference. Alternatively, the user tried to dial into to 406 conference without success because was rejected by the focus 407 according to local policy decisions. 408 failed: The server tried to bring the user into the conference, but 409 its attempt to contact the specific user resulted in a non-200 410 class final response. Alternatively, the user tried to dial into 411 the conference without success due to technical reasons. 413 4.1.1.3 Media Stream Information 415 Each user has zero or more "media-stream" sub-elements. 417 Each "media-stream" element indicates the media stream that the user 418 is currently connected to. Here, "connected to" implies that a user 419 has a media line in his/her SDP [11] document(s). With this 420 definition, a user is connected to a media stream even if he/she is 421 not sending any media. 423 The "media-stream" element has a mandatory "media-type" attribute 424 which identifies the media type (e.g. audio, video, message and 425 application) and MUST have one of the values registered for "media" 426 of SDP [11]. 428 The "media-stream" element has also an optional "proto" sub-element, 429 which MUST has the value registered for "proto" of SDP [11]. 431 An optional "ssrc" sub-element, if present, carries the value of SSRC 432 (defined in RTP/RTCP [10]) as generated by the user for the stream it 433 sends. 435 When an RTP mixer generates a CSRC list according to RTP/RTCP [10], 436 it inserts a list of the SSRC identifiers of the sources that 437 contributed to the generation of a particular packet into the RTP 438 header of that packet. "An example application is audio conferencing 439 where a mixer indicates all the talkers whose speech was combined to 440 produce the outgoing packet, allowing the receiver to indicate the 441 current talker, even though all the audio packets contain the same 442 SSRC identifier (that of the mixer)." 444 An optional "info" sub-element, if present, carries a human readable 445 description for this stream populated by the focus. The value of 446 this element corresponds to the information media attribute "i" in 447 SDP [11]. 449 An optional "label" sub-element, if present, carries a unique 450 identifier for this stream among all streams in the conference and is 451 assigned by the focus. The value of this element corresponds to the 452 "label" media attribute in SDP [11] and defined in [17]. 454 An optional "dialog-id" sub-element, if present, carries a URI, which 455 MUST uniquely identify the signaling dialog being used for 456 establishing of this media stream. In SIP, for example, values of 457 Contact URI or GRUU [16] can be used for this purpose. It is 458 RECOMMENDED to include the "dialog-id" information for every user 459 that has more than a single dialog associated with the conference. 460 This element SHOULD NOT be included for an anonymous participant. 462 4.1.2 Sidebar Element 464 The sidebar element has one attribute - "entity", which carries the 465 URI identifying the sidebar. This URI MUST be unique among the 466 sidebar identifiers of the same conference. Attribute "entity" is 467 used as the key in partial notifications about sidebars of a 468 conference. 470 A sidebar has zero or more users of "user-type". 472 4.1.3 Additional Conference Identifiers 474 In addition to the Conference URI present in the "entity" attribute, 475 a conference MAY have additional URIs of various types. Connecting 476 to these URIs will result in joining to the same conference. 478 4.1.4 Policy URIs 480 A policy URI specifies where and how a certain policy pertaining to 481 the conference can be accessed. The actual policy name and usage is 482 deduced from the URI schema name. 484 An example for the "policy-uri" usage is inclusion of the URI of the 485 CPCP [15]. A subscriber to the Conference package can use the Policy 486 URI to access and modify the conference policy. 488 4.2 Constructing Coherent State 490 Conference information is associated with a version number. The 491 version number MUST be initialized with the value of the "version" 492 attribute from the "conference-info" element in the first document 493 received. Each time a new document is received, the value of the 494 local version number, and the "version" attribute in the new 495 document, are compared. If the value in the new document is one 496 higher than the local version number, the local version number is 497 increased by one, and the document is processed. If the value in the 498 document is more than one higher than the local version number, the 499 local version number is set to the value in the new document, the 500 document is processed, and the subscriber SHOULD generate a refresh 501 request to trigger a full state notification. If the value in the 502 document is less than the local version, the document is discarded 503 without processing. 505 Further processing of the conference information document depends on 506 whether it contains full or partial state. If it contains full 507 state, indicated by the value of the "state" attribute in the 508 "conference-info" element, the whole local content is flushed and 509 repopulated from the document. 511 If the document contains partial state, as indicated by the value of 512 the "state" attribute in the "conference-info" element, the document 513 is used to update the local content as described below. 515 The conference information is described by a means of a root element: 516 "conference-info", which can be comprised of elements of four main 517 types: "user-type", "sidebar-type", "conf-ids-type", and 518 "policy-ids-type". Updates from partial notifications MUST be 519 implemented as a set of atomic operations on elements of these types 520 only. 522 4.2.1 User and Sidebar Updates 524 The conference package subscriber maintains two tables: one for the 525 list of users and another for the list of sidebars in the conference. 526 Each table contains a row for each user or each sidebar 527 correspondingly. Each row is indexed by a URI key, present in the 528 "uri" attribute of the "user" element or in the "entity" attribute of 529 the "sidebar" element correspondingly. The contents of each row 530 contain the state of that user or a sidebar as conveyed in the 531 document. 533 If the document is an update (i.e. contains partial state), for each 534 table and for each element (i.e. "user" or "sidebar") the subscriber 535 compares the keys received in the update with the keys in the local 536 tables. If a key doesn't exist in the local table, a row is added, 537 and its content is set to the element information from the update. 538 If a key of the same value does exist, the row content is replaced 539 with the received information. 541 If a row is updated or created such that user's state becomes 542 "disconnected", that entry MAY be removed from the table at any time. 543 If a row is updated or created such that a sidebar element doesn't 544 contain any users, that sidebar element MAY be removed from the table 545 at any time. 547 4.2.2 Conference and Policy Identifiers Updates 549 In order to support additional conference features, the conference 550 package subscriber SHOULD locally maintain two additional 551 informational elements: "conf-ids" and "policy-ids". The content of 552 each contains a list of URIs for additional conference identifiers or 553 for policy protocols (correspondingly) applicable to this conference. 555 If the document is an update (i.e. contains partial state), and one 556 or both of the elements exist in the update, the element(s) is/are 557 replaced with the new information as a whole. 559 If the element is updated or created, such that it is empty, that 560 element MAY be removed from the local content at any time. 562 4.3 Schema 564 565 566 569 571 573 574 575 576 577 578 579 580 582 583 584 585 586 587 588 589 590 592 593 595 597 598 600 601 602 603 604 605 606 608 610 611 612 613 614 616 618 619 620 621 622 624 625 627 628 629 630 631 633 634 636 637 638 639 640 642 643 645 646 647 648 649 650 651 653 654 656 657 659 660 661 662 663 664 665 666 668 669 670 671 672 673 674 676 677 678 679 680 681 682 684 685 686 687 688 689 691 693 4.4 Example 695 The following is an example conference information document: 697 699 700 connected 701 dialed-in 702 703 RTP/AVP 704 583398 705 706 708 709 on-hold 710 712 713 on-hold 715 717 718 719 720 722 723 tel:+18005671234 724 h323:conf545@example.com 725 727 729 This conference currently has three users, two of which are in a 730 sidebar conversation. The conference is being recorded. There are 731 additional means to join the conference either by phone using tel URI 732 [14] or by H.323 protocol using H.323 URL [12]. 734 5. Security Considerations 736 Subscriptions to conference state can reveal very sensitive 737 information. For this reason, the document recommends authentication 738 and authorization, and provides guidelines on sensible authorization 739 policies. 741 Since the data in notifications is sensitive as well, end-to-end SIP 742 encryption mechanisms using S/MIME SHOULD be used to protect it. 744 Since a focus provides participants identity information using this 745 event package, participant privacy needs to be taken into account. A 746 focus MUST support requests by participants for privacy. Privacy can 747 be indicated by the conference policy - for every participant or 748 select participants. It can also be indicated in the session 749 signaling. In SIP this can be done using the Privacy header field 750 described in RFC 3323 [8]. For a participant requesting privacy, no 751 identity information SHOULD be revealed by the focus such as a URI 752 (e.g. the Address of Record, Contact, or GRUU). For these cases, 753 the anonymous URI generation method outlined in section "User 754 Element" of this document MUST be followed. 756 6. IANA Considerations 758 This document registers a SIP event package, a new MIME type, 759 application/conference-info+xml, a new XML namespace, and a new XML 760 schema. 762 6.1 conference Event Package Registration 764 This specification registers an event package, based on the 765 registration procedures defined in RFC 3265 [7]. The following is 766 the information required for such a registration: 767 Package Name: conference 768 Package or Template-Package: This is a package. 769 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX 770 with the RFC number of this specification). 771 Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net. 773 6.2 application/conference-info+xml MIME Registration 774 MIME media type name: application 775 MIME subtype name: conference-info+xml 776 Mandatory parameters: none 777 Optional parameters: Same as charset parameter application/xml as 778 specified in RFC 3023 [5]. 779 Encoding considerations: Same as encoding considerations of 780 application/xml as specified in RFC 3023 [5]. 781 Security considerations: See Section 10 of RFC 3023 [5] and Section 5 782 of this specification. 783 Interoperability considerations: none. 784 Published specification: This document. 785 Applications which use this media type: This document type has been 786 used to support SIP conferencing applications. 787 Additional Information: 788 Magic Number: None 789 File Extension: .cif or .xml 790 Macintosh file type code: "TEXT" 791 Personal and email address for further information: Jonathan 792 Rosenberg, 793 Intended usage: COMMON 794 Author/Change controller: The IETF. 796 6.3 URN Sub-Namespace Registration for 797 urn:ietf:params:xml:ns:conference-info 799 This section registers a new XML namespace, as per the guidelines in 800 [1]. 802 URI: The URI for this namespace is 803 urn:ietf:params:xml:ns:conference-info. 804 Registrant Contact: IETF, SIPPING working group, , 805 Jonathan Rosenberg . 806 XML: 808 BEGIN 809 810 812 813 814 816 Conference Information Namespace 817 819

Namespace for Conference Information

820

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

821

See RFCXXXX.

822 823 824 END 826 6.4 XML Schema Registration 828 This specification registers a schema, as per the guidelines in in 829 [1]. 830 URI: please assign. 831 Registrant Contact: IETF, SIPPING Working Group 832 (sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). 833 XML: The XML can be found as the sole content of Section 4.3. 835 7. Acknowledgements 837 The authors would like to thank Dan Petrie, Sean Olson, and Alan 838 Johnston for their comments and inputs. 840 8. Changes History 842 8.1 Changes since -03 843 o "Constructing Coherent State" section has been updated. 844 o In order to support partial notifications, two placeholders 845 "conference-ids" and "policy-ids" (for "conf-uri" and "policy-uri" 846 elements, correspondingly) are created. 847 o Discussion and security considerations regarding anonymous 848 participation have been added. 849 o Optional elements "dialog-uri", "info" and "label" per media 850 stream are added. 852 8.2 Changes since -02 853 o State "muted-by-focus" is added to user's status. 854 o Optional conference attribute "recording" is added. 855 o Policy URI placeholder (i.e. element "policy-uri") is created. 856 o Example's syntax is corrected. 857 o Optional attribute "cascaded-focus" URI per user is added. 858 o Optional additional conference identifiers (i.e. element 859 "conf-uri") are added. 860 o In order to cover all possible cases, participant's status is 861 expressed using three optional statuses: "status", "joining-mode" 862 and "disconnection-reason". That is instead of "activity-status", 863 "history-status" and "is-on-dial-out-list". 865 8.3 Changes since -01 866 o Package parameters are removed. Decision about performing 867 "recursive" membership algorithm is perceived as a focus local 868 policy. 869 o General information (i.e. pointers to additional available 870 services) is removed. The defined XML schema can be extended in 871 future to include those when XCON work matures. 872 o Dialog information is removed. It can be obtained by direct 873 subscription to a dialog package of a participant. 874 o Media stream information is aligned with SDP definitions (media 875 and proto) and SSRC attribute is added. 876 o Participant's status is expressed using two optional statuses: 877 "activity" and "history". Optional "is-on-a-dial-out-list" 878 indication is added. 879 o Normative references to XCON work are removed. 880 o Optional sidebar rosters are added. 882 9. References 884 9.1 Normative References 886 [1] Mealling, M., "The IETF XML Registry", 887 draft-mealling-iana-xmlns-registry-05 (work in progress), June 888 2003. 890 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 891 Levels", BCP 14, RFC 2119, March 1997. 893 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 895 [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 896 August 1999. 898 [5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 899 3023, January 2001. 901 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 902 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 903 Session Initiation Protocol", RFC 3261, June 2002. 905 [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 906 Notification", RFC 3265, June 2002. 908 [8] Peterson, J., "A Privacy Mechanism for the Session Initiation 909 Protocol (SIP)", RFC 3323, November 2002. 911 [9] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, 912 "Grouping of Media Lines in the Session Description Protocol 913 (SDP)", RFC 3388, December 2002. 915 [10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 916 "RTP: A Transport Protocol for Real-Time Applications", RFC 917 3550, July 2003. 919 9.2 Informative References 921 [11] Handley, M. and V. Jacobson, "SDP: Session Description 922 Protocol", RFC 2327, April 1998. 924 [12] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme 925 Registration", RFC 3508, April 2003. 927 [13] Rosenberg, J., "A Framework for Conferencing with the Session 928 Initiation Protocol", 929 draft-ietf-sipping-conferencing-framework-01 (work in 930 progress), October 2003. 932 [14] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 933 Event Package for the Session Initiation Protocol (SIP)", 934 draft-ietf-sipping-dialog-package-04 (work in progress), 935 February 2004. 937 [15] Koskelainen, P. and H. Khartabil, "Requirements for Conference 938 Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-03 (work in 939 progress), April 2004. 941 [16] Rosenberg, J., "Obtaining and Using Globally Routable User 942 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 943 (SIP)", draft-ietf-sip-gruu-01 (work in progress), February 944 2004. 946 [17] Levin, O. and G. Camarillo, "SDP Media Label", 947 draft-levin-mmusic-sdp-media-label-00 (work in progress), 948 May 2004. 950 Authors' Addresses 952 Jonathan Rosenberg 953 dynamicsoft 954 600 Lanidex Plaza 955 Parsippany, NJ 07054 956 US 958 Phone: +1 973 952-5000 959 EMail: jdrosen@dynamicsoft.com 960 URI: http://www.jdrosen.net 962 Henning Schulzrinne 963 Columbia University 964 M/S 0401 965 1214 Amsterdam Ave. 966 New York, NY 10027 967 US 969 EMail: schulzrinne@cs.columbia.edu 970 URI: http://www.cs.columbia.edu/~hgs 971 Orit Levin (editor) 972 Microsoft Corporation 973 One Microsoft Way 974 Redmond, WA 98052 975 USA 977 EMail: oritl@microsoft.com 979 Intellectual Property Statement 981 The IETF takes no position regarding the validity or scope of any 982 intellectual property or other rights that might be claimed to 983 pertain to the implementation or use of the technology described in 984 this document or the extent to which any license under such rights 985 might or might not be available; neither does it represent that it 986 has made any effort to identify any such rights. Information on the 987 IETF's procedures with respect to rights in standards-track and 988 standards-related documentation can be found in BCP-11. Copies of 989 claims of rights made available for publication and any assurances of 990 licenses to be made available, or the result of an attempt made to 991 obtain a general license or permission for the use of such 992 proprietary rights by implementors or users of this specification can 993 be obtained from the IETF Secretariat. 995 The IETF invites any interested party to bring to its attention any 996 copyrights, patents or patent applications, or other proprietary 997 rights which may cover technology that may be required to practice 998 this standard. Please address the information to the IETF Executive 999 Director. 1001 Full Copyright Statement 1003 Copyright (C) The Internet Society (2004). All Rights Reserved. 1005 This document and translations of it may be copied and furnished to 1006 others, and derivative works that comment on or otherwise explain it 1007 or assist in its implementation may be prepared, copied, published 1008 and distributed, in whole or in part, without restriction of any 1009 kind, provided that the above copyright notice and this paragraph are 1010 included on all such copies and derivative works. However, this 1011 document itself may not be modified in any way, such as by removing 1012 the copyright notice or references to the Internet Society or other 1013 Internet organizations, except as needed for the purpose of 1014 developing Internet standards in which case the procedures for 1015 copyrights defined in the Internet Standards process must be 1016 followed, or as required to translate it into languages other than 1017 English. 1019 The limited permissions granted above are perpetual and will not be 1020 revoked by the Internet Society or its successors or assignees. 1022 This document and the information contained herein is provided on an 1023 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1024 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1025 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1026 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1027 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1029 Acknowledgment 1031 Funding for the RFC Editor function is currently provided by the 1032 Internet Society.