idnits 2.17.1 draft-ietf-xcon-event-package-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2008) is 5906 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-11) exists of draft-ietf-xcon-framework-10 == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-08 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON G. Camarillo 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Srinivasan 5 Expires: August 19, 2008 Microsoft Corporation 6 R. Even 7 Polycom 8 J. Urpalainen 9 Nokia 10 February 16, 2008 12 Conference Event Package Data Format Extension for Centralized 13 Conferencing (XCON) 14 draft-ietf-xcon-event-package-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 19, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document specifies the notification mechanism for XCON 48 (centralized conferencing). This mechanism reuses the SIP (Session 49 Initiation Protocol) event package for conference state. 50 Additionally, the notification mechanism includes support for the 51 XCON data model and for partial notifications. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Notification Formats . . . . . . . . . . . . . . . . . . . . . 4 58 4. Full Notifications . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 5 60 5. Partial Notifications . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Generation of Partial Notifications . . . . . . . . . . . 5 62 5.2. Processing of Partial Notifications . . . . . . . . . . . 6 63 5.3. Partial Notification Format . . . . . . . . . . . . . . . 7 64 5.4. XML Schema for Partial Notifications . . . . . . . . . . . 7 65 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. MIME type Registration: 68 application/xcon-conference-info+xml . . . . . . . . . . . 9 69 6.2. MIME type Registration: 70 application/xcon-conference-info-diff+xml . . . . . . . . 10 71 6.3. URN Sub-Namespace Registration: consent-status . . . . . . 11 72 6.4. XML Schema Registration . . . . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 Intellectual Property and Copyright Statements . . . . . . . . . . 14 78 1. Introduction 80 The XCON (centralized Conferencing) framework 81 [I-D.ietf-xcon-framework] defines a notification service that 82 provides updates about a conference instance's state to authorized 83 parties using a notification protocol, as shown in Figure 1. This 84 document specifies how to use the SIP (Session Initiation Protocol 85 [RFC3261]) event package for conference state defined in [RFC4575] as 86 a notification protocol between a client and a conference's 87 notification server. 89 ........................... 90 . Conferencing System . 91 . . 92 . +--------------+ . 93 . | Conf. object | . 94 . | | . 95 . +--------------+ . 96 . | . 97 . v . 98 . +------------+ . 99 . |Notification| . 100 . |Service | . 101 . +------------+ . 102 . ^ . 103 ..........|................ 104 | 105 | Notification 106 | Protocol 107 |(notifications following the 108 | XCON data model) 109 | 110 ..........|............ 111 . v . 112 . +------------+ . 113 . |Notification| . 114 . | Client | . 115 . +------------+ . 116 . . 117 . Conferencing Client . 118 ....................... 120 Figure 1: Notification service and protocol in the XCON architecture 122 In addition to specifying the SIP event package for conference state, 123 [RFC4575] specifies a data format to be used with the event package. 124 The XCON data model [I-D.ietf-xcon-common-data-model] extends that 125 format with new elements and attributes so that the extended format 126 supports more functionality (e.g., floor control). The notification 127 protocol specified in this document supports all the data defined in 128 the XCON data model (i.e., the data originally defined in [RFC4575] 129 plus all the extensions defined in [I-D.ietf-xcon-common-data-model]) 130 plus a partial notification mechanism based on XML patch operations 131 [I-D.ietf-simple-xml-patch-ops]. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Notification Formats 141 In order to obtain notifications from a conference server's 142 notification service, a client subscribes to the 'conference' event 143 package at the server as specified in [RFC4575]. Per [RFC4575], 144 NOTIFY requests within this event package can carry an XML document 145 in the "application/conference-info+xml" format. Additionally, per 146 this specification, NOTIFY requests can also carry XML documents in 147 the "application/xcon-conference-info+xml" and the "application/ 148 xcon-conference-info-diff" formats. 150 A document in the "application/xcon-conference-info+xml" format 151 provides the user agent with the whole state of a conference 152 instance. A document in the "application/ 153 xcon-conference-info-diff+xml" format provides the user agent with 154 the changes the state of the conference instance has experimented 155 since the last notification sent to the user agent. 157 4. Full Notifications 159 Subscribers signal support for full notifications by including the 160 "application/xcon-conference-info+xml" format in the Accept header 161 field of the SUBSCRIBE requests they generate. If a client 162 subscribing to the 'conference' event package generates an Accept 163 header field that includes the MIME type "application/ 164 xcon-conference-info+xml", the server has the option of returning 165 documents that follow the XML format specified in 166 [I-D.ietf-xcon-common-data-model] and are carried in "application/ 167 xcon-conference-info+xml" message bodies. 169 4.1. Backwards Compatibility 171 Conference servers that implement the SIP event package for 172 conference state and support the "application/ 173 xcon-conference-info+xml" MIME type MUST also support the 174 "application/conference-info+xml" MIME type. This way, legacy 175 clients, which only support "application/conference-info+xml", are 176 able to receive notifications in a format they understand. 178 Clients that implement the SIP event package for conference state and 179 support the "application/xcon-conference-info+xml" MIME type SHOULD 180 also support the "application/conference-info+xml" MIME type. This 181 way, these clients are able to receive notifications from legacy 182 servers, which only support "application/conference-info+xml", in a 183 format they understand. 185 5. Partial Notifications 187 The conference state reported by this event package may contain many 188 elements. When the "xcon-conference-info+xml" format is used and 189 there is a change in the state of an element, the server generates a 190 notification with the whole conference state. Generating large 191 notifications to report small changes does not meet the efficiency 192 requirements of some bandwidth-constrained environments. The partial 193 notifications mechanism specified in this section is a more efficient 194 way to report changes in the conference state. 196 The SIP event package for conference state defined a partial 197 notification mechanism based on elements. Servers compliant 198 with this specification MUST NOT use that partial notification 199 mechanism. Instead, they MUST use the mechanism specified in this 200 section. 202 Subscribers signal support for partial notifications by including the 203 "application/xcon-conference-info-diff+xml" format in the Accept 204 header field of the SUBSCRIBE requests they generate. If a client 205 subscribing to the 'conference' event package generates an Accept 206 header field that includes the MIME type "application/ 207 xcon-conference-info-diff+xml", the server has the option of 208 returning documents that follow the XML format specified in 209 Section 5.4 and are carried in "application/ 210 xcon-conference-diff-info+xml" message bodies. 212 5.1. Generation of Partial Notifications 214 Once a subscription is accepted and installed, the server MUST 215 deliver full state in its first notification. To report full state, 216 the server MUST set the Content-Type header field to the value 217 'application/xcon-conference-info+xml'. 219 In order to deliver a partial notification, the server MUST set the 220 Content-Type header field to the value 'application/ 221 xcon-conference-info-diff+xml'. When the server generates a partial 222 notification, the server SHOULD only include the information that has 223 changed compared to the previous notification. It is up to the 224 server's local policy to determine what is considered as a change to 225 the previous state. 227 The server MUST construct partial notifications according to the 228 following logic: all the information that has been added to the 229 document is listed inside elements. All information that has 230 been removed from the document is listed inside elements and 231 all information that has been changed is listed under 232 elements. 234 The server MUST NOT send a new NOTIFY request with a partial 235 notification until it has received a final response from the 236 subscriber for the previous one or the previous NOTIFY request has 237 timed out. 239 When the server receives a SUBSCRIBE request (refresh or termination) 240 within the associated subscription, it SHOULD send a NOTIFY request 241 containing the full document using the 'application/ 242 xcon-conference-info+xml' content type. 244 If the server has used a content type other than 'application/ 245 xcon-conference-info+xml' in notifications within the existing 246 subscription and changes to deliver partial notifications, the server 247 MUST deliver full state using the 'application/ 248 xcon-conference-info+xml' content type before generating its first 249 partial notification. 251 5.2. Processing of Partial Notifications 253 When a subscriber receives the first notification containing full 254 state in a 'application/xcon-conference-info+xml' MIME body, the 255 subscriber MUST store the received full document as its local copy. 257 When the subscriber receives a subsequent notification, the 258 subscriber MUST modify its locally-stored information according to 259 the following logic: 261 o If the notification carries an 'application/ 262 xcon-conference-info+xml' document, the subscriber MUST replace 263 its local copy of the document with the document received in 264 notification. 266 o If the notification carries an 'application/ 267 xcon-conference-info-diff+xml' document, the subscriber MUST apply 268 the changes indicated in the received 'application/ 269 xcon-conference-info-diff+xml' document to its local copy of the 270 full document. 272 If subscriber encounters a processing error while processing an 273 'application/xcon-conference-info-diff+xml' encoded document, the 274 subscriber SHOULD renew its subscription. A subscriber can fall back 275 to normal operations by not including the "application/ 276 xcon-conference-info-diff+xml' format in a new SUBSCRIBE request. 278 If the server changes the content type used in notifications within 279 the existing subscription, the subscriber MUST discard all the 280 previously received information and process the new content as 281 specified for that content type. 283 5.3. Partial Notification Format 285 A xcon-conference-info-diff diff document is an XML 286 [W3C.REC-xml-20060816] document that MUST be well-formed and SHOULD 287 be valid. The namespace URI for the root 288 document element is defined in [I-D.ietf-xcon-common-data-model] : 289 urn:ietf:params:xml:ns:xcon-conference-info 291 The root document element has a single 292 mandatory attribute, "entity". The value of this attribute is the 293 conference object identifier (XCON-URI) that identifies the 294 conference being described in the document. 296 The content of the element is an unordered 297 sequence of , and elements followed by 298 elements from other namespaces for the purposes of extensibility. 299 Any such unknown elements MUST be ignored by the client. The , 300 and elements can contain other extension 301 attributes than what are defined in the corresponding base types of 302 [I-D.ietf-simple-xml-patch-ops]. 304 5.4. XML Schema for Partial Notifications 306 This is the XML schema for the "application/ 307 xcon-conference-info-diff+xml" data format. The 308 "urn:ietf:params:xml:schema:xml-patch-ops" schema is defined in 309 [I-D.ietf-simple-xml-patch-ops]. 311 312 318 319 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 360 361 362 363 364 365 366 368 5.5. Examples 370 The following is an 'application/xcon-conference-info-diff+xml' 371 partial update document: 373 374 378 381 383 5 385 387 6. IANA Considerations 389 There are four IANA considerations associated with this 390 specification. 392 6.1. MIME type Registration: application/xcon-conference-info+xml 394 This section registers the 'application/xcon-conference-info+xml' 395 MIME type. 397 MIME media type name: application 398 MIME subtype name: xcon-conference-info+xml 399 Mandatory parameters: none 400 Optional Parameters: Same as charset parameter application/xml as 401 specified in [RFC3023]. 403 Encoding considerations: Same as encoding considerations of 404 application/xml as specified in [RFC3023]. 405 Security considerations: Security considerations: See Section 10 of 406 [RFC3023]. 407 Interoperability considerations: none 408 Published specification: RFC xxxx (Note to the RFC Editor: Please 409 replace XXXX with the RFC Number of this specification.) 410 Applications that use this media type: This document type has been 411 defined to support centralized conferencing applications. 413 Additional Information: 415 Magic Number: none 416 File extension: .xml 417 Macintosh file type code: "TEXT" 418 Personal and email address for further information: IETF XCON 419 Working Group 420 Intended usage: COMMON 421 Author/Change controller: The IETF. 423 6.2. MIME type Registration: application/xcon-conference-info-diff+xml 425 This section registers the 'application/ 426 xcon-conference-info-diff+xml' MIME type. 428 MIME media type name: application 429 MIME subtype name: xcon-conference-info-diff+xml 430 Mandatory parameters: none 431 Optional Parameters: Same as charset parameter application/xml as 432 specified in [RFC3023]. 433 Encoding considerations: Same as encoding considerations of 434 application/xml as specified in [RFC3023]. 435 Security considerations: Security considerations: See Section 10 of 436 [RFC3023]. 437 Interoperability considerations: none 438 Published specification: RFC xxxx (Note to the RFC Editor: Please 439 replace XXXX with the RFC Number of this specification.) 440 Applications that use this media type: This document type has been 441 defined to support partial notifications in centralized 442 conferencing applications. 444 Additional Information: 446 Magic Number: none 447 File extension: .xml 448 Macintosh file type code: "TEXT" 449 Personal and email address for further information: IETF XCON 450 Working Group 451 Intended usage: COMMON 452 Author/Change controller: The IETF. 454 6.3. URN Sub-Namespace Registration: consent-status 456 This section registers a new XML namespace per the procedures in 457 [RFC3688]. 459 URI: urn:ietf:params:xml:ns:xcon-conference-info-diff 461 Registrant Contact: IETF SIPPING working group, , 462 Gonzalo Camarillo 464 XML: 466 467 469 470 471 473 Partial Notifications in Centralized Conferencing 474 475 476

