1. draft-srinivasan-xcon-eventpkg- extension-01 IETF July 2007 Srivatsa Srinivasan srivats@microsoft.com Roni Even roni.even@polycom.co.il

2. Goals for the document (1) Satisfy notification needs (over SIP) defined in the XCON conferencing framework and XCON data model by using concepts from RFC 4575 (2) Support partial updates of elements previously defined without any (3) Backward compatibility: Specify how servers should be written so that clients implementing RFC 4575 will work.

3. Recap: Options discussed (and previously eliminated from IETF-68) Option-1: New media type – A) Existing XML namespace (‘conference-info’), extended schema with new elements under a new XML namespace – B) (current data model) Entirely new XML namespace (‘conference-schema’) and schema (copying elements from conf. event package) Option-2: No media type, Existing XML Namespace, Extended Schema, redefine controls under new XML elements Option-3: New event package with new partial update mechanism (perhaps like PIDF-DIFF) Option-4: Propose a RFC4575bis update with new data format and schema as proposed by XCON

4. Suggestions from prior RFCs (Recap) RFC 3265: "Designers of event packages are strongly encouraged to re-use existing MIME types for message bodies where practical. " RFC 3863: PIDF RFC 4119: PIDF-LO – Defined under presence – Simply uses a Sub-Namespace in XML and re-uses the same/existing MIME type. – No new MIME/media type defined for event packages, just a new data format in a new namespace for those elements that were extended.

5. Example (Recap) State change: The main audio with a label of "34569" changes mute state from false to true. Content-Type: application/conference-info+xml …. main audio audio sendrecv true 0

6. Elements supporting partial updates (Recap) RFC 4575: "Below is the complete list of elements permissible to use the partial notifications mechanism defined in this specification. (Note that future partial notifications mechanisms can potentially be applicable to additional elements.) – Element – Element "

7. Problem statement (Recap) Controls are now defined under and in the XCON data model RFC 4575 Missing and partial updates support Need to support partial updates

8. With the proposed new media type (Recap) Content-Type: application/xcon-conference-info+xml …. true

9. Backward compatibility Servers SHOULD implement BOTH media types: ‘application/conference-info+xml’ ‘application/xcon-conference-info+xml’ Questions: – What does the WG think about this? – Should we make this a MUST?

10. Overview of changes Changes from -00 – Registration template for media type using RFC 4288 – Some new wording WG document? Proposed changes coming in -02 – Require servers to implement both conference event package and xcon based data format. – Expanded "Introduction" section – Re-ordering of sections for easy readability – Examples

11. Appendix (meeting notes from IETF-68) Roni - Xcon event package extensions Complements work in data model and complements conference event package Overcome 4575 Sipping conference event limitations in the Xcon data model. Here are our three options 1) Extend RFC 4575 with a new Mime type, or 2) change the data model to keep compatibility with 4575 - not clean from data model perspective, or 3) define a new event package Adam - preference is #1 Roni - just means the server will have to support both elements. Roni pointed out that the data model draft says it? informational Adam - data model itself is not supposed to be informational, it will have to be standards draft Roni - it will need to be changed, for example dealing with current speaker notification, have to poll the data model, proposed status elements in the event package Oscar - these status elements should be in the data model Roni - Way forward agreed, status elements should be kept in the data model. Has to take into account Cullen? feedback on the list.