Network Working Group                                         C. Boulton
Internet-Draft                             Ubiquity Software Corporation
Expires: September 10, 2006                                 T. Melanchuk
                                                              BlankSpace
                                                            S. McGlashan
                                                         Hewlett-Packard
                                                            A. Shiratzky
                                                               Radvision
                                                           March 9, 2006


 A Conference Control Package for the Session Initiation Protocol (SIP)
              draft-boulton-conference-control-package-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 September 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines a Session Initiation (SIP) Control Package for
   Conference Control.  The control of Media Servers and their related
   resources in decomposed network architectures plays an important role



Boulton, et al.        Expires September 10, 2006               [Page 1]

Internet-Draft         Conference Control Package             March 2006


   in various Next Generation Networks.  This Control Package aims to
   fulfil Conferencing requirements using the SIP Control Framework[7].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Control Package Definition . . . . . . . . . . . . . . . . . .  3
     4.1.  Control Package Name . . . . . . . . . . . . . . . . . . .  3
     4.2.  Framework Message Usage  . . . . . . . . . . . . . . . . .  4
     4.3.  Common XML Support . . . . . . . . . . . . . . . . . . . .  4
     4.4.  CONTROL Message Body . . . . . . . . . . . . . . . . . . .  4
     4.5.  REPORT Message Body  . . . . . . . . . . . . . . . . . . .  4
   5.  Conference Schema Description  . . . . . . . . . . . . . . . .  4
     5.1.  CONTROL Message Operations . . . . . . . . . . . . . . . .  5
       5.1.1.  <create> . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1.2.  <modify> . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1.3.  <delete> . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1.4.  <event>  . . . . . . . . . . . . . . . . . . . . . . .  5
     5.2.  Configuration Objects  . . . . . . . . . . . . . . . . . .  5
       5.2.1.  Conference Configuration Object  . . . . . . . . . . .  6
       5.2.2.  Members Configuration Object . . . . . . . . . . . . .  6
       5.2.3.  <talker-event> . . . . . . . . . . . . . . . . . . . .  8
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Conf Control Schema  . . . . . . . . . . . . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Control Package Registration . . . . . . . . . . . . . . . 13
     9.2.  MIME Registration  . . . . . . . . . . . . . . . . . . . . 13
     9.3.  URN Sub-Namespace Registration . . . . . . . . . . . . . . 13
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16












Boulton, et al.        Expires September 10, 2006               [Page 2]

Internet-Draft         Conference Control Package             March 2006


1.  Introduction

   The SIP Control Framework[7] provides a generic template for
   establishment and reporting capabilities of remotely initiated
   commands.  The Framework utilizes many functions provided by the
   Session Initiation Protocol [3] (SIP) for the rendezvous and
   establishment of a reliable channel for control interactions.  The
   Control Framework also introduces the concept of a Control Package.
   A Control Package is an explicit usage of the Control Framework for a
   particular interaction set.  This specification defines a package for
   Control of Conference instances.

   A conference instance in the context of this Control Package can be
   defined as an identifiable object that represents zero or more
   associated SIP dialogs.  Control commands that explicitly reference a
   Conference using this Control Package apply to all related SIP
   dialogs (unless explicitly excluded).


2.  Conventions and Terminology

   In this document, BCP 14/RFC 2119 [1] defines the key words "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL".  In
   addition, BCP 15 indicates requirement levels for compliant
   implementations.

   The following additional terms are defined for use in this document:
   [Editors Note:TODO]


3.  Overview

   [Editors Note:TODO]


4.  Control Package Definition

   This section fulfils the mandatory requirement for information that
   MUST be specified during the definition of a Control Framework
   Package, as detailed in Section 8 of [7].

4.1.  Control Package Name

   The Control Framework requires a Control Package definition to
   specify and register a unique name.  The name of this Control Package
   is "msc-conf".




Boulton, et al.        Expires September 10, 2006               [Page 3]

Internet-Draft         Conference Control Package             March 2006


4.2.  Framework Message Usage

   The intent for the Conference Control package is for the creation,
   manipulation and deletion of conference instances.  The Conference
   Control package is intended for use in an architecture where
   application logic and media mixing are distributed.  For this reason
   the Control Framework will operate in a manner where CONTROL
   messages, as defined in the Conference Framework [7], MUST only be
   sent from the network entity providing the application logic.

