XCON Working Group M. Barnes
Internet-Draft Nortel
Expires: December 26, 2006 C. Boulton
Ubiquity Software Corporation
June 24, 2006
Centralized Conferencing Manipulation Protocol
draft-barnes-xcon-ccmp-01
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 December 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
"A Framework and Data Model for Centralized Conferencing" defines a
model whereby client intereaction is required for creation, deletion,
and manipulation of a conference, as well as querying the state of a
conference. The Centralized Conferencing Manipulation Protocol
(CCMP) defined in this document provides the appropriate mechanisms
for these protocol interactions. CCMP is based on the Simple Object
Access Protocol (SOAP), with the data necessary for the interactions
Barnes & Boulton Expires December 26, 2006 [Page 1]
Internet-Draft CCMP June 2006
specified via Web Services Description Language (WSDL).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
5.1. Identifying a Conference Instance . . . . . . . . . . . . 5
5.2. Constructing a CCMP request . . . . . . . . . . . . . . . 5
5.2.1. Query Blueprints . . . . . . . . . . . . . . . . . . . 5
5.2.2. Get Template . . . . . . . . . . . . . . . . . . . . . 6
5.2.3. Create a Conference Object (Explicitly) . . . . . . . 6
5.2.4. Create a Conference Object (Implicitly) . . . . . . . 6
5.2.5. Manipulate a Conference Object . . . . . . . . . . . . 6
5.2.6. Query Conference Object . . . . . . . . . . . . . . . 6
5.2.7. Delete Conference Object . . . . . . . . . . . . . . . 6
5.3. Sending a CCMP Request . . . . . . . . . . . . . . . . . . 7
6. System Architecture . . . . . . . . . . . . . . . . . . . . . 7
7. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 9
8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Query Blueprints . . . . . . . . . . . . . . . . . . . . . 9
8.2. Get Template . . . . . . . . . . . . . . . . . . . . . . . 9
8.3. Create Conference Object . . . . . . . . . . . . . . . . . 9
8.4. Manipulate Conference Object . . . . . . . . . . . . . . . 9
8.5. Query Conference Object . . . . . . . . . . . . . . . . . 9
8.6. Delete Conference Object . . . . . . . . . . . . . . . . . 9
9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. WSDL Definition . . . . . . . . . . . . . . . . . . . . . . . 11
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Barnes & Boulton Expires December 26, 2006 [Page 2]
Internet-Draft CCMP June 2006
1. Introduction
The Framework and Data Model for Centralized Conferencing [6] defines
a signaling agnostic data model, naming conventions and logical
entities required for constructing advanced conferencing systems. A
primary concept introduced in the framework and data model for
centralized conferencing is the existence of a conference object.
The conference object is a logical representation of a conference
instance, which represents the current state and capabilities of a
conference.
It is the purpose of this document to allow the manipulation of a
conference object by authenticated and authorized clients. This is
achieved using an appropriate client-server Remote Procedure Call
(RPC) mechanism. In this document the Simple Object Access Protocol
(SOAP) has been chosen to carry out the appropriate client-server
protocol transactions.
The common information contained in all conference objects is defined
using an XML representation such as the one introduced in Conference
Package [7] and 'A Common Conference Information Data Model for
Centralized Conferencing' [9]. These data structures are used as the
basis for the Web Services Description Language (WSDL) [3] definition
and XML schema.
This document first provides an overview of the protocol operations
in Section 5, followed by a system architecture in Section 6. The
detailed potocol operation information is provided in Section 8. An
XML schema is provided in Section 9. WSDL information is detailed in
Section 10 and some example interactions in Section 11.
2. Conventions
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.
3. Terminology
This document reuses the terminology defined in the framework and
data model for centralized conferencing [6]. In addition, the
following acronyms and terms are used in this document:
Barnes & Boulton Expires December 26, 2006 [Page 3]
Internet-Draft CCMP June 2006
SOAP: Simple Object Access Protocol.
WSDL: Web Services Description Language. WSDL is an XML format for
describing network services as a set of endpoints operating on
messages containing either document-oriented or procedure-oriented
information.
W3C: World Wide Web Consortium. The organization that developed the
SOAP and WSDL specifications referenced within this document.
4. Motivation
SOAP is chosen as the RPC mechanism due to its compatibility with the
requirements for the conference control protocol as introduced in the
framework and data model for centralized conferencing. SOAP is a
lightweight protocol for exchange of information in a decentralized,
distributed environment. It is an XML based protocol that consists
of three parts: an envelope that defines a framework for describing
what is in a message and how to process it, a set of encoding rules
for expressing instances of application-defined datatypes, and a
convention for representing remote procedure calls and responses.
SOAP can be used with a variety of transport protocols. For the
purposes of its role in providing the basis for the conference
control protocol, HTTP is the chosen transport. The advantages of
the use of SOAP as the basis for the conference control protocol are
deemed to be the re-use of existing standards, the ease of software
development, the availability of tools, and the ease of integration
with deployed systems.
WSDL is a natural fit for specifying the content of the conference
control protocol messages. WSDL is an XML format for describing
network services as a set of endpoints operating on messages
containing either document-oriented or procedure-oriented
information. The operations and messages are described abstractly,
and then bound to a concrete network protocol and message format to
define an endpoint. Related concrete endpoints are combined into
abstract endpoints (services). WSDL is extensible to allow
description of endpoints and their messages regardless of what
message formats or network protocols are used to communicate,
however, the only bindings described in this document describe how to
use WSDL in conjunction with SOAP.
[Editor's note: the current content of this document is very
incomplete. This document can very easily be combined with [10] as a
starting point for a very comprehensive document once the XCON WG
agrees on the fundamental verbs and nouns (and required level of
granularity) for the protocol. ]
Barnes & Boulton Expires December 26, 2006 [Page 4]
Internet-Draft CCMP June 2006
5. Overview of Operation
The primary function of this document is to provide a conference
control client with the ability to carry out specific operations on a
conference object. As mentioned previously, SOAP is used as the the
XML RPC mechanism to fulfill such operations.
A conference control client wishing to carry out operations on a
particular conference object follows a series of steps as detailed in
the following sections.
5.1. Identifying a Conference Instance
For any operation that is to be carried out on an existing conference
object, a unique identifier is required. The framework and data
model for centralized conferencing [6] defines the appropriate
conference object identifier.
[Editors Note: Requests using this mechanism need to convey the
appropriate conference instance identifier as defined in the XCON
Framework. This will be included in later versions of this
document.]
Operations can be initiated from a conference control client for the
purpose of creating a conference object. To achieve this, an
operation is executed without specifying a unique conference object
identifier. If the operation is successful, the unique conference
object identifier be included in the SOAP response transaction.
[Editors Note: More detail to be provided. Again, need to discuss
inclusion of conference identifier]
5.2. Constructing a CCMP request
The construction of the SOAP envelope associated with a conference
control request message complies fully with the WSDL, as defined in
Section 10. Construction of a valid conference control protocol
message includes the options, discussed in the following sections,
depending upon the function and associated information desired by the
conference control client.
5.2.1. Query Blueprints
The Query Blueprints operation is used by a client to query a system
for its capabilities. These capabilities are represented by
blueprints, as specified in [6]. The blueprints are comprised of
common conference information initialized to specific values and
ranges, and typically a single template for specifying media
Barnes & Boulton Expires December 26, 2006 [Page 5]
Internet-Draft CCMP June 2006
characteristics, etc.
5.2.2. Get Template
The Get Template operation is used by a client to query a system for
a specific template. The templates are either included in the
blueprint by-value or by-reference. In the case of by-reference, a
client may need to obtain any new template that it has not previously
used for that system.
5.2.3. Create a Conference Object (Explicitly)
This conference control operation is used by a client to create and
reserve a conference object for that system based upon a specific
blueprint.
5.2.4. Create a Conference Object (Implicitly)
This conference control operation is used by a client to construct a
request to create a conference without providing a conference object
based on a specific blueprint. This results in the creation and
reservation of an instance of the default conference object. The
default conference object is specific to a conferencing system and
its specification is outside the scope of this document.
5.2.5. Manipulate a Conference Object
During the lifetime of a conference, this conference control
operation is used by a conference control client to manipulate a
conference object. This includes the ability to pass relevant
fragments of the conference object along with relevant operation
types (add, delete, modify, etc.).
5.2.6. Query Conference Object
This conference control operation is used to retrieve the current
representation of a conference object and requires the unique
conference identifier be provided by the client, as discussed in
Section 5.1.
5.2.7. Delete Conference Object
This conference control operation is used to delete the current
representation of a conference object and requires the unique
conference identifier be provided by the client, as discussed in
Section 5.1.
Further details of these operations is provided in Section 8
Barnes & Boulton Expires December 26, 2006 [Page 6]
Internet-Draft CCMP June 2006
5.3. Sending a CCMP Request
A constructed CCMP message that is compliant to the SOAP WSDL is then
ready to be executed using appropriate protocol operations. Detail
describing the protocol operations can be found in Section 8.
[Editors Note: It is fully expected that the Operations will involve
asynchronous transactions. This section will be expanded at a later
date to allow synchronous transactions. ].
6. System Architecture
CCMP supports the framework and data model for centralized
conferencing [6]. Figure 1 depicts a subset of the 'Conferencing
System Logical Decomposition' architecture from the framework and
data model for centralized conferencing document. It illustrates the
role that CCMP assumes within the overall centralized architecture.
Barnes & Boulton Expires December 26, 2006 [Page 7]
Internet-Draft CCMP June 2006
........................................................
. Conferencing System .
. .
. +---------------------------------------+ .
. | C O N F E R E N C E O B J E C T | .
. +-+-------------------------------------+ | .
. | C O N F E R E N C E O B J E C T | | .
. +-+-------------------------------------+ | | .
. | C O N F E R E N C E O B J E C T | | | .
. | | | | .
. | | |-+ .
. | |-+ .
. +---------------------------------------+ .
. ^ .
. | .
. v .
. +-------------------+ .
. | Conference Control| .
. | Server | .
. +-------------------+ .
. ^ .
.........................|..............................
|
|Conference
|Control
|Protocol
|
|
.........................|..............................
. V .
. +----------------+ .
. | Conference | .
. | Control | .
. | Client | .
. +----------------+ .
. .
. Conferencing Client .
........................................................
Figure 1: Conference Client Interaction
CCMP serves as the Conference Control Protocol, allowing the
conference control client to interface with the conference object
maintained by the conference control server, as represented in
Figure 1. Conference Control is one set of functionality for
advancing conferencing supported by a conferencing client. Other
functions are discussed in the framework and data model for
Barnes & Boulton Expires December 26, 2006 [Page 8]
Internet-Draft CCMP June 2006
centralized conferencing document and related documents.
7. Transaction Model
The transaction model for CCMP complies fully with SOAP version 1.2
as defined by W3C in [ref].
8. Protocol Operations
This section provides descriptive text for the basic protocol
operations for CCMP. A conference control client and conference
control server MUST provide the ability to action all of the protocol
operations in this section and MUST fully implement the SOAP WSDL
schema defined in Section 10 which uses HTTP operations as the
transport mechanism. The following sections provide more detail on
specific protocol operations.
8.1. Query Blueprints
TODO - describe use in conjunction with HTTP GET.
8.2. Get Template
TODO - describe use in conjunction with HTTP GET.
8.3. Create Conference Object
TODO - describe use in conjunction with HTTP POST.
8.4. Manipulate Conference Object
TODO - describe use in conjunction with HTTP POST.
8.5. Query Conference Object
TODO - describe use in conjunction with HTTP GET.
8.6. Delete Conference Object
TODO - describe use in conjunction with HTTP POST.
9. XML Schema
[Editor's note: This current version is currently bare bones. It
will be enhanced and updated and also needs to align with the
Barnes & Boulton Expires December 26, 2006 [Page 9]
Internet-Draft CCMP June 2006
fundamental XCON data model that is agreed.]
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:ccp"
xmlns:tns="urn:ietf:params:xml:ns:ccp"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
<!-- CONF-CTL-REQUEST-TYPE element -->
<xs:element name="request" type="tns:conf-ctl-request-type"/>
<!-- CONF-CTL-RESPONSE-TYPE element-->
<xs:element name="response" type="tns:conf-ctl-response-type"/>
<!-- CONF-CTL-REQUEST-TYPE definition-->
<xs:complexType name="conf-ctl-request-type">
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="queryBlueprints"
type="tns:query-blueprints-type"/>
<xs:element name="getTemplate"
type="tns:get-template-type"/>
<xs:element name="createConf"
type="tns:create-conf-type"/
<xs:element name="queryConference"
type="tns:query-conference-type"/>
<xs:element name="manipulateConference"
type="tns:manipulate-conference-type"/>
<xs:element name="deleteConference"
type="tns:delete-conference-type"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="requestId"
type="xs:string" use="required"/>
<!-- The URI of the conference control client sending the request -->
<xs:attribute name="from" type="xs:anyURI" use="required"/>
<!--The URI of the conference control server the request is being sent to -->
<xs:attribute name="to" type="xs:anyURI" use="required"/>
</xs:complexType>
<!-- CONF-CTL-RESPONSE-TYPE definition -->
Barnes & Boulton Expires December 26, 2006 [Page 10]
Internet-Draft CCMP June 2006
<xs:complexType name="conf-ctl-response-type">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element name="queryBlueprintsResponse"
type="tns:query-blueprints-response-type"/>
<xs:element name="getTemplateResponse"
type="tns:get-template-response-type"/>
<xs:element name="createConfResponse"
type="tns:create-conf-response-type"/
<xs:element name="queryConferenceResponse"
type="tns:query-conference-response-type"/>
<xs:element name="manipulateConferenceResponse"
type="tns:manipulate-conference-type"/>
<xs:element name="deleteConferenceResponse"
type="tns:delete-conference-response-type"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="requestId"
type="xs:string" use="required"/>
<!--The URI of the conference control server that processed the original request and is sending the response -->
<xs:attribute name="from" type="xs:anyURI" use="required"/>
<!-- The URI of the conference control client that initiated the original request and is receiving the response -->
<xs:attribute name="to" type="xs:anyURI" use="required"/>
<xs:attribute name="responseCode"
type="tns:response-code-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--Yes, there's lots more to do here!!!! -->
</xs:schema>
Figure 2
10. WSDL Definition
The following provides the WSDL definition for conference control and
manipulation, using the the XML schema defined in Section 9 as a
basis.
Barnes & Boulton Expires December 26, 2006 [Page 11]
Internet-Draft CCMP June 2006
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="CCMP"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cccp="urn:ietf:params:xml:ns:ccp"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="urn:ietf:params:xml:ns:ccmp"
targetNamespace="urn:ietf:params:xml:ns:ccmp:proto">
<xs:import
namespace="urn:ietf:params:xml:ns:ccp"
schemaLocation="ccp.xsd"/>
<message name="CCMPRequestMessage">
<part name="body" element="ccp:request"/>
</message>
<message name="CCMPReponseMessage">
<part name="body" element="ccp:response"/>
</message>
<wsdl:portType name="CCMPPortType">
<wsdl:operation name="confOperation" parameterOrder="body">
<wsdl:input message="tns:CCMPRequestMessage"/>
<wsdl:output message="tns:CCMPResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ccpSoapBinding" type="tns:CCMPPortType">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="confOperation">
<wsdlsoap:operation soapAction=""/>
<wsdl:input>
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
use="encoded"/>
</wsdl:input>
<wsdl:output>
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
Barnes & Boulton Expires December 26, 2006 [Page 12]
Internet-Draft CCMP June 2006
<wsdl:service name="CCMP">
<wsdl:port binding="tns:ccpSoapBinding" name="CCMPPortType">
<wsdlsoap:address location="http://www.example.com"/>
</wsdl:port>
</wsdl:service>
</definitions>
Figure 3
11. Examples
TODO
12. IANA Considerations
TODO
13. Security Considerations
TODO
14. Acknowledgments
Henning Schulzrinne provided the initial impetus for this proposal.
He and Orit Levin provided useful input.
15. References
15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[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] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web
Services Description Language (WSDL) Version 2.0 Part 1: Core
Language", W3C CR CR-wsdl20-20051215, December 2005.
Barnes & Boulton Expires December 26, 2006 [Page 13]
Internet-Draft CCMP June 2006
[4] Nielsen, H., Gudgin, M., Mendelsohn, N., Hadley, M., and J.
Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", World
Wide Web Consortium Recommendation http://www.w3.org/TR/2003/
REC-soap12-part1-20030624, June 2003.
[5] Nielsen, H., Hadley, M., Moreau, J., Gudgin, M., and N.
Mendelsohn, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web
Consortium Recommendation http://www.w3.org/TR/2003/
REC-soap12-part2-20030624, June 2003.
15.2. Informative References
[6] Barnes, M., "A Framework and Data Model for Centralized
Conferencing", draft-ietf-xcon-framework-04 (work in progress),
June 2006.
[7] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress),
July 2005.
[8] Levin, O., "Centralized Conference Control Protocol",
draft-levin-xcon-cccp-04 (work in progress), January 2006.
[9] Novo, O., "A Common Conference Information Data Model for
Centralized Conferencing (XCON)",
draft-ietf-xcon-common-data-model-00 (work in progress),
April 2006.
[10] Schulzrinne, H., "COMP: Conference Object Manipulation
Protocol", draft-schulzrinne-xcon-comp-00 (work in progress),
January 2006.
Barnes & Boulton Expires December 26, 2006 [Page 14]
Internet-Draft CCMP June 2006
Authors' Addresses
Mary Barnes
Nortel
2380 Performance Drive
Richardson, TX
Email: mary.barnes@nortel.com
Chris Boulton
Ubiquity Software Corporation
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@ubiquitysoftware.com
Barnes & Boulton Expires December 26, 2006 [Page 15]
Internet-Draft CCMP June 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.
Barnes & Boulton Expires December 26, 2006 [Page 16]