XCON Working Group S. Srinivasan Internet-Draft Microsoft Corporation Intended status: Standards Track R. Even Expires: August 30, 2007 Polycom February 26, 2007 Conference event package extensions for the XCON framework draft-srinivasan-xcon-eventpkg-extensions-00 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 August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document extends the notification mechanism defined in the conference event package [2] to suit the specific needs of the XCON framework [1] and the XCON data model [3]. The document registers a new MIME-subtype for this purpose. Support for this new data format may be negotiated using Accept header semantics (as defined in RFC 3261). Srinivasan & Even Expires August 30, 2007 [Page 1] Internet-Draft xcon-eventpkg-extensions February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Limitations of current data format for notifications defined in the conference event package . . . . . . . . . . . 3 2.1. Partial updates for existing elements . . . . . . . . . . 3 2.2. Re-definition of existing elements . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Candidate elements (for partial updates) . . . . . . . . . . . 4 6. New MIME subtype definition . . . . . . . . . . . . . . . . . 5 6.1. Partial Notification Mechanism: Updates to Section 4.4 of [2] . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. Element keys: Updates to Section 4.5 of [2] . . . . . . . 5 7. Other approaches . . . . . . . . . . . . . . . . . . . . . . . 5 8. Conference-aware clients subscribing to conference state . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10.1. application/xcon-conference-info+xml MIME Registration . . 6 10.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:xcon-conference-info' . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Srinivasan & Even Expires August 30, 2007 [Page 2] Internet-Draft xcon-eventpkg-extensions February 2007 1. Introduction The XCON centralized conferencing framework [1] describes a framework for XCON based conferencing. It 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 and build upon the framework established in the conference event package [2]. For more information, refer [2] and [3]. The following section will describe the limitations of the current data format defined within the conference event package [2]. 2. Limitations of current data format for notifications defined in the conference event package [2] defines the MIME-type 'application/conference-info+xml' to be associated with the conference event package. The following section discusses a few of the limitations in the data format defined in the conference event package [2]. 2.1. Partial updates for existing elements Section 4.4, 4.5 and 4.6 of [2] specify a mechanism to send partial updates of conference state information. The algorithm (defined in Section 4.6 of [2]), however, prevents the partial notifications for non-atomic sub-elements for elements like 'available-media' (as defined in Section 5.3.4 of [2]) and 'media' XML element (as defined in Section 5.7.8 of [2]) as these elements do not contain a state attribute defined. 2.2. Re-definition of existing elements Several elements defined in [2] have been re-defined or extended for the purposes of XCON and multi-protocol support. Examples of such elements are 'conf-uris' element defined in Section 3.3.2 and 'service-uris' defined in Section 3.3.3. 3. 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. Srinivasan & Even Expires August 30, 2007 [Page 3] Internet-Draft xcon-eventpkg-extensions February 2007 4. Requirements Listed here are some of the requirements for developing an XCON-based conference event package data format. REQ-1: It should satisfy all the notifications needs defined in the conferencing framework [1]. REQ-2: The document should describe changes in behavior and describe how conference-aware clients implementing the conference event package [2] (and the data format defined therein) MAY work against the XCON defined extensions. [[ Note that this is a MAY. However, as per Section 3.4 in [2] states, all subscribers and notifiers MUST support the "application/conference-info+xml" data format.]] REQ-3: The document should define any and all changes that break normative text defined in the SIP conference event package. REQ-4: It should enable partial updates of changes in specific element extensions defined in the XCON data model [3] such as controls and list elements. [[ During IETF-67, it was determined that there would be changes required in this area. ]] REQ-5: The data format for the notification is the XCON data model [3] (which is an extension to the conference event package [2] with certain elements being re-defined). REQ-6: A general notification mechanism for sending partial updates to any XML element (stretch goal). [[ Like partial pidf. Should this be a concrete requirement? ]] 5. Candidate elements (for partial updates) As defined earlier, the following list captures elements defined in [2] not supporting 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. Conference information 'conf-uris' and 'service-uris' defined in Section 5.3.1 and Section 5.3.2 respectively of [2] Srinivasan & Even Expires August 30, 2007 [Page 4] Internet-Draft xcon-eventpkg-extensions February 2007 6. New MIME subtype definition This document defines a new MIME subtype for subscribing to and notifying conference state information. The new MIME-type 'application/xcon-conference-info+xml' defines the new content type for supporting the XCON data model. The XML schema (data format) is as defined in the XCON data model [3]. Implementations MUST follow all sections of [2] not related directly to the data model. These include, but are not limited to, Section 3, Section 4 (see annotations below), Section 8 and Section 9.1. Note: This approach will require the XCON server to support both versions if there is a need for backward compatibility. If there is lack of support for the MIME-type format defined in [2], then SIP clients (implementing [2]) will not be able to interwork with the XCON clients. 6.1. Partial Notification Mechanism: Updates to Section 4.4 of [2] The only change here is to include additional elements for partial updates (TBD). The following is a list of additional elements previously defined in [2] that are now permissible for partial updates using the data model defined in [3]. o Element 'available-media' o Element 'media' as defined in Section 5.7.8 of [2] 6.2. Element keys: Updates to Section 4.5 of [2] The only change here is to include the keys for the additional elements supporting partial updates. [TODO: add definitions here] 7. Other approaches [[ This section presents other approaches or solutions for information purposes only and will be removed from the final document once a decision has been made. ]] Alternate-1: Re-define elements that require partial updates that appear under available-media and media (as described in the previous section) in a separate section without breaking backward compatibility with [2]. Eliminate the re-defined elements and extend the base conference event package schema. This eliminates the limitations described in the Limitations section above. [[Note: This was discussed in an offline discussion and was not clean from a data model perspective. ]] Srinivasan & Even Expires August 30, 2007 [Page 5] Internet-Draft xcon-eventpkg-extensions February 2007 Alternate-2: Introduce a protocol version as a MIME parameter instead. Note that this may not satisfy all requirements for protocol processing and backward compatibility. The content type header may look like -- "application/conference-info+xml;version=2". Change the schema to include 'state' attribute in existing elements defined within the conference event package [2] that require partial updates. Alternate-3: Deprecate logic defined in the conference event package for partial updates (i.e. use of 'state' attributes is no longer required). Use a PIDF-DIFF like (or better) system for partial conference state updates and eliminate re-defined elements to conform to [2]. Alternate-4: Define a new event package. The event header may look like -- "Event: xcon-conference". Change the schema to include 'state' attribute in existing elements defined within the conference event package [2] that require partial updates. 8. Conference-aware clients subscribing to conference state Conference-aware clients implementing [2] SHOULD be able to subscribe to conference state information from the conferencing focus. The conference focus thus SHOULD support both MIME-type's defined in [2] and this document. [[Note: If Option-1, in the previous section, were to be chosen then this requirement goes away.]] 9. Security Considerations TBD 10. IANA Considerations TBD [[Note: This section only applies if Option-1a or Option-1b are chosen.]] 10.1. application/xcon-conference-info+xml MIME Registration MIME media type name: application MIME subtype name: xcon-conference-info+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as Srinivasan & Even Expires August 30, 2007 [Page 6] Internet-Draft xcon-eventpkg-extensions February 2007 specified in RFC 3023 [rfc3023] Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [rfc3023] Security considerations: See Section 10 of RFC 3023 [rfc3023] and Section 8 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 XCON data model [3] Additional Information: Magic Number: None File Extension: .xml Macintosh file type code: "TEXT" Personal and email address for further information: TBD Intended usage: COMMON Author/Change controller: TBD Srinivasan & Even Expires August 30, 2007 [Page 7] Internet-Draft xcon-eventpkg-extensions February 2007 10.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:xcon-conference-info' URI: urn:ietf:params:xml:ns:xcon-conference-info Description: This is the XML namespace for XML elements defined by [[[RFCXXXX]]] to describe the 'application/xcon-conference-info+xml' content type for the XCON extensions defined for the conference event pacakge. Registrant Contact: TBD XML: BEGIN
See RFCXXXX.