draft-srinivasan-xcon-eventpkg-extension-01

1
draft-srinivasan-xcon-eventpkg-extension-01

• IETF July 2007
• Srivatsa Srinivasan
• srivats_at_microsoft.com
• Roni Evenroni.even_at_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-infoxml
• .
• lt?xml version"1.0" encoding"UTF-8"?gt
  ltconference-info xmlns"urnietfparamsxmlnsco
  nference-info" entity"sipsconf233_at_example.com"
  state"partial" version"1"gt lt!-- CONFERENCE
  INFO --gt ltavailable-mediagt ltentry
  label"34569"gt ltdisplay-textgtmain
  audiolt/display-textgt
  lttypegtaudiolt/typegt
  ltstatusgtsendrecvlt/statusgt
  ltcontrolsgt
• ltmutegttruelt/mutegt
• ltgaingt0lt/gaingt lt/controlsgt
• lt/entrygt lt/available-mediagtlt/c
  onference-infogt

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 ltconference-infogt
• Element ltusersgt
• Element ltusergt
• Element ltendpointgt
• Element ltsidebars-by-valgt
• Element ltsidebars-by-refgt"

7
Problem statement(Recap)

• Controls are now defined under ltavailable-mediagt
  and ltmediagt in the XCON data model
• RFC 4575 Missing ltmediagt and ltavailable-mediagt
  partial updates support
• Need to support partial updates

8
With the proposed new media type (Recap)

• Content-Type application/xcon-conference-infoxm
  l
• .
• lt?xml version"1.0" encoding"UTF-8"?gt
  ltconference-info xmlns"urnietfparamsxmlnsco
  nference-schema" entity"sipsconf233_at_example.com"
  state"partial" version"1"gt lt!--
  CONFERENCE INFO --gt ltavailable-media
  state"partial"gt ltentry label"34569"
  state"partial"gt ltcontrols
  state"partial"gt
• ltmutegttruelt/mutegt
• lt/controlsgt
• lt/entrygt lt/available-mediagtlt/con
  ference-infogt

9
Backward compatibility

• Servers SHOULD implement BOTH media types
• application/conference-infoxml
• application/xcon-conference-infoxml
• 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.