4.3.  Common XML Support

   This Control package MUST have full support for Control Framework
   Formal Syntax as defined in [7].

4.4.  CONTROL Message Body

   This Control Package MUST fully support the XML schema defined in
   Section 7.1 and described in Section 5.  XML commands appearing in
   CONTROL message bodies will be derived from the <request> element in
   Section 7.1.

4.5.  REPORT Message Body

   This Control Package MUST fully support the XML schema defined in
   Section 7.1 and described in Section 5.  XML commands appearing in
   REPORT (and 200 response) message bodies will be derived from the
   <response> element in Section 7.1.


5.  Conference Schema Description

   The XML schema in Section 7.1 is designed to allow flexibility in
   initiating, modifying and terminating Conferences.  The schema can be
   split into requests and responses.  Requests, which are carried in
   CONTROL message bodies are identified by the <request> element in the
   schema.  Similarly, responses are carried either in REPORT message
   bodies or 200 responses and are defined by the <response> element in
   the schema.  The schema defines a 'conf-id' attribute which is
   associated with a <request> element.  The attribute imports a common
   conference identifier type from the core Control Framework[7].  Each
   Control operation, described in Section 5.1, MUST contain a 'conf-id'
   attribute.

   The schema defines a number of operations for <request> elements
   (described in Section 5.1) that are used to define the type of
   command that is to take place and the objects that are allowed within
   an operation (defined in Section 5.2).



Boulton, et al.        Expires September 10, 2006               [Page 4]

Internet-Draft         Conference Control Package             March 2006


   The following sub-section provides more detail on the operations.

5.1.  CONTROL Message Operations

5.1.1.  <create>

   The <create> command is used for creating initial conference
   instances.  This is achieved by including a 'Conference Configuration
   Object' (as described in Section 5.2.1) and optionally a 'Member
   Configuration Object' (as described in Section 5.2.2).  The value
   contained in the <request> attribute 'conf-id' needs MUST be unique.

5.1.2.  <modify>

   The <modify> command is used for manipulating conference instances.
   This is achieved by optionally including a 'Conference Configuration
   Object' (as described in Section 5.2.1) and optionally a 'Member
   Configuration Object' (as described in Section 5.2.2).  Either a
   'Conference Configuration Object' or a 'Member Configuration Object'
   MUST exist in a modify command.  The value contained in the <request>
   attribute 'conf-id' MUST reference an existing conference instance.

5.1.3.  <delete>

   The <delete> command is used for removing conference instances.  No
   configuration objects are required or permitted to delete a
   conference instance.  The value contained in the <request> attribute
   'conf-id' needs to reference an existing conference instance.

5.1.4.  <event>

   The <event> command is used for reporting subsequent events related
   to an initial command request.  Events can only be carried in a
   REPORT message.  Only one event type is defined in the conference
   package which reports active speaker information for a conference
   instance.  More information is provided later in this document.

5.2.  Configuration Objects

   Request operations contained in CONTROL messages (create/modify)
   contain configuration objects.  The configuration objects can be
   split into two distinct areas - configuration and parameters related
   to the conference instance and the members of the conference
   instance.  The two configuration objects are represented by the
   <conf-config> and <member-config>.  The following subsections provide
   more information on the two Configuration objects.





Boulton, et al.        Expires September 10, 2006               [Page 5]

Internet-Draft         Conference Control Package             March 2006


5.2.1.  Conference Configuration Object

   The Conference Configuration Object consists of the following
   elements:

5.2.1.1.  <audio-settings>

   The <audio-settings> element then comprises the following features:

5.2.1.1.1.  <active-talker>

   The <active-talker> element is included if the controlling entity
   wishes to receive notifications of active speakers.  Active speaker
   notifications are delivered using the <event> (Section 5.1.4) element
   container and the <talker-event> event type (Section 5.2.3).

   attributes:

   status: The <interval> attribute represents the minimum amount of
   time that must lapse before further talker events can be generated.
   The default value is "0" which suppresses notifications.

5.2.1.1.2.  <audio-mixing>

   <audio-mixing> element is a string indicating the audio stream mixing
   policy.  Defined values are: "nbest" and "manual" (audio stream is
   selected manually by the AS via an external floor control event).
   The default value is "nbest".  The attribute is optional.

5.2.1.1.3.  <reserved-talkers>

   <reserved-talkers> element represents the number of guaranteed
   speaker slots to be reserved for the conference.  The attribute is
   optional.