Namespace for Partial Notifications in

477

Centralized Conferencing

478

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

479

See RFCXXXX [[NOTE TO 480 RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of 481 this specification]].

482 483 485 6.4. XML Schema Registration 487 This section registers an XML schema per the procedures in [RFC3688]. 489 URI: urn:ietf:params:xml:schema:xcon-conference-info-diff 491 Registrant Contact: IETF XCON working group, , Gonzalo 492 Camarillo 493 The XML for this schema can be found in Section 5.4. 495 7. Security Considerations 497 This document specifies how to deliver notifications using the SIP 498 event package for conference state in two new formats. The fact that 499 notifications are encoded in a different format does not have 500 security implications. Section 8 of [RFC4575] contains security 501 considerations related to the use of the event package. Implementers 502 of the event package need to follow those considerations regardless 503 of the format used to encode their notifications. 505 8. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 511 Types", RFC 3023, January 2001. 513 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 514 A., Peterson, J., Sparks, R., Handley, M., and E. 515 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 516 June 2002. 518 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 519 January 2004. 521 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 522 Initiation Protocol (SIP) Event Package for Conference 523 State", RFC 4575, August 2006. 525 [W3C.REC-xml-20060816] 526 Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C., 527 and E. Maler, "Extensible Markup Language (XML) 1.0 528 (Fourth Edition)", World Wide Web Consortium 529 Recommendation REC-xml-20060816, August 2006, 530 . 532 [I-D.ietf-simple-xml-patch-ops] 533 Urpalainen, J., "An Extensible Markup Language (XML) Patch 534 Operations Framework Utilizing XML Path Language (XPath) 535 Selectors", draft-ietf-simple-xml-patch-ops-04 (work in 536 progress), November 2007. 538 [I-D.ietf-xcon-framework] 539 Barnes, M., Boulton, C., and O. Levin, "A Framework for 540 Centralized Conferencing", draft-ietf-xcon-framework-10 541 (work in progress), November 2007. 543 [I-D.ietf-xcon-common-data-model] 544 Novo, O., Camarillo, G., Morgan, D., and R. Even, 545 "Conference Information Data Model for Centralized 546 Conferencing (XCON)", draft-ietf-xcon-common-data-model-08 547 (work in progress), December 2007. 549 Authors' Addresses 551 Gonzalo Camarillo 552 Ericsson 553 Hirsalantie 11 554 Jorvas 02420 555 Finland 557 Email: Gonzalo.Camarillo@ericsson.com 559 Srivatsa Srinivasan 560 Microsoft Corporation 561 One Microsoft Way 562 Redmond, WA 98052 563 USA 565 Email: srivats@microsoft.com 567 Roni Even 568 Polycom 569 94 Derech Em Hamoshavot 570 Petach Tikva 49130 571 Israel 573 Email: roni.even@polycom.co.il 575 Jari Urpalainen 576 Nokia 577 Itamerenkatu 11-13 578 Helsinki 00180 579 Finland 581 Email: jari.urpalainen@nokia.com 583 Full Copyright Statement 585 Copyright (C) The IETF Trust (2008). 587 This document is subject to the rights, licenses and restrictions 588 contained in BCP 78, and except as set forth therein, the authors 589 retain all their rights. 591 This document and the information contained herein are provided on an 592 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 593 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 594 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 595 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 596 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 599 Intellectual Property 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at 621 ietf-ipr@ietf.org. 623 Acknowledgment 625 Funding for the RFC Editor function is provided by the IETF 626 Administrative Support Activity (IASA).