conference package extensions draft-levin-xcon-conference-package-ext-00 by orit levin

Nov 6 – 11, 2005 XCON WG IETF54 Slide #1

Conference Package Extensions

draft-levin-xcon-conference-package-ext-00by Orit Levin

The Discussion Starter


The Objectives

• How? - Define extensibility guidelines

• What info? - Define additional conferencing data

• Expose the main objects to external schemas


How the Conference Package can be extended

The XML-related issues…


The Basic Package Extensibility

<xs:complexType name="conference-description-type"> <xs:sequence> <xs:element name="display-text" type="xs:string"

minOccurs="0"/> …………………………………………………………………. <xs:element name="available-media" type="conference-media-

type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax“

maxOccurs="unbounded"/> </xs:sequence> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/></xs:complexType>


The Conference Package Extensibility Requirements

• IETF MUST be capable to extend any schema construct with additional elements

• A vendor MUST be capable to extend any schema construct with additional elements

• It MUST be possible to have extensions from different namespaces in a single XML document

• The resultant document MUST adhere to a valid schema

• The standard extended documents MUST be backwards compatible


The Naïve ApproachResults in Invalid XML

<xs:complexType name="conference-description-type"> <xs:sequence> <xs:element name="display-text" type="xs:string"

minOccurs="0"/> …………………………………………………………………. <xs:element name="available-media" type="conference-media-

type" minOccurs="0"/> <xs:element ref="cix:disclaimer" minOccurs="0"/> <xs:any namespace="##other" processContents="lax"

maxOccurs="unbounded"/></xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/></xs:complexType>


The XML Extensibility Issue

• According to the XML standard, a parser recognizing document element contents MUST be able to decide, without look ahead, which content model token to match with the current input token, while processing the document from left to right

• This requirement creates the known “ambiguous content” problem, which makes the XML extensibility difficult

• Different applications use different approaches, but no “ultimate” solution exists

• Some implementations just don’t schematize the extensions as an integral part of the .xsd, instead they process the extension section “manually”, i.e. outside of the XML automatic one step parsing


Extensibility:The Proposed Solution

<xs:complexType name="conference-description-type"> <xs:sequence> <xs:element name="display-text" type="xs:string" minOccurs="0"/> …………………………………………………………………. <xs:element name="available-media" type="conference-media-type"

minOccurs="0"/> <xs:element ref="cix:disclaimer" minOccurs="0"/> <xs:sequence minOccurs="0"> <xs:element ref="cis:separator"/> <xs:any namespace="##other" processContents="lax"



What It Gives Us

• For the entity receiving the document

– This is a valid schema, and therefore can be parsed by an XML compliant compiler

• For the entity generating the document

– If no extensions are included in the document, the “separator” doesn’t have to be included either

• Extensions can be introduced in steps (e.g. versions) as long as the order is known

• Extensions can belong to different namespaces


Example1: A Single StepStandard or Vendor Extensions


minOccurs="0"/> <xs:element ref=“cix:disclaimer" minOccurs="0"/> <xs:sequence minOccurs="0"> <xs:element ref="cis:separator"/> <xs:any namespace="##other" processContents="lax"



Example2:Standard and Vendor Extensions


minOccurs="0"/> <xs:element ref="cix:disclaimer" minOccurs="0"/> <xs:element ref=“ms:disclaimer" minOccurs="0"/> <xs:sequence minOccurs="0"> <xs:element ref="cis:separator"/> <xs:any namespace="##other" processContents="lax"



The Proposed Solution PropertiesSummary

• Pros:– Backwards compatible with the basic conference package– Automatic parsing by a standard XML compiler

• The limitation – the extensions order must be known and predefined in the .xsd– Every time a standard extension is defined its order MUST

be defined relatively to already defined standard extensions– In order to support a new standard extension, the .xsd needs

to be rearranged such that all proprietary extensions appear after the latest standard extension

– If extensions from different vendors need to be supported by a certain product, the order of these extensions needs to be agreed upon


What information needs to be added to the basic package

and why …


The Actual Extensions

• Conference state that needs to be distributed to subscribers

• Candidates for extensions:– Floor Control identifiers and state– Authorization information– Etc.


Using the Conference Package XML definitions for more than

events only

For Conference Control Protocols…


Exposing the Main Objects• Reason: reusing parts of the schema without

prefixing each internal element

• The root “conference” object exists already:<xs:element name="conference-info" type="conference-

type"

• The suggested schema additions:<xs:attribute name="state" type="state-type"/>

<xs:element name="media" type="media-type"/>

<xs:element name="endpoint" type="endpoint-type"/>

<xs:element name="user-roles" type="user-roles-type"/>

<xs:element name="user" type="user-type"/>


Example: addConference()CCCP Primitive Definition

xmlns:ci="urn:ietf:params:xml:ns:conference-info"

<xs:complexType name="add-conference-type"> <xs:sequence> <xs:element ref="ci:conference-info"/> <xs:any namespace="##other" processContents="lax" minOccurs="0"

maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other“ processContents="lax"/></xs:complexType>


The Corresponding XML Document

<addConference> <conference-info entity="sip:[email protected]"

xmlns="urn:ietf:params:xml:ns:conference-info"> <conference-description> <subject>Phone conference to discuss our design</subject> <conf-uris> <entry> <uri>tel:+1-8666119036</uri> <display-text>pstn bridge</display-text> </entry> </conf-uris> </conference-description> </conference-info></addConference>


Example: addUser()CCCP Primitive Definition

xmlns:ci="urn:ietf:params:xml:ns:conference-info"

<xs:complexType name="add-user-type">

<xs:sequence>

<xs:element name="conferenceKeys" type="tns:conference-keys-type"/>

<xs:element ref="ci:user"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0“ maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>


The Corresponding XML Document

<addUser> <conferenceKeys confEntity="sip:[email protected]"/> <user entity="sip:[email protected]“ xmlns="urn:ietf:params:xml:ns:conference-info"> <display-text>Bob Hoskins</display-text> <roles> <entry>presenter</entry> </roles>

</user></addUser>


Thank you!

The Conference Control Protocol discussion will be continued

tomorrow…

conference package extensions draft-levin-xcon-conference-package-ext-00 by orit levin

Documents