5.2.1.1.4.  <reserved-talkers>

   <reserved-listeners> element represents the number of guaranteed
   listener slots to be reserved for the conference.  The attribute is
   optional.

5.2.1.2.  <video-settings>

   [Editors Note: TODO].

5.2.2.  Members Configuration Object

   The Members Configuration Object consists of the following elements:



Boulton, et al.        Expires September 10, 2006               [Page 6]

Internet-Draft         Conference Control Package             March 2006


5.2.2.1.  <add-member>

   This element is included when a member is to be added to a conference
   instance.  The <add-member> element contains a <connection-id>
   element which supplies the reference to the SIP dialog that is to be
   added to the Conference Instance (This is imported from the Control
   Framework[7]).  The <add-member> element can appear multiple times.

   attributes:

   status: The <add-member> element can appear multiple times in a
   single command and is used to add a member to a conference instance.
   For this reason, the success of each <add-member> operation is
   recorded in the status attribute.  The default value is false which
   is then set to true and returned in the 200 response.

5.2.2.2.  <modify-member>

   This element is included when a member is to be modified in a
   conference instance.  The <modify-member> element contains a
   <connection-id> element which supplies the reference to the SIP
   dialog that is to be modified in a Conference Instance (This is
   imported from the Control Framework[7]).  The <add-member> element
   can appear multiple times.

   attributes:

   status: The <modify-member> element can appear multiple times in a
   single command and is used to modify a member of a conference
   instance.  For this reason, the success of each <modify-member>
   operation is recorded in the status attribute.  The default value is
   false which is then set to true and returned in the 200 response.

5.2.2.3.  <remove-member>

   This element is included when a member is to be removed from a
   conference instance.  The <remove-member> element contains a
   <connection-id> element which supplies the reference to the SIP
   dialog that is to be removed from a Conference Instance (This is
   imported from the Control Framework[7]).  The <add-member> element
   can appear multiple times.

   attributes:

   status: The <remove-member> element can appear multiple times in a
   single command and is used to remove a member from a conference
   instance.  For this reason, the success of each <remove-member>
   operation is recorded in the status attribute.  The default value is



Boulton, et al.        Expires September 10, 2006               [Page 7]

Internet-Draft         Conference Control Package             March 2006


   false which is then set to true if successful and returned in the 200
   response.

