XCON Working Group S. Srinivasan Internet-Draft Microsoft Corporation Intended status: Standards Track R. Even Expires: February 17, 2008 Polycom August 16, 2007 Conference event package data format extension for centralized conferencing draft-srinivasan-xcon-eventpkg-extensions-02 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document augments the notification mechanism defined in RFC 4575 to suit the specific needs of the framework and the data model defined for centralized conferencing. The document registers a new media subtype for this purpose. Support for this new data format may be negotiated using Accept header semantics as defined in the Session Initiation Protocol (SIP). Srinivasan & Even Expires February 17, 2008 [Page 1] Internet-Draft xcon-eventpkg-extensions August 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Event package definition . . . . . . . . . . . . . . . . . . . 4 3.1. Event package name . . . . . . . . . . . . . . . . . . . . 4 3.2. SUSCRIBE and NOTIFY bodies . . . . . . . . . . . . . . . . 4 3.2.1. Reasons for a new media type . . . . . . . . . . . . . 5 3.2.2. Elements supporting partial updates . . . . . . . . . 6 3.3. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 7 3.4. Notifier Generation of NOTIFY Requests . . . . . . . . . . 7 3.5. Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. application/xcon-conference-info+xml media type registration . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informational References . . . . . . . . . . . . . . . . . 9 Appendix A. Examples of partial updates . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Srinivasan & Even Expires February 17, 2008 [Page 2] Internet-Draft xcon-eventpkg-extensions August 2007 1. Introduction The framework for centralized conferencing [1] specifies the need for a notification mechanism to deliver conference state updates to conference-aware clients. The purpose of this document is to fill that requirement by building upon the event package defined in RFC 4575 [2] and uses the data model defined for centralized conferencing [3] instead of the one defined in the Conference Event Package. The diagram below shows the subscription and notification entities present in the centralized conferencing framework. ........................... . Conferencing System . . . . +--------------+ . . | Conf. object | . . | | . . | | . . | | . . +--------------+ . . | . . | . . v . . +------------+ . . |Notification| . . |Service | . . |(Notifier) | . . +------------+ . . ^ ^ . .....|....|................ | | | | Subscribe| |Notification | |(data model for centralized conferencing) | | | | .....|....|............ . V v . . +------------+ . . |Notification| . . | Client | . . |(Subscriber)| . . | | . . +------------+ . . . . Conferencing Client . ....................... Srinivasan & Even Expires February 17, 2008 [Page 3] Internet-Draft xcon-eventpkg-extensions August 2007 As mentioned earlier, the conferencing client may use the notification protocol defined in RFC 4575 [2] to subscribe and receive notifications based on mechanisms defined here. Listed below are some of the requirements for the event package. o The event package should satisfy the notifications needs defined in the conferencing framework [1] and the data model defined for centralized conferencing [3]. o The event package should re-use the event package mechanisms defined in RFC4575 [2] to the extent possible. o The event package should support partial updates of changes in elements defined in the data model for centralized conferencing [3] such as controls and list elements. Clients receiving partial notifications can determine the specific control that changed by examining the notification received. o The event package should describe how conference-aware clients implementing the conference event package [2](and the data format defined therein) will work against the centralized conferencing defined data format defined in [3]. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Event package definition Implementations of this event package MUST follow all sections of RFC 4575 [2] Section 3 unless otherwise specified in this document. 3.1. Event package name The name of this event package is "conference" as defined in Section 3.1 of RFC 4575 [2]. 3.2. SUSCRIBE and NOTIFY bodies This document defines a new media type 'application/ xcon-conference-info+xml' for supporting the data model for centralized conferencing. Implementations of this specification thus MUST support the data model defined for centralized conferencing [3]. Furthermore, Srinivasan & Even Expires February 17, 2008 [Page 4] Internet-Draft xcon-eventpkg-extensions August 2007 implementations MUST also support the media type 'application/ conference-info+xml' defined in RFC 4575 [2] for backward compatibility reasons. Subscribers implementing this specification MUST include an Accept header, as defined in RFC 3261 [4], in the SUBSCRIBE request including BOTH 'application/xcon-conference-info+xml' as well as the media type 'application/conference-info+xml' defined in [2]. Notifiers implementing this specification MUST handle SUBSCRIBE requests with either media types as well. Therefore, subscribers implementing this specification may receive NOTIFY's with either media type depending on the format that the conferencing system supports. Notifiers implementing this specification SHOULD prefer to use 'application/xcon-conference-info+xml' wherever possible over the media type 'application/conference-info+xml'. Furthermore, the subscriber may a priori determine which formats the conferencing system is capable of by using Accept header semantics. 3.2.1. Reasons for a new media type This section describes some of the reasoning for defining a new media type as opposed to simply using XML extensibility to achieve the needs for notifications. The media type 'application/conference-info+xml' is defined in the conference event package [2]. Sections 4.4, 4.5 and 4.6 therein specify a mechanism to send partial updates of conference state information. The algorithm defined in those sections, however, prevents the partial notifications for non-atomic sub-elements of elements like 'available-media' (defined in Section 5.3.4 of [2]) and 'media' (defined in Section 5.7.8 of [2]) as these elements do not contain a state attribute defined. The data model for centralized conferencing introduces the concept of controls for controlling media. This is defined under 'available- media' for streams from the mixer and under 'media' for streams received from and sent to the mixer from conference participant's endpoints. A 'floor' element has also been defined under the 'media' element. These elements may frequently change their state over the course of a conference. The list of media could grow significantly large for large conferences. Furthermore, clients receiving updates of media often need to know which specific control changed when a notification as such is received. To overcome these limitations, a partial notification mechanism needs to be defined for these elements. Thus, state attributes and element Srinivasan & Even Expires February 17, 2008 [Page 5] Internet-Draft xcon-eventpkg-extensions August 2007 keys (for the sub-elements) have been defined in the data model for these elements. This, however, requires that a new media subtype be defined and registered as these elements have been explicitly marked as not having a state attribute in [2]. A conferencing system, implementing only [2], may not expect to receive these XML elements with a state attribute of partial and thus this may result in inconsistent conferencing state. In-order to overcome this limitation this specification defines a new media subtype which can be used to enable partial notifications of elements previously defined without a state attribute. 3.2.2. Elements supporting partial updates As specified earlier, the following captures elements defined in RFC 4575 [2] not supporting partial updates that now need support for partial updates. 1. Conference information 'available-media' XML element defined in Section 5.3.4 of [2] 2. Endpoint 'media' XML element defined in Section 5.7.8 of [2] 3.2.2.1. Available-media With the introduction of the state attribute to available-media in [3], element keys are defined as follows for sub-elements. The sub-element 'entry' is defined with the attribute key 'label'. The non-atomic sub-elements under 'entry' are 'codecs' and 'controls'. There are no requirements to have 'codecs' support partial updates as these are expected to change rarely. The 'controls' element is defined with a state attribute as well. The sub-elements appearing under 'controls' do not require a key as each sub-element (like 'mute' or 'gain') appears only once and is atomic. That is, in a partial notification, the 'mute' element (and all sub-elements) should be included. 3.2.2.2. Media Similarly, the introduction of the state attribute to media requires element keys to be defined for its sub-elements. The 'endpoints' element (under which 'media' appears) has the state attribute defined and so do all its parent elements. Srinivasan & Even Expires February 17, 2008 [Page 6] Internet-Draft xcon-eventpkg-extensions August 2007 The non-atomic sub-elements under 'media' are 'from-mixer' and 'to- mixer'. Both of which have the state attribute defined. The 'floor' element is an atomic sub-element of 'from-mixer' or 'to- mixer' and thus does not require a state attribute. The non-atomic sub-element appearing under both 'from-mixer' and 'to-mixer' is the 'controls' element which has a 'state' attribute defined. The sub- elements appearing under 'controls', as defined previously (Section 3.2.2.1), do not require a key as each sub-element appears only once and is atomic. 3.3. Notifier Processing of SUBSCRIBE Requests Notifiers implementing this specification MUST be capable of accepting SUBSCRIBE requests with an Accept header field containing 'application/xcon-conference-info+xml' and/or 'application/ conference-info+xml'. A SUBSCRIBE request sent without an Accept header field MUST be supported. In this case, the notifier should default to the media type 'application/conference-info+xml' and thus all NOTIFY's generated for that subscription MUST follow RFC 4575 [2]. Furthermore, a SUBSCRIBE body sent without a body will apply default subscription filtering policy as specified in Section 3.2 of [2]. 3.4. Notifier Generation of NOTIFY Requests Notifiers generating NOTIFY requests should take into account the media type that the subscriber can accept when generating partial notifications. As mentioned before, notifiers SHOULD prefer to use 'application/xcon-conference-info+xml' wherever possible over the media type 'application/conference-info+xml'. For example, a notification request generated to a subscriber only accepting the media type 'application/conference-info+xml' may be different from the one generated to a subscriber accepting 'application/xcon-conference-info+xml'. An example of such a case is illustrated in Appendix A. 3.5. Subscriber Processing of NOTIFY Requests Subscribers implementing this specification MUST be capable of receiving NOTIFY Requests with media types of either 'application/ xcon-conference-info+xml' or 'application/conference-info+xml'. All sections of Section 4.6 of [2] apply to enable subscribers to construct coherent state when receiving partial updates based on the new media type defined here. Srinivasan & Even Expires February 17, 2008 [Page 7] Internet-Draft xcon-eventpkg-extensions August 2007 4. Security Considerations It is RECOMMENDED that a centralized conferencing system following this specification use a strong means for authentication and conference information protection and that it apply comprehensive authorization rules as defined in RFC 4575 [2], Section 8. 5. IANA Considerations 5.1. application/xcon-conference-info+xml media type registration [[TBD]] To: ietf-types@iana.org Subject: Registration of media type application/ xcon-conference-info+xml Type name: application Subtype name: xcon-conference-info+xml Required parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [5] Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5] Security considerations: See Section 10 of RFC 3023 [5] and Section 4 of this specification Interoperability considerations: none Published specification: This document. Applications which use this media type: This document type has been used to support SIP conferencing applications that comply with the data model for centralized conferencing [3] Additional Information: Magic Number(s): None File Extension(s): .xml Srinivasan & Even Expires February 17, 2008 [Page 8] Internet-Draft xcon-eventpkg-extensions August 2007 Macintosh file type code(s): "TEXT" Personal and email address for further information: TBD Intended usage: COMMON Author: Change controller: TBD 6. References 6.1. Normative References [1] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", draft-ietf-xcon-framework-09 , August 2007. [2] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [3] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference Information Data Model for Centralized Conferencing (XCON)", draft-ietf-xcon-common-data-model-05 , April 2007. [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. 6.2. Informational References [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Appendix A. Examples of partial updates Consider an example, where the conferencing state changes. The main audio stream with a label of '34569' changes mute state from false to true. A notifier implementing partial updates specified in RFC 4575 [2] without the state attribute extensions defined in this document would Srinivasan & Even Expires February 17, 2008 [Page 9] Internet-Draft xcon-eventpkg-extensions August 2007 end up sending the entire available-media element as shown below. Content-Type: application/conference-info+xml ... main audio audio sendrecv true 0 However, a notifier implementing the centralized conferencing data model and the extensions defined in this draft would notify clients with relevant changes only wherever possible as shown below. Content-Type: application/conference-info+xml ... true Srinivasan & Even Expires February 17, 2008 [Page 10] Internet-Draft xcon-eventpkg-extensions August 2007 Authors' Addresses Srivatsa Srinivasan Microsoft Corporation One Microsoft Way Redmond, WA 98052, USA Email: srivats@microsoft.com Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130, Israel Email: roni.even@polycom.co.il Srinivasan & Even Expires February 17, 2008 [Page 11] Internet-Draft xcon-eventpkg-extensions August 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Srinivasan & Even Expires February 17, 2008 [Page 12]