5.2.3.  <talker-event>

   The XML schema also defines the generation of responses to the
   operations carried out in <request> elements.  It should be noted
   that responses have nothing to do with the status of the Control
   Framework message transaction (CONTROL, REPORT) which has its own set
   of responses defined in [7].  The result of the operation is carried
   in the body of either a Control Framework 200 response to a CONTROL
   message or in a REPORT message (depending on timing of operation).
   The following codes are defined to appear in the <response> element:

   Success
   200 OK

   Client Error
   400 Bad Request
   401 Conf already exists
   402 Conf does not exist
   401 Unknown or Unsupported Element
   402 Element Required
   403 Unknown or Unsupported Attribute
   404 Attribute Required

   Server Error
   500 Internal Server Error
   503 Service Unavailable
   520 No Resource

   [Editors Note: TODO - response section needs to be completed
   properly.


6.  Examples


7.  Formal Syntax

   [Editors note: XML schema goes here.]

7.1.  Conf Control Schema

   Text

   <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema targetNamespace="urn:ietf:params:xml:ns:control:msc-conf"



Boulton, et al.        Expires September 10, 2006               [Page 8]

Internet-Draft         Conference Control Package             March 2006


       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns="urn:ietf:params:xml:ns::control:msc-conf"
       xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
       elementFormDefault="qualified" attributeFormDefault="unqualified">
       <xs:include schemaLocation="common-schema.xsd"/>

       <xs:element name="msc-conf">
          <xs:complexType>
            <xs:choice>
              <xs:element name="request" type="msc-conf-request"/>
              <xs:element name="response" type="msc-conf-response"/>
            </xs:choice>
          </xs:complexType>
       </xs:element>

       <xs:complexType name="msc-conf-request">
          <xs:choice>
            <xs:element name="create" type="createType"/>
            <xs:element name="modify" type="modifyType"/>
            <xs:element name="delete" type="xs:empty"/>
            <xs:element name="event" type="eventType"/>
            <xs:any namespace="##other" processContents="lax" minOccurs="0"
               maxOccurs="unbounded"/>
          </xs:choice>
          <xs:attribute name="conf-id" type="fw:conf-id" use="required"/>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:complexType>

         <xs:complexType name="msc-conf-response">
           <xs:sequence>
             <xs:element name="reason" minOccurs="0">
               <xs:simpleType>
                 <xs:restriction base="xs:string">
                   <xs:pattern value="[a-zA-Z0-9.-_]+"/>
                 </xs:restriction>
               </xs:simpleType>
             </xs:element>
             <xs:element name="member-operations" type="memberConfigType"/>
            </xs:sequence>
            <xs:attribute name="response">
              <xs:simpleType>
                <xs:restriction base="xs:string">
                  <xs:pattern value="\d{3}"/>
                </xs:restriction>
              </xs:simpleType>
            </xs:attribute>
         </xs:complexType>




Boulton, et al.        Expires September 10, 2006               [Page 9]

Internet-Draft         Conference Control Package             March 2006


         <xs:complexType name="createType">
           <xs:sequence>
             <xs:element name="conf-config" type="confConfigType"
                minOccurs="1" maxOccurs="1"/>
             <xs:element name="member-config" type="memberConfigType"
                minOccurs="0" maxOccurs="1"/>
             <xs:any namespace="##other" processContents="lax" minOccurs="0"
                maxOccurs="unbounded"/>
           </xs:sequence>
         </xs:complexType>

         <xs:complexType name="modifyType">
          <xs:sequence>
             <xs:element name="conf-config" type="confConfigType"
                minOccurs="0" maxOccurs="1"/>
             <xs:element name="member-config" type="memberConfigType"
                minOccurs="0" maxOccurs="1"/>
             <xs:any namespace="##other" processContents="lax" minOccurs="0"
               maxOccurs="unbounded"/>
           </xs:sequence>
          </xs:complexType>

          <xs:complexType name="confConfigType">
            <xs:sequence>
              <xs:element name="audio-settings" minOccurs="0" maxOccurs="1"
                      default="0">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="active-talker" minOccurs="0" maxOccurs="1">
                      <xs:complexType>
                        <xs:attribute name="interval" type="xs:positiveInteger"
                           default="0"/>
                      </xs:complexType>
                    </xs:element>
                    <xs:element name="audio-mixing" type="audioMixingType"
                            minOccurs="0" maxOccurs="1" default="nbest"/>
                    <xs:element name="reserved-talkers" type="xs:nonNegativeInteger"
                            minOccurs="0" maxOccurs="1" default="0"/>
                    <xs:element name="reserved-listeners" type="xs:nonNegativeInteger"
                            minOccurs="0" maxOccurs="1" default="0"/>
                    <xs:any namespace="##other" processContents="lax" minOccurs="0"
                            maxOccurs="unbounded"/>
                    </xs:sequence>
                    <xs:anyAttribute namespace="##any" processContents="lax"/>
                </xs:complexType>
              </xs:element>
              <xs:element name="video-settings" minOccurs="0" maxOccurs="1"
                    default="0">



Boulton, et al.        Expires September 10, 2006              [Page 10]

Internet-Draft         Conference Control Package             March 2006


                       .
                       .
                      TODO
                       .
                       .
               </xs:element>
            </xs:sequence>
          </xs:complexType>

          <xs:complexType name="memberConfigType">
           <xs:sequence>
             <xs:element name="add-member" type="addMemberType"
                     minOccurs="0" maxOccurs="1"/>
             <xs:element name="modify-member" type="modifyMemberType"
                     minOccurs="0" maxOccurs="1"/>
             <xs:element name="remove-member" type="removeMemberType"
                     minOccurs="0" maxOccurs="1"/>
             <xs:any namespace="##other" processContents="lax" minOccurs="0"
                     maxOccurs="unbounded"/>
             </xs:sequence>
             <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>

          <xs:complexType name="addMemberType">
            <xs:sequence>
              <xs:element name="connection-id" type="connection-idType"
                 minOccurs="1" maxOccurs="unbounded"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0"
               maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="status" type="xs:boolean"
               default="false" use="required"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>

          <xs:complexType name="modifyMemberType">
            <xs:sequence>
              <xs:element name="connection-id" type="connection-idType"
                 minOccurs="1" maxOccurs="unbounded"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0"
                 maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="status" type="xs:boolean"
               default="false" use="required"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>

          <xs:complexType name="removeMemberType">



Boulton, et al.        Expires September 10, 2006              [Page 11]

Internet-Draft         Conference Control Package             March 2006


            <xs:sequence>
              <xs:element name="connection-id" type="connection-idType"
                 minOccurs="1" maxOccurs="unbounded"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0"
                 maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="status" type="xs:boolean"
               default="false" use="required"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>

          <xs:complexType name="connection-idType">
            <xs:sequence>
              <xs:element name="id" type="fw:connection-id"
                 minOccurs="1" maxOccurs="1"/>
              <xs:element name="direction" type="directionType"
                 minOccurs="0" maxOccurs="unbounded" default="both"/>
              <xs:element name="label" type="xs:string"
                 minOccurs="0" maxOccurs="unbounded"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0"
                 maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>

          <xs:complexType name="eventType">
            <xs:choice>
              <xs:element name="talker-event" type="talkerEventType"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0"
               maxOccurs="unbounded"/>
          </xs:choice>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>

          <xs:complexType name="talkerEventType">
            <xs:sequence>
               <xs:element name="id" type="fw:connection-id"
               minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
          </xs:complexType>

          <xs:simpleType name="audioMixingType">
            <xs:restriction base="xsd:NMTOKEN">
              <xs:enumeration value="nbest"/>
              <xs:enumeration value="manual"/>
            </xs:restriction>
          </xs:simpleType>




Boulton, et al.        Expires September 10, 2006              [Page 12]

Internet-Draft         Conference Control Package             March 2006


          <xs:simpleType name="directionType">
            <xs:restriction base="xs:NMTOKEN">
              <xs:enumeration value="both"/>
              <xs:enumeration value="transmit"/>
              <xs:enumeration value="receive"/>
            </xs:restriction>
          </xs:simpleType>


      </xs:schema>


   Figure 1: Conference Package XML Schema


8.  Security Considerations

   Security Considerations to be included in later versions of this
   document.


9.  IANA Considerations

   This document registers a new SIP Control Framework Package, a new
   MIME type, and a new XML namespace.

9.1.  Control Package Registration

   Control Package name: msc-conf

9.2.  MIME Registration

   TODO: application/msc-conf+xml

9.3.  URN Sub-Namespace Registration

   TODO: urn:ietf:params:xml:ns:msc-conf


10.  Acknowledgments

   The authors would like to thank Ian Evans from Ubiquity Software for
   help in the design of concepts contained in this document.


11.  References





Boulton, et al.        Expires September 10, 2006              [Page 13]

Internet-Draft         Conference Control Package             March 2006


11.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [2]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [3]  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.

   [4]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
        Responses in Session Initiation Protocol (SIP)", RFC 3262,
        June 2002.

   [5]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [6]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

   [7]  Boulton, C., "A Control Framework for the Session Initiation
        Protocol (SIP)", draft-boulton-sip-control-framework-00 (work in
        progress), December 2005.

   [8]  McGlashan, S., Burnett, D., Carter, J., Danielsen, P., Ferrans,
        J., Hunt, A., Lucas, B., Porter, B., Rehor, K., and S.
        Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version
        2.0", W3C Recommendation, March 2004.

   [9]  Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E., and F.
        Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)",
        W3C Recommendation, February 2004.














Boulton, et al.        Expires September 10, 2006              [Page 14]

Internet-Draft         Conference Control Package             March 2006


Authors' Addresses

   Chris Boulton
   Ubiquity Software Corporation
   Building 3
   Wern Fawr Lane
   St Mellons
   Cardiff, South Wales  CF3 5EA

   Email: cboulton@ubiquitysoftware.com


   Tim Melanchuk
   BlankSpace

   Email: tim.melanchuk@gmail.com


   Scott McGlashan
   Hewlett-Packard
   Gustav III:s boulevard 36
   SE-16985 Stockholm, Sweden

   Email: scott.mcglashan@hp.com


   Asher Shiratzky
   Radvision
   24 Raoul Wallenberg st
   Tel-Aviv, Israel

   Email: ashers@radvision.com



















Boulton, et al.        Expires September 10, 2006              [Page 15]

Internet-Draft         Conference Control Package             March 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Boulton, et al.        Expires September 10, 2006              [Page 16]