draft-ietf-xcon-ccmp-08.txt   draft-ietf-xcon-ccmp-09.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track C. Boulton Intended status: Standards Track C. Boulton
Expires: December 20, 2010 NS-Technologies Expires: January 3, 2011 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
June 18, 2010 July 2, 2010
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-08 draft-ietf-xcon-ccmp-09
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) allows an The Centralized Conferencing Manipulation Protocol (CCMP) allows an
XCON conferencing system client to create, retrieve, change, and XCON conferencing system client to create, retrieve, change, and
delete objects that describe a centralized conference. CCMP is a delete objects that describe a centralized conference. CCMP is a
means to control basic and advanced conference features such as means to control basic and advanced conference features such as
conference state and capabilities, participants, relative roles, and conference state and capabilities, participants, relative roles, and
details. CCMP is a state-less, XML-based, client server protocol details. CCMP is a state-less, XML-based, client server protocol
that carries, in its request and response messages, conference that carries, in its request and response messages, conference
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2010. This Internet-Draft will expire on January 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. XCON Conference Control System Architecture . . . . . . . . . 5 3. XCON Conference Control System Architecture . . . . . . . . . 5
3.1. Conference Objects . . . . . . . . . . . . . . . . . . . . 7 3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7
3.2. Conference Users . . . . . . . . . . . . . . . . . . . . . 7 3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9
4.2. Implementation Approach . . . . . . . . . . . . . . . . . 11 4.2. Implementation Approach . . . . . . . . . . . . . . . . . 11
5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 12 5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12 5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12
5.2. CCMP Response Message Type . . . . . . . . . . . . . . . . 14 5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14
5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16
5.3.1. optionsRequest and optionsResponse . . . . . . . . . . 19 5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19
5.3.2. blueprintsRequest and blueprintsResponse . . . . . . . 21 5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21
5.3.3. confsRequest and confsResponse . . . . . . . . . . . . 23 5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22
5.3.4. blueprintRequest and blueprintResponse . . . . . . . . 25 5.3.4. confRequest and confResponse . . . . . . . . . . . . 24
5.3.5. confRequest and confResponse . . . . . . . . . . . . . 27 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28
5.3.6. usersRequest and usersResponse . . . . . . . . . . . . 31 5.3.6. userRequest and userResponse . . . . . . . . . . . . 30
5.3.7. userRequest and userResponse . . . . . . . . . . . . . 33 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35
5.3.8. sidebarsByValRequest and sidebarsByValResponse . . . . 37 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 36
5.3.9. sidebarByValRequest and sidebarByValResponse . . . . . 39 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39
5.3.10. sidebarsByRefRequest and sidebarsByRefResponse . . . . 42 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41
5.3.11. sidebarByRefRequest and sidebarByRefResponse . . . . . 43 5.3.11. extendedRequest and extendedResponse . . . . . . . . 44
5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 46 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46
6. A complete example of the CCMP in action . . . . . . . . . . . 49 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49
6.1. Alice retrieves the available blueprints . . . . . . . . . 50 6. A complete example of the CCMP in action . . . . . . . . . . 52
6.1. Alice retrieves the available blueprints . . . . . . . . 53
6.2. Alice gets detailed information about a specific 6.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 52 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3. Alice creates a new conference through a cloning 6.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 54 operation . . . . . . . . . . . . . . . . . . . . . . . . 57
6.4. Alice updates conference information . . . . . . . . . . . 57 6.4. Alice updates conference information . . . . . . . . . . 60
6.5. Alice inserts a list of users in the conference object . . 59 6.5. Alice inserts a list of users in the conference object . 62
6.6. Alice joins the conference . . . . . . . . . . . . . . . . 60 6.6. Alice joins the conference . . . . . . . . . . . . . . . 63
6.7. Alice adds a new user to the conference . . . . . . . . . 62 6.7. Alice adds a new user to the conference . . . . . . . . . 65
7. Locating a Conference Control Server . . . . . . . . . . . . . 64 6.8. Alice asks for the CCMP server capabilities . . . . . . . 67
8. Managing Notifications . . . . . . . . . . . . . . . . . . . . 66 6.9. Alice exploits a CCMP server extension . . . . . . . . . 70
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 67 7. Locating a Conference Control Server . . . . . . . . . . . . 73
10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 77
10.1. Assuring that the Proper Conferencing Server has been 10.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 69 contacted . . . . . . . . . . . . . . . . . . . . . . . . 78
10.2. User Authentication and Authorization . . . . . . . . . . 70 10.2. User Authentication and Authorization . . . . . . . . . . 78
10.3. Security and Privacy of Identity . . . . . . . . . . . . . 71 10.3. Security and Privacy of Identity . . . . . . . . . . . . 79
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 72 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 88 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 89 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 98
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 89 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 90 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 99
12.4.1. Registration of a Conference Control Server 12.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 90 Application Service Tag . . . . . . . . . . . . . . . 100
12.4.2. Registration of a Conference Control Server 12.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 91 Application Protocol Tag for CCMP . . . . . . . . . . 100
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 91 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 100
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 91 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 100
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 92 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 103
14. Changes since last Version . . . . . . . . . . . . . . . . . . 94 14. Changes since last Version . . . . . . . . . . . . . . . . . 103
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 104
15.1. Normative References . . . . . . . . . . . . . . . . . . . 95 15.1. Normative References . . . . . . . . . . . . . . . . . . 104
15.2. Informative References . . . . . . . . . . . . . . . . . . 95 15.2. Informative References . . . . . . . . . . . . . . . . . 105
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . . 97 considered for CCMP . . . . . . . . . . . . . . . . 106
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 97 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 98 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 107
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108
1. Introduction 1. Introduction
The Framework for Centralized Conferencing [RFC5239] (XCON Framework) The Framework for Centralized Conferencing [RFC5239] (XCON Framework)
defines a signaling-agnostic framework, naming conventions and defines a signaling-agnostic framework, naming conventions and
logical entities required for building advanced conferencing systems. logical entities required for building advanced conferencing systems.
The XCON Framework introduces the conference object as a logical The XCON Framework introduces the conference object as a logical
representation of a conference instance, representing the current representation of a conference instance, representing the current
state and capabilities of a conference. state and capabilities of a conference.
skipping to change at page 8, line 8 skipping to change at page 8, line 8
participants are users, but some users may have only administrative participants are users, but some users may have only administrative
functions and do not contribute or receive media. Users are added functions and do not contribute or receive media. Users are added
one user at a time to simplify error reporting. When a conference is one user at a time to simplify error reporting. When a conference is
cloned from a parent object, users are inherited as well, so that it cloned from a parent object, users are inherited as well, so that it
is easy to set up a conference that has the same set of participants is easy to set up a conference that has the same set of participants
or a common administrator. The Conference Control Server creates or a common administrator. The Conference Control Server creates
individual users, assigning them a unique Conference User Identifier individual users, assigning them a unique Conference User Identifier
(XCON-USERID). The XCON-USERID as identifier of each conferencing (XCON-USERID). The XCON-USERID as identifier of each conferencing
system client is introduced in the XCON framework and defined in the system client is introduced in the XCON framework and defined in the
XCON common data model. Each CCMP request, with an exception pointed XCON common data model. Each CCMP request, with an exception pointed
out in Section 5.3.7 representing the case of a user at his first out in Section 5.3.6 representing the case of a user at his first
entrance in the system as a conference participant, must carry the entrance in the system as a conference participant, must carry the
XCON-USERID of the requestor in the proper "confUserID" parameter. XCON-USERID of the requestor in the proper "confUserID" parameter.
The XCON-USERID acts as a pointer to the user's profile as a The XCON-USERID acts as a pointer to the user's profile as a
conference actor, e.g. her signalling URI and other XCON protocol conference actor, e.g. her signalling URI and other XCON protocol
URIs in general, her role (moderator, participant, observer, etc.), URIs in general, her role (moderator, participant, observer, etc.),
her display text, her joining information and so on. A variety of her display text, her joining information and so on. A variety of
elements defined in the common <conference-info> element as specified elements defined in the common <conference-info> element as specified
in the XCON data model are used to describe the users related to a in the XCON data model are used to describe the users related to a
conference, in the first place the <users> element, as well as each conference, in the first place the <users> element, as well as each
skipping to change at page 13, line 5 skipping to change at page 13, line 5
confUserID: An optional parameter containing the XCON-USERID of the confUserID: An optional parameter containing the XCON-USERID of the
client. The XCON-USERID is used to identify any conferencing client. The XCON-USERID is used to identify any conferencing
client within the context of the conferencing system and it is client within the context of the conferencing system and it is
assinged by the conferencing server at each conferencing client assinged by the conferencing server at each conferencing client
who interacts with it. The "confUserID" parameter is REQUIRED in who interacts with it. The "confUserID" parameter is REQUIRED in
the CCMP request and response messages with the exception of the the CCMP request and response messages with the exception of the
case of a user who has no XCON-USERID and who wants to enter, via case of a user who has no XCON-USERID and who wants to enter, via
CCMP, a conference whose identifier is known. In such case, a CCMP, a conference whose identifier is known. In such case, a
side-effect of the request is that the user is provided with an side-effect of the request is that the user is provided with an
appropriate XCON-USERID. An example of the above mentioned case appropriate XCON-USERID. An example of the above mentioned case
will be provided in Section 5.3.7. will be provided in Section 5.3.6.
confObjID: An optional parameter containing the XCON-URI of the confObjID: An optional parameter containing the XCON-URI of the
target conference object. target conference object.
operation: An optional parameter refining the type of specialized operation: An optional parameter refining the type of specialized
request message. The "operation" parameter is REQUIRED in all request message. The "operation" parameter is REQUIRED in all
requests except for the "blueprintsRequest" and "confsRequest" requests except for the "blueprintsRequest" and "confsRequest"
specialized messages. specialized messages.
conference-password: An optional parameter that MUST be inserted in conference-password: An optional parameter that MUST be inserted in
all requests whose target conference object is password-protected all requests whose target conference object is password-protected
(as per the <conference-password> element in (as per the <conference-password> element in
[I-D.ietf-xcon-common-data-model]). [I-D.ietf-xcon-common-data-model]).
skipping to change at page 16, line 49 skipping to change at page 16, line 49
</xs:complexType> </xs:complexType>
Figure 3: Structure of CCMP Response message Figure 3: Structure of CCMP Response message
5.3. Detailed messages 5.3. Detailed messages
Based on the request and response message structures described in Based on the request and response message structures described in
Section 5.1 and Section 5.2, the following summarizes the specialized Section 5.1 and Section 5.2, the following summarizes the specialized
CCMP request/response types described in this document: CCMP request/response types described in this document:
1. optionsRequest/optionsResponse 1. blueprintsRequest/blueprintsResponse
2. blueprintsRequest/blueprintsResponse 2. confsRequest/confsResponse
3. confsRequest/confsResponse 3. blueprintRequest/blueprintResponse
4. blueprintRequest/blueprintResponse 4. confRequest/confResponse
5. confRequest/confResponse 5. usersRequest/usersResponse
6. usersRequest/usersResponse 6. userRequest/userResponse
7. userRequest/userResponse 7. sidebarsByValRequest/sidebarsByValResponse
8. sidebarsByValRequest/sidebarsByValResponse 8. sidebarsByRefRequest/sidebarsByRefResponse
9. sidebarsByRefRequest/sidebarsByRefResponse 9. sidebarByValRequest/sidebarByValResponse
10. sidebarByValRequest/sidebarByValResponse 10. sidebarByRefRequest/sidebarByRefResponse
11. sidebarByRefRequest/sidebarByRefResponse 11. extendedRequest/extendedResponse
12. optionsRequest/optionsResponse
These CCMP request/response pairs use the fundamental CCMP operations These CCMP request/response pairs use the fundamental CCMP operations
as defined in Section 4.1 to manipulate the conference data. The as defined in Section 4.1 to manipulate the conference data. The
optionsRequest/optionsResponse message pair deserves a specific optionsRequest/optionsResponse message pair deserves a specific
discussion, since it is not used for manipulating information about discussion, since it is not used for manipulating information about
either conferences or conference users, but rather to retrieve either conferences or conference users, but rather to retrieve
general information about conference server capabilities, in terms of general information about conference server capabilities, in terms of
standard CCMP messages it supports, plus potential extension messages standard CCMP messages it supports, plus potential extension messages
it understands, as it will be further explained in Section 5.3.1. it understands, as it will be further explained in Section 5.3.12.
Table 1 summarizes the remaining CCMP operations and corresponding Table 1 summarizes the remaining CCMP operations and corresponding
actions that are valid for a specific CCMP request type, noting that actions that are valid for a specific CCMP request type, noting that
neither the blueprintsRequest/blueprintsResponse nor confsRequest/ neither the blueprintsRequest/blueprintsResponse nor confsRequest/
confsResponse require an "operation" parameter. The corresponding confsResponse require an "operation" parameter. The corresponding
response MUST contain the same operation. Note that some entries are response MUST contain the same operation. Note that some entries are
labeled "N/A" indicating the operation is invalid for that request labeled "N/A" indicating the operation is invalid for that request
type. In the case of an "N/A*", the operation MAY be allowed for type. In the case of an "N/A*", the operation MAY be allowed for
specific privileged users or system administrators, but is not part specific privileged users or system administrators, but is not part
of the functionality included in this document. of the functionality included in this document.
skipping to change at page 19, line 16 skipping to change at page 19, line 16
Thus, "update" and "retrieve" are the only semantically correct Thus, "update" and "retrieve" are the only semantically correct
operations for such message. operations for such message.
(***): This operation can involve the creation of an XCON-USERID, if (***): This operation can involve the creation of an XCON-USERID, if
the sender does not add it in the "confUserID" parameter, and/or if the sender does not add it in the "confUserID" parameter, and/or if
the "entity" field of the "userInfo" parameter is void. the "entity" field of the "userInfo" parameter is void.
Additional parameters included in the specialized CCMP request/ Additional parameters included in the specialized CCMP request/
response messages are detailed in the subsequent sections. response messages are detailed in the subsequent sections.
5.3.1. optionsRequest and optionsResponse 5.3.1. blueprintsRequest and blueprintsResponse
An "optionsRequest" (Figure 4) message is basic CCMP message, i.e. it
does not provide any specialization of the general CCMP request.
Coming to the response, it can contain information about both
standard (i.e. IETF-defined) CCMP messages and extension messages
supported by the server. In both cases, the response carries back a
list of names of the supported (standard and extended) messages.
Since all CCMP messages can potentially contain XML elements not
envisioned in the CCMP schema (due to the presence of <any> elements
and attributes), a reference to a proper schema definition specifying
such new elements/attributes can also be sent back to the clients (in
the <schema-ref> element).
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="optionsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="optionsResponse"
type="optionsResponseType" />
<xs:complexType name="optionsResponseType">
<xs:sequence>
<xs:element name="options"
type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="options-type">
<xs:sequence>
<xs:element name="standard-message-list" type="standard-message-list-type"
minOccurs="1"/>
<xs:element name="extended-message-list" type="extended-message-list-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="standard-message-list-type">
<xs:sequence>
<xs:element name="standard-message" type="standard-message-type" minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="standard-message-type">
<xs:sequence>
<xs:element name="name" type="standard-message-name-type" minOccurs="1"/>
<xs:element name="schema-def" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="extended-message-list-type">
<xs:sequence>
<xs:element name="extended-message" type="extended-message-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="extended-message-type">
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="schema-def" type="xs:string" />
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- options -->
Figure 4: Structure of the optionsRequest and optionsResponse
messages
5.3.2. blueprintsRequest and blueprintsResponse
A "blueprintsRequest" (Figure 5) message is sent to request the list A "blueprintsRequest" (Figure 4) message is sent to request the list
of XCON-URIs associated with the available blueprints from the of XCON-URIs associated with the available blueprints from the
conference server. Such URIs can be subsequently used by the client conference server. Such URIs can be subsequently used by the client
to access detailed information about a specified blueprint with a to access detailed information about a specified blueprint with a
specific blueprintRequest message per Section 5.3.4. The specific blueprintRequest message per Section 5.3.3. The
"confUserID" parameter MUST be included in every blueprintsRequest/ "confUserID" parameter MUST be included in every blueprintsRequest/
Response message and reflect the XCON-USERID of the conferencing Response message and reflect the XCON-USERID of the conferencing
client issuing the request. A blueprintsRequest message REQUIRES no client issuing the request. A blueprintsRequest message REQUIRES no
"confObjID" and "operation" parameters, since it is not targetted to "confObjID" and "operation" parameters, since it is not targetted to
a specific conference instance and it is conceived as a "retrieve- a specific conference instance and it is conceived as a "retrieve-
only" request. In order to obtain a specific subset of the available only" request. In order to obtain a specific subset of the available
blueprints, a client may specify a selection filter providing an blueprints, a client may specify a selection filter providing an
appropriate xpath query in the optional "xpathFilter" parameter of appropriate xpath query in the optional "xpathFilter" parameter of
the request. For example, to select blueprints having both audio and the request. For example, to select blueprints having both audio and
video stream support, a possible xpathFilter value could be: "/ video stream support, a possible xpathFilter value could be: "/
conference-info[conference-description/available-media/entry/ conference-info[conference-description/available-media/entry/
type='audio' and conference-description/available-media/entry/ type='audio' and conference-description/available-media/entry/
type='video']". type='video']".
The associated "blueprintsResponse" message SHOULD contain, as shown The associated "blueprintsResponse" message SHOULD contain, as shown
in Figure 5, a "blueprintsInfo" parameter containing the above in Figure 4, a "blueprintsInfo" parameter containing the above
mentioned XCON-URI list. mentioned XCON-URI list.
<!-- blueprintsRequest --> <!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type"> <xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintsRequest" /> <xs:element ref="blueprintsRequest" />
</xs:sequence> </xs:sequence>
skipping to change at page 23, line 22 skipping to change at page 20, line 47
<xs:complexType name="blueprintsResponseType"> <xs:complexType name="blueprintsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintsInfo" <xs:element name="blueprintsInfo"
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 5: Structure of the blueprintsRequest and blueprintsResponse Figure 4: Structure of the blueprintsRequest and blueprintsResponse
messages messages
5.3.3. confsRequest and confsResponse 5.3.2. confsRequest and confsResponse
A "confsRequest" message is used to retrieve, from the server, the A "confsRequest" message is used to retrieve, from the server, the
list of XCON-URIs associated with active and registered conferences list of XCON-URIs associated with active and registered conferences
currently handled by the conferencing system. The "confUserID" currently handled by the conferencing system. The "confUserID"
parameter MUST be included in every confsRequest/Response message and parameter MUST be included in every confsRequest/Response message and
reflect the XCON-USERID of the conferencing client issuing the reflect the XCON-USERID of the conferencing client issuing the
request. The "confObjID" parameter MUST NOT be included in the request. The "confObjID" parameter MUST NOT be included in the
confsRequest message. The "confsRequest" message is of a "retrieve- confsRequest message. The "confsRequest" message is of a "retrieve-
only" type, since the sole purpose is to collect information only" type, since the sole purpose is to collect information
available at the conference server. Thus, an "operation" parameter available at the conference server. Thus, an "operation" parameter
skipping to change at page 25, line 4 skipping to change at page 22, line 29
<xs:complexType name="confsResponseType"> <xs:complexType name="confsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confsInfo" type="info:uris-type" <xs:element name="confsInfo" type="info:uris-type"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 6: Structure of the confsRequest and confsResponse messages
5.3.4. blueprintRequest and blueprintResponse Figure 5: Structure of the confsRequest and confsResponse messages
5.3.3. blueprintRequest and blueprintResponse
Through a "blueprintRequest", a client can manipulate the conference Through a "blueprintRequest", a client can manipulate the conference
object associated with a specified blueprint. Further than the object associated with a specified blueprint. Further than the
"confUserID" parameter, the request MUST include the "confObjID" and "confUserID" parameter, the request MUST include the "confObjID" and
the "operation" one. Again, the "confUserID" parameter MUST be the "operation" one. Again, the "confUserID" parameter MUST be
included in every blueprintRequest/Response message and reflect the included in every blueprintRequest/Response message and reflect the
XCON-USERID of the conferencing client issuing the request. The XCON-USERID of the conferencing client issuing the request. The
"confObjID" parameter MUST contain the XCON-URI of the blueprint, "confObjID" parameter MUST contain the XCON-URI of the blueprint,
which might have been previously retrieved through a which might have been previously retrieved through a
"blueprintsRequest" message. "blueprintsRequest" message.
skipping to change at page 26, line 47 skipping to change at page 24, line 25
<xs:complexType name="blueprintResponseType"> <xs:complexType name="blueprintResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type" <xs:element name="blueprintInfo" type="info:conference-type"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"> minOccurs="0" maxOccurs="unbounded">
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 7: Structure of the blueprintRequest and blueprintResponse Figure 6: Structure of the blueprintRequest and blueprintResponse
messages messages
5.3.5. confRequest and confResponse 5.3.4. confRequest and confResponse
With a "confRequest" message, CCMP clients can manipulate conference With a "confRequest" message, CCMP clients can manipulate conference
objects associated with either active or registered conferences. The objects associated with either active or registered conferences. The
"confUserID" parameter MUST be included in every confRequest/Response "confUserID" parameter MUST be included in every confRequest/Response
message and reflect the XCON-USERID of the conferencing client message and reflect the XCON-USERID of the conferencing client
issuing the request. ConfRequest and confResponse messages MUST also issuing the request. ConfRequest and confResponse messages MUST also
include an "operation" parameter. ConfResponse messages MUST return include an "operation" parameter. ConfResponse messages MUST return
to the requestor a "response-code" and MAY contain a "response- to the requestor a "response-code" and MAY contain a "response-
string" explaining it. Depending upon the type of "operation", a string" explaining it. Depending upon the type of "operation", a
"confObjID" and "confInfo" parameter MAY be included in the "confObjID" and "confInfo" parameter MAY be included in the
skipping to change at page 28, line 24 skipping to change at page 26, line 4
model, it does not represent the entire updated version of the target model, it does not represent the entire updated version of the target
conference, since it rather conveys just the modifications to apply conference, since it rather conveys just the modifications to apply
to that conference. For example, in order to change the conference to that conference. For example, in order to change the conference
title, the confInfo parameter will be of the form: title, the confInfo parameter will be of the form:
<confInfo entity="xcon:8977777@example.com"> <confInfo entity="xcon:8977777@example.com">
<conference-description> <conference-description>
<display-text> *** NEW CONFERENCE TITLE *** </display-text> <display-text> *** NEW CONFERENCE TITLE *** </display-text>
</conference-description> </conference-description>
</confInfo> </confInfo>
Figure 7: Updating a conference object: modifying the title of a
Figure 8: Updating a conference object: modifying the title of a
conference conference
Similarly, to remove the title of an existing conference, a Similarly, to remove the title of an existing conference, a
confRequest/update carrying the following "confInfo" parameter would confRequest/update carrying the following "confInfo" parameter would
do the job.: do the job.:
<confInfo entity="xcon:8977777@example.com"> <confInfo entity="xcon:8977777@example.com">
<conference-description> <conference-description>
<display-text/> <display-text/>
</conference-description> </conference-description>
</confInfo> </confInfo>
Figure 9: Updating a conference object: removing the title of a Figure 8: Updating a conference object: removing the title of a
conference conference
In the case of a confResponse/update with a response-code of "200", In the case of a confResponse/update with a response-code of "200",
no additional information is required in the response message, which no additional information is required in the response message, which
means the return of confInfo parameter is not mandatory. A following means the return of confInfo parameter is not mandatory. A following
confRequest/retrieve transaction might provide the CCMP client with confRequest/retrieve transaction might provide the CCMP client with
the current aspect of the conference upon the modification, or the the current aspect of the conference upon the modification, or the
Notification Protocol might address that task as well. A "200" Notification Protocol might address that task as well. A "200"
response-code indicates that the referenced conference document has response-code indicates that the referenced conference document has
been changed accordingly to the request by the conferencing server. been changed accordingly to the request by the conferencing server.
skipping to change at page 29, line 44 skipping to change at page 27, line 21
A confRequest with an "operation" of "retrieve", "update" or "delete" A confRequest with an "operation" of "retrieve", "update" or "delete"
carrying a "confObjID" which is not associated with one of the carrying a "confObjID" which is not associated with one of the
conferences (active or registered) the system is holding will conferences (active or registered) the system is holding will
generate, on the server's side, a confResponse message containing a generate, on the server's side, a confResponse message containing a
"404" error code. This holds also for the case in which the "404" error code. This holds also for the case in which the
mentioned "confObjID" is related to an existing conference object mentioned "confObjID" is related to an existing conference object
stored at the server, but associated with a blueprint or with a stored at the server, but associated with a blueprint or with a
sidebar rather than an actual conference. sidebar rather than an actual conference.
The schema for the confRequest/confResponse pair is shown in The schema for the confRequest/confResponse pair is shown in
Figure 10. Figure 9.
<!-- confRequest --> <!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type"> <xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confRequest" /> <xs:element ref="confRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
skipping to change at page 31, line 4 skipping to change at page 28, line 27
<xs:complexType name="confResponseType"> <xs:complexType name="confResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" type="info:conference-type" <xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 10: Structure of the confRequest and confResponse messages
5.3.6. usersRequest and usersResponse Figure 9: Structure of the confRequest and confResponse messages
5.3.5. usersRequest and usersResponse
Through a "usersRequest" message the CCMP client manipulates the XML Through a "usersRequest" message the CCMP client manipulates the XML
<users> element of the conference document associated with the <users> element of the conference document associated with the
conference identified by the "confObjID" parameter complusory conference identified by the "confObjID" parameter complusory
included in the request. Inside the <users> element, along with the included in the request. Inside the <users> element, along with the
list of <user> elements associated with conference participants, list of <user> elements associated with conference participants,
there is information that the client may be interested in there is information that the client may be interested in
controlling, such the list of the users to which access to the controlling, such the list of the users to which access to the
conference is allowed/denied, conference participation policies, conference is allowed/denied, conference participation policies,
etc.; for this reason, a customized message has been designed to etc.; for this reason, a customized message has been designed to
skipping to change at page 33, line 4 skipping to change at page 30, line 31
<xs:element name="usersResponse" type="usersResponseType" /> <xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType"> <xs:complexType name="usersResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="usersInfo" type="info:users-type" <xs:element name="usersInfo" type="info:users-type"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 11: Structure of the usersRequest and usersResponse messages Figure 10: Structure of the usersRequest and usersResponse messages
5.3.7. userRequest and userResponse 5.3.6. userRequest and userResponse
A "userRequest" message is used to manipulate <user> elements inside A "userRequest" message is used to manipulate <user> elements inside
a conference document associated with a conference identified by the a conference document associated with a conference identified by the
"confObjID" parameter. Besides retrieving information about a "confObjID" parameter. Besides retrieving information about a
specific conference user, the message is used to request that the specific conference user, the message is used to request that the
conference server either create, modify, or delete information about conference server either create, modify, or delete information about
a user. A "userRequest" message MUST include the "confObjID", the a user. A "userRequest" message MUST include the "confObjID", the
"operation" parameter, and MAY include a "userInfo" parameter "operation" parameter, and MAY include a "userInfo" parameter
containing the detailed user's information depending upon the containing the detailed user's information depending upon the
operation and whether the "userInfo" has already been populated for a operation and whether the "userInfo" has already been populated for a
skipping to change at page 34, line 41 skipping to change at page 32, line 24
... ...
Response fields (in case of success): Response fields (in case of success):
confUserID=user345; confUserID=user345;
confObjID=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
response-code=200; response-code=200;
userInfo=null; //or the entire userInfo object userInfo=null; //or the entire userInfo object
Figure 12: userRequest and userResponse in the absence of an xcon- Figure 11: userRequest and userResponse in the absence of an xcon-
userid userid
o Conferencing client is unaware of the XCON-USERID of a third user: o Conferencing client is unaware of the XCON-USERID of a third user:
In this case, the XCON-USERID in the request "confUserID" is the In this case, the XCON-USERID in the request "confUserID" is the
sender's one and the "entity" attribute of the attached userInfo sender's one and the "entity" attribute of the attached userInfo
is filled with the pre-defined fake value is filled with the pre-defined fake value
"xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the
third user MUST be returned to the client issuing the request in third user MUST be returned to the client issuing the request in
the "entity" attribute of the response "userInfo" parameter, if the "entity" attribute of the response "userInfo" parameter, if
the "response-code" is "200". [RP] This scenario is intended to the "response-code" is "200". [RP] This scenario is intended to
skipping to change at page 37, line 26 skipping to change at page 35, line 4
<xs:element name="userResponse" type="userResponseType" /> <xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userResponseType"> <xs:complexType name="userResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="userInfo" type="info:user-type <xs:element name="userInfo" type="info:user-type
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 13: Structure of the userRequest and userResponse messages Figure 12: Structure of the userRequest and userResponse messages
5.3.8. sidebarsByValRequest and sidebarsByValResponse 5.3.7. sidebarsByValRequest and sidebarsByValResponse
A "sidebarsByValRequest" is used to execute a retrieve-only operation A "sidebarsByValRequest" is used to execute a retrieve-only operation
on the <sidebars-by-val> field of the conference object represented on the <sidebars-by-val> field of the conference object represented
by the "confObjID". The "sidebarsByValRequest" message is of a by the "confObjID". The "sidebarsByValRequest" message is of a
"retrieve-only" type, so an "operation" parameter MUST NOT be "retrieve-only" type, so an "operation" parameter MUST NOT be
included in a "sidebarsByValRequest" message. As with blueprints and included in a "sidebarsByValRequest" message. As with blueprints and
conferences, also with sidebars, CCMP allows for the use of xpath conferences, also with sidebars, CCMP allows for the use of xpath
filters whenever a selected subset of the sidebars available at the filters whenever a selected subset of the sidebars available at the
server's side has to be retrieved by the client. This applies both server's side has to be retrieved by the client. This applies both
to sidebars by reference and to sidebars by value. A to sidebars by reference and to sidebars by value. A
"sidebarsByValResponse" with a "response-code" of "200" MUST contain "sidebarsByValResponse" with a "response-code" of "200" MUST contain
a "sidebarsByValInfo" parameter containing the desired <sidebars-by- a "sidebarsByValInfo" parameter containing the desired <sidebars-by-
val> element. A "sidebarsByValResponse" message MUST carry back to val> element. A "sidebarsByValResponse" message MUST carry back to
the client a "version" element related to the current version of the the client a "version" element related to the current version of the
main conference object (i.e. the one whose identifier is contained in main conference object (i.e. the one whose identifier is contained in
the "confObjId" field of the request) to which the sidebars in the "confObjId" field of the request) to which the sidebars in
question are associated. The "sidebarsByValInfo" parameter contains question are associated. The "sidebarsByValInfo" parameter contains
the list of the conference objects associated with the sidebars by the list of the conference objects associated with the sidebars by
value derived from the main conference. The retrieved sidebars can value derived from the main conference. The retrieved sidebars can
then be updated or deleted using the "sidebarByValRequest" message, then be updated or deleted using the "sidebarByValRequest" message,
which is described in Section 5.3.9. which is described in Section 5.3.8.
<!-- sidebarsByValRequest --> <!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type"> <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByValRequest"/> <xs:element ref="sidebarsByValRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
skipping to change at page 39, line 13 skipping to change at page 36, line 38
<xs:complexType name="sidebarsByValResponseType"> <xs:complexType name="sidebarsByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByValInfo" <xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/> type="info:sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 14: Structure of the sidebarsByValRequest and Figure 13: Structure of the sidebarsByValRequest and
sidebarsByValResponse messages sidebarsByValResponse messages
5.3.9. sidebarByValRequest and sidebarByValResponse 5.3.8. sidebarByValRequest and sidebarByValResponse
A sidebarByValRequest message MUST contain the "operation" parameter A sidebarByValRequest message MUST contain the "operation" parameter
which discriminates among retrieval, creation, modification and which discriminates among retrieval, creation, modification and
deletion of a specific sidebar. The other required parameters depend deletion of a specific sidebar. The other required parameters depend
upon the type of operation. upon the type of operation.
In the case of a "create" operation, the "confObjID" parameter MUST In the case of a "create" operation, the "confObjID" parameter MUST
be included in the sidebyValRequest message. In this case, the be included in the sidebyValRequest message. In this case, the
"confObjID" parameter contains the XCON-URI of the main conference in "confObjID" parameter contains the XCON-URI of the main conference in
which the sidebar has to be created. If no "sidebarByValInfo" which the sidebar has to be created. If no "sidebarByValInfo"
skipping to change at page 40, line 6 skipping to change at page 37, line 32
subscribed to the conference event package, and are authorized to subscribed to the conference event package, and are authorized to
receive the notifications, of the addition of the sidebar to the receive the notifications, of the addition of the sidebar to the
conference. conference.
In the case of a "sidebarByVal" request with an operation of In the case of a "sidebarByVal" request with an operation of
"retrieve", the URI for the conference object created for the sidebar "retrieve", the URI for the conference object created for the sidebar
(received in the response to a "create" operation or in a (received in the response to a "create" operation or in a
sidebarsByValResponse message) MUST be included in the "confObjID" sidebarsByValResponse message) MUST be included in the "confObjID"
parameter in the request. This "retrieve" operation is handled by parameter in the request. This "retrieve" operation is handled by
the conference server in the same manner as a "retrieve" operation the conference server in the same manner as a "retrieve" operation
included in a confRequest message as detailed in Section 5.3.5. included in a confRequest message as detailed in Section 5.3.4.
In the case of a "sidebarByVal" request with an operation of In the case of a "sidebarByVal" request with an operation of
"update", the "sidebarByValInfo" MUST also be included in the "update", the "sidebarByValInfo" MUST also be included in the
request. The "confObjID" parameter contained in the request message request. The "confObjID" parameter contained in the request message
identifies the specific sidebar instance to be updated. An "update" identifies the specific sidebar instance to be updated. An "update"
operation on the "sidebarByValInfo" is handled by the conference operation on the "sidebarByValInfo" is handled by the conference
server in the same manner as an "update" operation on the confInfo server in the same manner as an "update" operation on the confInfo
included in a confRequest message as detailed in Section 5.3.5. A included in a confRequest message as detailed in Section 5.3.4. A
"sidebarByValResponse" message MUST carry back to the client a "sidebarByValResponse" message MUST carry back to the client a
"version" element related to the current version of the sidebar whose "version" element related to the current version of the sidebar whose
identifier is contained in the "confObjId" field of the request. identifier is contained in the "confObjId" field of the request.
If an "operation" of "delete" is included in the sidebarByVal If an "operation" of "delete" is included in the sidebarByVal
request, the "sidebarByValInfo" parameter MUST NOT be included in the request, the "sidebarByValInfo" parameter MUST NOT be included in the
request. Any "sidebarByValInfo" included in the request MUST be request. Any "sidebarByValInfo" included in the request MUST be
ignored by the conference server. The URI for the conference object ignored by the conference server. The URI for the conference object
associated with the sidebar MUST be included in the "confObjID" associated with the sidebar MUST be included in the "confObjID"
parameter in the request. If the specific conferencing user as parameter in the request. If the specific conferencing user as
skipping to change at page 42, line 4 skipping to change at page 39, line 28
<xs:complexType name="sidebarByValResponseType"> <xs:complexType name="sidebarByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type minOccurs="0"/> type="info:conference-type minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 15: Structure of the sidebarByValRequest and
Figure 14: Structure of the sidebarByValRequest and
sidebarByValResponse messages sidebarByValResponse messages
5.3.10. sidebarsByRefRequest and sidebarsByRefResponse 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse
Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be
invoked to retrieve the <sidebars-by-ref> element of the conference invoked to retrieve the <sidebars-by-ref> element of the conference
object identified by the "confObjID" parameter. The object identified by the "confObjID" parameter. The
"sidebarsByRefRequest" message is of a "retrieve-only" type, so an "sidebarsByRefRequest" message is of a "retrieve-only" type, so an
"operation" parameter MUST NOT be included in a "operation" parameter MUST NOT be included in a
"sidebarsByRefRequest" message. In the case of a "response-code" of "sidebarsByRefRequest" message. In the case of a "response-code" of
"200", the "sidebarsByRefInfo" parameter, containing the <sidebars- "200", the "sidebarsByRefInfo" parameter, containing the <sidebars-
by-ref> element of the conference object, MUST be included in the by-ref> element of the conference object, MUST be included in the
response. The <sidebars-by-ref> element represents the set of URIs response. The <sidebars-by-ref> element represents the set of URIs
of the sidebars associated with the main conference, whose of the sidebars associated with the main conference, whose
description (in the form of a standard XCON conference document) is description (in the form of a standard XCON conference document) is
external to the main conference itself. Through the retrieved URIs, external to the main conference itself. Through the retrieved URIs,
it is then possible to access single sidebars using the it is then possible to access single sidebars using the
"sidebarByRef" request message, described in Section 5.3.11. A "sidebarByRef" request message, described in Section 5.3.10. A
"sidebarsByRefResponse" message MUST carry back to the client a "sidebarsByRefResponse" message MUST carry back to the client a
"version" element related to the current version of the main "version" element related to the current version of the main
conference object (i.e. the one whose identifier is contained in the conference object (i.e. the one whose identifier is contained in the
"confObjId" field of the request) to which the sidebars in question "confObjId" field of the request) to which the sidebars in question
are associated. are associated.
<!-- sidebarsByRefRequest --> <!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type"> <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent> <xs:complexContent>
skipping to change at page 43, line 36 skipping to change at page 41, line 15
<xs:complexType name="sidebarsByRefResponseType"> <xs:complexType name="sidebarsByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByRefInfo" <xs:element name="sidebarsByRefInfo"
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 16: Structure of the sidebarsByRefRequest and Figure 15: Structure of the sidebarsByRefRequest and
sidebarsByRefResponse messages sidebarsByRefResponse messages
5.3.11. sidebarByRefRequest and sidebarByRefResponse 5.3.10. sidebarByRefRequest and sidebarByRefResponse
A sidebarByRefRequest message MUST contain the "operation" parameter A sidebarByRefRequest message MUST contain the "operation" parameter
which discriminates among retrieval, creation, modification and which discriminates among retrieval, creation, modification and
deletion of a specific sidebar. The other required parameters depend deletion of a specific sidebar. The other required parameters depend
upon the type of operation. upon the type of operation.
In the case of a "create" operation, the "confObjID" parameter MUST In the case of a "create" operation, the "confObjID" parameter MUST
be included in the sidebyRefRequest message. In this case, the be included in the sidebyRefRequest message. In this case, the
"confObjID" parameter contains the XCON-URI of the main conference in "confObjID" parameter contains the XCON-URI of the main conference in
which the sidebar has to be created. If no "sidebarByRefInfo" which the sidebar has to be created. If no "sidebarByRefInfo"
skipping to change at page 44, line 29 skipping to change at page 42, line 6
that have subscribed to the conference event package, and are that have subscribed to the conference event package, and are
authorized to receive the notifications, of the addition of the authorized to receive the notifications, of the addition of the
sidebar to the conference. sidebar to the conference.
In the case of a "sidebarByRef" request with an operation of In the case of a "sidebarByRef" request with an operation of
"retrieve", the URI for the conference object created for the sidebar "retrieve", the URI for the conference object created for the sidebar
MUST be included in the "confObjID" parameter in the request. A MUST be included in the "confObjID" parameter in the request. A
"retrieve" operation on the "sidebarByRefInfo" is handled by the "retrieve" operation on the "sidebarByRefInfo" is handled by the
conference server in the same manner as a "retrieve" operation on the conference server in the same manner as a "retrieve" operation on the
confInfo included in a confRequest message as detailed in confInfo included in a confRequest message as detailed in
Section 5.3.5. Section 5.3.4.
In the case of a "sidebarByRef" request with an operation of In the case of a "sidebarByRef" request with an operation of
"update", the URI for the conference object created for the sidebar "update", the URI for the conference object created for the sidebar
MUST be included in the "confObjID" parameter in the request. The MUST be included in the "confObjID" parameter in the request. The
"sidebarByRefInfo" MUST also be included in the request in the case "sidebarByRefInfo" MUST also be included in the request in the case
of an "operation" of "update". An "update" operation on the of an "operation" of "update". An "update" operation on the
"sidebarByRefInfo" is handled by the conference server in the same "sidebarByRefInfo" is handled by the conference server in the same
manner as an "update" operation on the confInfo included in a manner as an "update" operation on the confInfo included in a
confRequest message as detailed in Section 5.3.5. A confRequest message as detailed in Section 5.3.4. A
"sidebarByRefResponse" message MUST carry back to the client a "sidebarByRefResponse" message MUST carry back to the client a
"version" element related to the current version of the sidebar whose "version" element related to the current version of the sidebar whose
identifier is contained in the "confObjId" field of the request. identifier is contained in the "confObjId" field of the request.
If an "operation" of "delete" is included in the sidebarByRef If an "operation" of "delete" is included in the sidebarByRef
request, the "sidebarByRefInfo" parameter MUST NOT be included in the request, the "sidebarByRefInfo" parameter MUST NOT be included in the
request. Any "sidebarByRefInfo" included in the request MUST be request. Any "sidebarByRefInfo" included in the request MUST be
ignored by the conference server. The URI for the conference object ignored by the conference server. The URI for the conference object
for the sidebar MUST be included in the "confObjID" parameter in the for the sidebar MUST be included in the "confObjID" parameter in the
request. If the specific conferencing user as reflected by the request. If the specific conferencing user as reflected by the
skipping to change at page 46, line 26 skipping to change at page 44, line 4
<xs:complexType name="sidebarByRefResponseType"> <xs:complexType name="sidebarByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 16: Structure of the sidebarByRefRequest and
Figure 17: Structure of the sidebarByRefRequest and
sidebarByRefResponse messages sidebarByRefResponse messages
5.3.11. extendedRequest and extendedResponse
In order to facilitate the possibility of specifying new request/
response pairs for conference control, CCMP makes available the
"extendedRequest" and "extendedResponse" messages. Such messages
constitute a CCMP skeleton in which implementors can transport the
information needed to realize conference control mechanisms not
explicitly envisioned in the CCMP specification; these mechanisms are
called, in this context, "extensions". Each extension is assumed to
be characterized by an appropriate name that MUST be carried in the
extendedRequest/extendedResponse pair in the provided <extensionName>
field. Extension-specific information can be transported in the form
of schema-defined XML elements inside the <any> element present in
both extendedRequest and extendedResponse.
The conferencing client SHOULD be able to be informed about the
extensions supported by a CCMP server and to recover the XML Schema
defining the related specific elements by means of an optionsRequest/
optionsResponse CCMP transaction (see Section 5.3.12).
The meaning of the common CCMP parameters inherited by the
extendedRequest and extendedResponse from the basic CCMP request and
response messages SHOULD be preserved and exploited appropriately
while defining an extension.
<!-- extendedRequest -->
<xs:complexType name="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="extendedRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedRequestType -->
<xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="extendedRequestType">
<xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- extendedResponse -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="extendedResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedResponseType -->
<xs:element name="extendedResponse" type="extendedResponseType"/>
<xs:complexType name="extendedResponseType">
<xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
Figure 17: Structure of the extendedRequest and extendedResponse
messages
5.3.12. optionsRequest and optionsResponse
An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e.
it does not represent a specialization of the general CCMP request.
It allows a CCMP client to become aware of CCMP server capabilities
in terms of CCMP supported messages.
Indeed, the "optionsResponse" returns, in the appropriate <options>
field, information about both standard (i.e. IETF-defined) CCMP
messages and extension messages the server is able to handle.
Supported messages are listed into two separate groups, namely
<standard-message-list> and <extended-message-list>. Such groups are
represented, respectively, by a <standard-message> entry (for
standard messages) and an <extended-message> entry (for extensions).
In both cases, for each message the following information is
provided:
o <name> (mandatory): in case of standard messages, it can be one of
the ten standard message names defined in this document (i.e.
"blueprintsRequest", "confsRequest", etc.). In case of
extensions, this element MUST carry the same value of the
<extension-name> inserted in the corresponding extendedRequest/
extendedResponse message pair
o <operations> (optional): this field is a list of <operation>
entries, each representing the CRUD operation supported by the
server for the message. If this optional element is absent, the
client SHOULD assume the server is able to handle the entire set
of CRUD operations or, in case of standard messages, all the
operations envisioned for that message in this document.
o <schema-ref> (optional): since all CCMP messages can potentially
contain XML elements not envisioned in the CCMP schema (due to the
presence of <any> elements and attributes), a reference to a
proper schema definition specifying such new elements/attributes
can also be sent back to the clients by means of such field. If
this element is absent, no new elements are introduced in the
messages further than those explicitly defined in the CCMP
specification.
o <description> (optional): human readable information about the
related message
The only parameter needed in the optionsRequest is the sender
confUserID, which is mirrored in the homologous parameter of the
corresponding optionsResponse.
The <standard-message-list> MUST appear in the optionsResponse and
MUST not be void, since a CCMP server MUST be able to handle at least
one of the standard messages in at least one of the envisioned
operations, i.e. the aforementioned list MUST carry at least one
<standard-message> containing at least one <operation> element.
<!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponse -->
<xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="optionsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponseType -->
<xs:element name="optionsResponse"
type="optionsResponseType" />
<xs:complexType name="optionsResponseType">
<xs:sequence>
<xs:element name="options"
type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- options-type -->
<xs:complexType name="options-type">
<xs:sequence>
<xs:element name="standard-message-list"
type="standard-message-list-type" minOccurs="1"/>
<xs:element name="extended-message-list"
type="extended-message-list-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-list-type -->
<xs:complexType name="standard-message-list-type">
<xs:sequence>
<xs:element name="standard-message" type="standard-message-type" minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-type -->
<xs:complexType name="standard-message-type">
<xs:sequence>
<xs:element name="name" type="standard-message-name-type" minOccurs="1"/>
<xs:element name="operations" type="operations-type" minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-name-type -->
<xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction>
</xs:simpleType>
<!-- operations-type -->
<xs:complexType name="operations-type">
<xs:sequence>
<xs:element name="operation" type="operation-type"
minOccurs="1" maxOccurs="4"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 18: Structure of the optionsRequest and optionsResponse
messages
5.4. CCMP Response Codes 5.4. CCMP Response Codes
All CCMP response messages MUST include a ""response-code"". The All CCMP response messages MUST include a ""response-code"". The
following summarizes the CCMP response codes: following summarizes the CCMP response codes:
200 Success: Successful completion of the requested operation. 200 Success: Successful completion of the requested operation.
400 Bad Request: Syntactically malformed request. 400 Bad Request: Syntactically malformed request.
401 Unauthorized: User not allowed to perform the required 401 Unauthorized: User not allowed to perform the required
operation. operation.
403 Forbidden: Operation not allowed (e.g., cancellation of a 403 Forbidden: Operation not allowed (e.g., cancellation of a
skipping to change at page 50, line 7 skipping to change at page 53, line 7
3. Alice decides to create a new conference by cloning the retrieved 3. Alice decides to create a new conference by cloning the retrieved
blueprint (Section 6.3); blueprint (Section 6.3);
4. Alice modifies information (e.g. XCON-URI, name, description) 4. Alice modifies information (e.g. XCON-URI, name, description)
associated with the newly created blueprint (Section 6.4); associated with the newly created blueprint (Section 6.4);
5. Alice specifies a list of users to be contacted when the 5. Alice specifies a list of users to be contacted when the
conference is activated (Section 6.5); conference is activated (Section 6.5);
6. Alice joins the conference (Section 6.6); 6. Alice joins the conference (Section 6.6);
7. Alice lets a new user, Ciccio, (whose "confUserID" is 7. Alice lets a new user, Ciccio, (whose "confUserID" is
"xcon-userid:Ciccio@example.com") join the conference "xcon-userid:Ciccio@example.com") join the conference
(Section 6.7). (Section 6.7).
8. Alice asks for the CCMP server capabilities (Section 6.8);
9. Alice exploits an extension of the CCMP server (Section 6.9).
Note, the examples do not include any details beyond the basic Note, the examples do not include any details beyond the basic
operation. operation.
In the following sections we deal with each of the above mentioned In the following sections we deal with each of the above mentioned
actions separately. actions separately.
6.1. Alice retrieves the available blueprints 6.1. Alice retrieves the available blueprints
This section illustrates the transaction associated with retrieval of This section illustrates the transaction associated with retrieval of
skipping to change at page 52, line 33 skipping to change at page 55, line 36
only one user can talk at the same time, only one user can talk at the same time,
and the requests for the AudioFloor MUST and the requests for the AudioFloor MUST
be accepted by a Chair. be accepted by a Chair.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
</blueprintsInfo> </blueprintsInfo>
</ccmp:blueprintsResponse> </ccmp:blueprintsResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 18: Getting blueprints from the server Figure 19: Getting blueprints from the server
6.2. Alice gets detailed information about a specific blueprint 6.2. Alice gets detailed information about a specific blueprint
This section illustrates the second transaction in the overall flow. This section illustrates the second transaction in the overall flow.
In this case, Alice, who now knows the XCON-URIs of the blueprints In this case, Alice, who now knows the XCON-URIs of the blueprints
available at the server, makes a drill-down query, in the form of a available at the server, makes a drill-down query, in the form of a
CCMP "blueprintRequest" message, to get detailed information about CCMP "blueprintRequest" message, to get detailed information about
one of them (the one called with XCON-URI one of them (the one called with XCON-URI
"xcon:AudioRoom@example.com"). The picture shows such transaction. "xcon:AudioRoom@example.com"). The picture shows such transaction.
Notice that the response contains, in the "blueprintInfo" parameter, Notice that the response contains, in the "blueprintInfo" parameter,
skipping to change at page 54, line 31 skipping to change at page 57, line 31
</xcon:floor-request-handling> </xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="audioLabel"></xcon:floor> <xcon:floor id="audioLabel"></xcon:floor>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</blueprintInfo> </blueprintInfo>
</ccmp:blueprintResponse> </ccmp:blueprintResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 19: Getting info about a specific blueprint Figure 20: Getting info about a specific blueprint
6.3. Alice creates a new conference through a cloning operation 6.3. Alice creates a new conference through a cloning operation
This section illustrates the third transaction in the overall flow. This section illustrates the third transaction in the overall flow.
Alice decides to create a new conference by cloning the blueprint Alice decides to create a new conference by cloning the blueprint
having XCON-URI "xcon:AudioRoom@example.com", for which she just having XCON-URI "xcon:AudioRoom@example.com", for which she just
retrieved detailed information through the "blueprintRequest" retrieved detailed information through the "blueprintRequest"
message. This is achieved by sending a "confRequest/create" message message. This is achieved by sending a "confRequest/create" message
having the blueprint's URI in the "confObjID" parameter. The picture having the blueprint's URI in the "confObjID" parameter. The picture
shows such transaction. Notice that the response contains, in the shows such transaction. Notice that the response contains, in the
skipping to change at page 56, line 30 skipping to change at page 59, line 30
New conference by Alice cloned from AudioRoom New conference by Alice cloned from AudioRoom
</info:display-text> </info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
xcon:8977794@example.com xcon:8977794@example.com
</info:uri> </info:uri>
<info:display-text> <info:display-text>
conference xcon-uri conference xcon-uri
</info:display-text> </info:display-text>
<xcon:conference-password>
8601
</xcon:conference-password>
</info:entry> </info:entry>
</info:conf-uris> </info:conf-uris>
<info:maximum-user-count>10</info:maximum-user-count> <info:maximum-user-count>10</info:maximum-user-count>
<info:available-media> <info:available-media>
<info:entry label="11"> <info:entry label="11">
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:users> <info:users>
skipping to change at page 57, line 4 skipping to change at page 59, line 49
<info:users> <info:users>
<xcon:join-handling>allow</xcon:join-handling> <xcon:join-handling>allow</xcon:join-handling>
</info:users> </info:users>
<xcon:floor-information> <xcon:floor-information>
<xcon:floor-request-handling> <xcon:floor-request-handling>
confirm</xcon:floor-request-handling> confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="11"/> <xcon:floor id="11"/>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</confInfo> </confInfo>
</ccmp:confResponse> </ccmp:confResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 20: Creating a new conference by cloning a blueprint Figure 21: Creating a new conference by cloning a blueprint
6.4. Alice updates conference information 6.4. Alice updates conference information
This section illustrates the fourth transaction in the overall flow. This section illustrates the fourth transaction in the overall flow.
Alice decides to modify some of the details associated with the Alice decides to modify some of the details associated with the
conference she just created. More precisely, she changes the conference she just created. More precisely, she changes the
<display-text> element under the <conference-description> element of <display-text> element under the <conference-description> element of
the document representing the conference. This is achieved through a the document representing the conference. This is achieved through a
"confRequest/update" message carrying the fragment of the conference "confRequest/update" message carrying the fragment of the conference
document to which the required changes have to be applied. As shown document to which the required changes have to be applied. As shown
skipping to change at page 59, line 4 skipping to change at page 61, line 47
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>200</ccmp:response-code> <ccmp:response-code>200</ccmp:response-code>
<ccmp:version>2</ccmp:version> <ccmp:version>2</ccmp:version>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 21: Updating conference information
Figure 22: Updating conference information
6.5. Alice inserts a list of users in the conference object 6.5. Alice inserts a list of users in the conference object
This section illustrates the fifth transaction in the overall flow. This section illustrates the fifth transaction in the overall flow.
Alice modifies the <allowed-users-list> under the <users> element in Alice modifies the <allowed-users-list> under the <users> element in
the document associated with the conference she created. To the the document associated with the conference she created. To the
purpose, she exploits the "usersRequest" message provided by the purpose, she exploits the "usersRequest" message provided by the
CCMP. The picture below shows the transaction. CCMP. The picture below shows the transaction.
Alice updates information about the list of users to whom access to Alice updates information about the list of users to whom access to
skipping to change at page 60, line 37 skipping to change at page 63, line 35
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>200</ccmp:response-code> <ccmp:response-code>200</ccmp:response-code>
<ccmp:version>3</ccmp:version> <ccmp:version>3</ccmp:version>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 22: Updating the list of allowed users for the conference Figure 23: Updating the list of allowed users for the conference
'xcon:8977794@example.com' 'xcon:8977794@example.com'
6.6. Alice joins the conference 6.6. Alice joins the conference
This section illustrates the sixth transaction in the overall flow. This section illustrates the sixth transaction in the overall flow.
Alice uses the CCMP to add herself to the newly created conference. Alice uses the CCMP to add herself to the newly created conference.
This is achieved through a "userRequest/create" message containing, This is achieved through a "userRequest/create" message containing,
in the "userInfo" parameter, a <user> element compliant with the XCON in the "userInfo" parameter, a <user> element compliant with the XCON
data model representation. Notice that such element includes data model representation. Notice that such element includes
information about the user's Address of Records, as well as her information about the user's Address of Records, as well as her
skipping to change at page 62, line 33 skipping to change at page 65, line 31
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>200</ccmp:response-code> <ccmp:response-code>200</ccmp:response-code>
<ccmp:version>4</ccmp:version> <ccmp:version>4</ccmp:version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 23: Alice joins the conference through the CCMP Figure 24: Alice joins the conference through the CCMP
6.7. Alice adds a new user to the conference 6.7. Alice adds a new user to the conference
This section illustrates the seventh and last transaction in the This section illustrates the seventh and last transaction in the
overall flow. Alice uses the CCMP to add a new conferencing system overall flow. Alice uses the CCMP to add a new conferencing system
user, Ciccio, to the conference. This "third-party" request is user, Ciccio, to the conference. This "third-party" request is
realized through a "userRequest/create" message containing, in the realized through a "userRequest/create" message containing, in the
"userInfo" parameter, a <user> element compliant with the XCON data "userInfo" parameter, a <user> element compliant with the XCON data
model representation. Notice that such element includes information model representation. Notice that such element includes information
about Ciccio's Address of Records, as well as his current end-point, about Ciccio's Address of Records, as well as his current end-point,
skipping to change at page 63, line 17 skipping to change at page 66, line 15
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP userRequest message | | CCMP userRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: CiccioUserInfo(with dummy "entity") | | - userInfo: CiccioUserInfo(with dummy "entity") |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP userResponse message | | CCMP optionsResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - response-code: 200 | | - response-code: 200 |
| - version: 5 | | - version: 5 |
| - userInfo: CiccioUserInfo | | - userInfo: CiccioUserInfo |
| (with actual "entity") | | (with actual "entity") |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
skipping to change at page 64, line 4 skipping to change at page 66, line 49
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE@example.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Ciccio@example.com mailto:Ciccio@example.com
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/> <info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. "third party" userResponse message form the server: 2. "third party" userResponse message from the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
skipping to change at page 64, line 42 skipping to change at page 67, line 40
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/> <info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo> </userInfo>
</ccmp:userResponse> </ccmp:userResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 24: Alice adds a new user to the conference through the CCMP Figure 25: Alice adds a new user to the conference through the CCMP
6.8. Alice asks for the CCMP server capabilities
This section illustrates how Alice can discover which standard CCMP
messages and what extensions are supported by the CCMP server she
interacts with through an optionsRequest/optionsResponse transaction.
To prepare the optionsRequest, Alice just puts her XCON-USERID in the
confUserID parameter. Looking at the <options> element in the
received optionsResponse, Alice infers the following server
capabilities as regards standard CCMP messages:
o the server doesn't support neither sidebarsByValRequest nor
sidebarByValRequest messages, since they do not appear in the
<standard-message-list>;
o the only implemented operation for the blueprintRequest message is
"retrieve", since no other <operation> entries are included in the
related <operations> field.
Besides, by analyzing the <extended-message-list>, Alice discovers
the server implements an extension named "confSummaryRequest"
allowing conferencing clients to recover via CCMP a brief description
of a specific conference; the XML elements involved in this extended
conference control transaction are available at the URL indicated in
the <schema-ref> element and the only operation envisioned for this
extension is "retrieve". To better understand how Alice can exploit
the "confSummaryRequest" extension via CCMP, see Section 6.9.
The picture below shows the optionsRequest/optionsResponse message
exchanging between Alice and the CCMP server.
CCMP Client CCMP Server
| |
| CCMP optionsRequest message |
| - confUserID: Alice |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - response-code: 200 |
| - options (list of both |
| standard and extended |
| supported messages) |
|<------------------------------------------------------|
| |
. .
. .
1. optionsRequest (Alice asks for CCMP server capabilities)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
</ccmpRequest>
</ccmp:ccmpRequest>
2. optionsResponse (the server returns the list of its conference
control capabilities)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:optionsResponse>
<options>
<standard-message-list>
<standard-message>
<name>blueprintsRequest</name>
</standard-message>
</standard-message>
<name>blueprintRequest</name>
<operations>
<operation>retrieve</operation>
</operations>
<standard-message>
</standard-message>
<name>confsRequest</name>
<standard-message>
<name>confRequest</name>
</standard-message>
<standard-message>
<name>usersRequest</name>
</standard-message>
<standard-message>
<name>userRequest</name>
</standard-message>
<standard-message>
<name>sidebarsByRefRequest</name>
</standard-message>
<standard-message>
<name>sidebarByRefRequest</name>
</standard-message>
</standard-message-list>
<extended-message-list>
<extended-message>
<name>confSummaryRequest</name>
<operations>
<operation>request</operation>
</operations>
<schema-ref>
http://example.com/ccmp-extension-schema.xsd
</schema-ref>
<description>
confSummaryRequest is intented
to allow the requestor to retrieve
a brief description
of the conference indicated in the
confObjID request parameter
</description>
</extended-message>
</extended-message-list>
</options>
</ccmp:optionsResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 26: Alice asks for the server control capabilities
6.9. Alice exploits a CCMP server extension
In this section, a very simple example of CCMP extension support is
provided. Alice can recover information about this and other server-
supported extensions by issuing an optionsRequest (see Section 6.8).
The extension in question is named "confSummaryRequest" and is
conceived to allow a CCMP client to obtain from the CCMP server
synthetic information about a specific conference. The conference
summary is carried in the form of an XML element, <confSummary>,
defined by the following XML schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="confSummary" type="conf-summary-type"/>
<xs:complexType name="conf-summary-type">
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="status" type="xs:string"/>
<xs:element name="public" type="xs:boolean"/>
<xs:element name="media" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema
Figure 27: Example of XML Schema defining an extension parameter
(ccmp-extension-schema.xsd)
As it can be inferred from the schema file, the <confSummary> element
contains conference information related to:
o title
o status (active or registered)
o participation modality (if everyone is allowed to participate, the
boolean <public> element is set to "true")
o involved media
In order to retrieve a conference summary related to the conference
she participates in, Alice then sends to the CCMP server an
extendedRequest with a "confSummaryRequest" <extensionName>,
specifying the conference xcon-uri in the confObjID request
parameter, as depicted in the figure below.
CCMP Client CCMP Server
| |
| CCMP extendedRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: retrieve |
| - extensionName: confSummaryRequest |
|------------------------------------------------------>|
| |
| CCMP extendedResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: retrieve |
| - response-code: 200 |
| - extensionName: |
| confSummaryRequest |
| - confSummary |
|<------------------------------------------------------|
| |
. .
. .
1. extendedRequest (Alice makes use of the "confSummaryRequest")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:example="http://example.com/ccmp-extension-schema.xsd">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-extended-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:extendedRequest>
<extensionName>confRequestSummary</extensionName>
</ccmp:extendedRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. extendedResponse (the server provides Alice with a brief description
of the desired conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:example="http://example.com/ccmp-extension-schema.xsd">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-extended-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:extendedResponse>
<extensionName>confSummaryRequest</extensionName>
<example:confSummary>
<title> Alice's conference </title>
<status> active </status>
<public> true </public>
<media> audio </media>
</example:confSummary>
</ccmp:extendedResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 28: Alice exploits the 'confSummaryRequest' extension
7. Locating a Conference Control Server 7. Locating a Conference Control Server
If a conference control client is not pre-configured to use a If a conference control client is not pre-configured to use a
specific conference control server for the requests, the client MUST specific conference control server for the requests, the client MUST
first discover the conference control server before it can send any first discover the conference control server before it can send any
requests. The result of the discovery process, is the address of the requests. The result of the discovery process, is the address of the
server supporting conferencing. In this document, the result is an server supporting conferencing. In this document, the result is an
http: or https: URI, which identifies a conference server. http: or https: URI, which identifies a conference server.
skipping to change at page 65, line 21 skipping to change at page 73, line 39
This process also requires an Application Service tag and an This process also requires an Application Service tag and an
Application Protocol tag, which differentiate conferencing-related Application Protocol tag, which differentiate conferencing-related
NAPTR records from other records for that domain. NAPTR records from other records for that domain.
Section 12.4.1 defines an Application Service tag of "XCON", which is Section 12.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in particular domain. The Application Protocol tag "CCMP", defined in
Section 12.4.2, is used to identify an XCON server that understands Section 12.4.2, is used to identify an XCON server that understands
the CCMP protocol. the CCMP protocol.
The NAPTR records in the following example Figure 25 demonstrate the The NAPTR records in the following example Figure 29 demonstrate the
use of the Application Service and Protocol tags. Iterative NAPTR use of the Application Service and Protocol tags. Iterative NAPTR
resolution is used to delegate responsibility for the conferencing resolution is used to delegate responsibility for the conferencing
service from "zonea.example.com." and "zoneb.example.com." to service from "zonea.example.com." and "zoneb.example.com." to
"outsource.example.com.". "outsource.example.com.".
zonea.example.com. zonea.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "" "XCON:CCMP" ( ; service IN NAPTR 100 10 "" "XCON:CCMP" ( ; service
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
skipping to change at page 65, line 46 skipping to change at page 74, line 24
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
) )
outsource.example.com. outsource.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service
"!*.!https://confs.example.com/!" ; regex "!*.!https://confs.example.com/!" ; regex
. ; replacement . ; replacement
) )
Figure 25: Sample XCON:CCMP Service NAPTR Records Figure 29: Sample XCON:CCMP Service NAPTR Records
Details for the "XCON" Application Service tag and the "CCMP" Details for the "XCON" Application Service tag and the "CCMP"
Application Protocol tag are included in Section 12.4. Application Protocol tag are included in Section 12.4.
8. Managing Notifications 8. Managing Notifications
As per [RFC5239], the CCMP is one of the following four protocols As per [RFC5239], the CCMP is one of the following four protocols
which have been formally identified within the XCON framework: which have been formally identified within the XCON framework:
Conference Control Protocol: between Conference and Media Control Conference Control Protocol: between Conference and Media Control
Client and Conference Server. Such protocol is the subject of the Client and Conference Server. Such protocol is the subject of the
skipping to change at page 72, line 14 skipping to change at page 80, line 37
the user is provided the appropriate level of privacy. If the the user is provided the appropriate level of privacy. If the
"provide-anonymity" element is not included in the conference object, "provide-anonymity" element is not included in the conference object,
then other users can see the participant's identity. then other users can see the participant's identity.
11. XML Schema 11. XML Schema
This section provides the XML schema definition of the "application/ This section provides the XML schema definition of the "application/
ccmp+xml" format. ccmp+xml" format.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
schemaLocation="DataModel.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="rfc4575.xsd"/>
<xs:element name="ccmpRequest" type="ccmp-request-type" />
<xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- CCMP request definition -->
<xs:complexType name="ccmp-request-type">
<xs:sequence>
<xs:element name="ccmpRequest"
type="ccmp-request-message-type" />
</xs:sequence>
</xs:complexType>
<!-- CCMP response definition -->
<xs:complexType name="ccmp-response-type">
<xs:sequence>
<xs:element name="ccmpResponse"
type="ccmp-response-message-type" />
</xs:sequence>
</xs:complexType>
<!-- Definition of ccmp-request-message-type -->
<xs:complexType abstract="true"
name="ccmp-request-message-type">
<xs:sequence>
<xs:element name="subject" type="subject-type"
minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="conference-password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
<xs:complexType name="blueprintsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType">
<xs:sequence>
<xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsRequestType --> <xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="confsRequest" type="confsRequestType" /> <xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
schemaLocation="DataModel.xsd"/>
<xs:complexType name="confsRequestType"> <xs:import namespace="urn:ietf:params:xml:ns:conference-info"
<xs:sequence> schemaLocation="rfc4575.xsd"/>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> <xs:element name="ccmpRequest" type="ccmp-request-type" />
<xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- confRequest --> <!-- CCMP request definition -->
<xs:complexType name="ccmp-conf-request-message-type"> <xs:complexType name="ccmp-request-type">
<xs:complexContent> <xs:sequence>
<xs:extension base="tns:ccmp-request-message-type"> <xs:element name="ccmpRequest"
<xs:sequence> type="ccmp-request-message-type" />
<xs:element ref="confRequest" /> </xs:sequence>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confRequestType --> <!-- ccmp-request-message-type -->
<xs:element name="confRequest" type="confRequestType" />
<xs:complexType name="confRequestType">
<xs:sequence>
<xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="usersRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersRequestType">
<xs:sequence>
<xs:element name="usersInfo" type="info:users-type"
minOccurs="0" />
<xs:complexType abstract="true"
name="ccmp-request-message-type">
<xs:sequence>
<xs:element name="subject" type="subject-type"
minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="conference-password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- userRequest --> <!-- CCMP response definition -->
<xs:complexType name="ccmp-user-request-message-type"> <xs:complexType name="ccmp-response-type">
<xs:complexContent> <xs:sequence>
<xs:extension base="tns:ccmp-request-message-type"> <xs:element name="ccmpResponse"
<xs:sequence> type="ccmp-response-message-type" />
<xs:element ref="userRequest" /> </xs:sequence>
</xs:sequence> </xs:complexType>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userRequestType --> <!-- ccmp-response-message-type -->
<xs:element name="userRequest" type="userRequestType" /> <xs:complexType abstract="true" name="ccmp-response-message-type">
<xs:sequence>
<xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType" minOccurs="0"
maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1"
maxOccurs="1" />
<xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger"
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="userRequestType"> <!-- CCMP REQUESTS -->
<xs:sequence>
<xs:element name="userInfo" type="info:user-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValRequest --> <!-- blueprintsRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type"> <xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByValRequest" /> <xs:element ref="blueprintsRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValRequestType --> <!-- blueprintsRequestType -->
<xs:element name="sidebarsByValRequest" <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValRequestType"> <xs:complexType name="blueprintsRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="xpathFilter" <xs:element name="xpathFilter" type="xs:string"
type="xs:string" minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefRequest --> <!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type">
<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByRefRequest" /> <xs:element ref="blueprintRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefRequestType --> <!-- blueprintRequestType -->
<xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByValRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest"
type="sidebarByValRequestType"/>
<xs:complexType name="sidebarByValRequestType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- Definition of ccmp-response-message-type -->
<xs:complexType abstract="true" name="ccmp-response-message-type">
<xs:sequence>
<xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" minOccurs="0"
maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1"
maxOccurs="1" />
<xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
<xs:complexType name="blueprintsResponseType">
<xs:sequence>
<xs:element name="blueprintsInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintResponse -->
<xs:complexType name="ccmp-blueprint-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintResponseType -->
<xs:element name="blueprintResponse" type="blueprintResponseType"/> <xs:element name="blueprintRequest" type="blueprintRequestType" />
<xs:complexType name="blueprintResponseType"> <xs:complexType name="blueprintRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type" <xs:element name="blueprintInfo"
minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- confsResponse --> <!-- confsRequest -->
<xs:complexType name="ccmp-confs-response-message-type"> <xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confsResponse" /> <xs:element ref="confsRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confsResponseType --> <!-- confsRequestType -->
<xs:element name="confsResponse" type="confsResponseType" /> <xs:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsResponseType"> <xs:complexType name="confsRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="confsInfo" type="info:uris-type" <xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- confResponse --> <!-- confRequest -->
<xs:complexType name="ccmp-conf-response-message-type">
<xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confResponse"/> <xs:element ref="confRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confResponseType --> <!-- confRequestType -->
<xs:element name="confResponse" type="confResponseType" /> <xs:element name="confRequest" type="confRequestType" />
<xs:complexType name="confResponseType"> <xs:complexType name="confRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" type="info:conference-type" <xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- usersResponse --> <!-- usersRequest -->
<xs:complexType name="ccmp-users-response-message-type"> <xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="usersResponse" /> <xs:element ref="usersRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersResponseType --> <!-- usersRequestType -->
<xs:element name="usersResponse" type="usersResponseType" /> <xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersResponseType"> <xs:complexType name="usersRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="usersInfo" type="info:users-type" <xs:element name="usersInfo" type="info:users-type"
minOccurs="0"/> minOccurs="0" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:complexType> <!-- userRequest -->
<!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type"> <xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userResponse" /> <xs:element ref="userRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- userResponseType --> <!-- userRequestType -->
<xs:element name="userResponse" type="userResponseType" /> <xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userResponseType"> <xs:complexType name="userRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="userInfo" type="info:user-type" <xs:element name="userInfo" type="info:user-type"
minOccurs="0"/> minOccurs="0" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValResponse --> <!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-response-message-type"> <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByValResponse" /> <xs:element ref="sidebarsByValRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValResponseType --> <!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValResponse" <xs:element name="sidebarsByValRequest"
type="sidebarsByValResponseType" /> type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValResponseType"> <xs:complexType name="sidebarsByValRequestType">
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByValInfo" <xs:element name="xpathFilter" type="xs:string"
type="info:sidebars-by-val-type" minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefResponse --> <!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarsByRef-response-message-type"> <xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByRefResponse" /> <xs:element ref="sidebarByValRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValRequestType -->
<!-- sidebarsByRefResponseType --> <xs:element name="sidebarByValRequest"
type="sidebarByValRequestType"/>
<xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType"> <xs:complexType name="sidebarByValRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByRefInfo" type="info:uris-type" <xs:element name="sidebarByValInfo"
minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- sidebarByValResponse --> <!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type"> <xs:complexType name="ccmp-sidebarByRef-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByValResponse" /> <xs:element ref="sidebarByRefRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValResponseType --> <!-- sidebarByRefRequestType -->
<xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType"> <xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefResponse --> <!-- extendedRequest -->
<xs:complexType name="ccmp-sidebarByRef-response-message-type"> <xs:complexType name="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="extendedRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedRequestType -->
<xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="extendedRequestType">
<xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- CCMP RESPONSES -->
<!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByRefResponse" /> <xs:element ref="blueprintsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefResponseType --> <!-- blueprintsResponseType -->
<xs:element name="sidebarByRefResponse" <xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType"> <xs:complexType name="blueprintsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="blueprintsInfo" type="info:uris-type"
type="info:conference-type" minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- response-code --> <!-- blueprintResponse -->
<xs:element name="response-code" type="response-codeType" /> <xs:complexType name="ccmp-blueprint-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="response-codeType"> <!-- blueprintResponseType -->
<xs:restriction base="xs:positiveInteger">
<xs:pattern value="[0-9][0-9][0-9]" />
</xs:restriction>
</xs:simpleType> <xs:element name="blueprintResponse" type="blueprintResponseType"/>
<!-- operationType --> <xs:complexType name="blueprintResponseType">
<xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:simpleType name="operationType"> <!-- confsResponse -->
<xs:restriction base="xs:token">
<xs:enumeration value="retrieve"/>
<xs:enumeration value="create"/>
<xs:enumeration value="update"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
<!-- subject-type --> <xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="subject-type"> <!-- confsResponseType -->
<xs:sequence> <xs:element name="confsResponse" type="confsResponseType" />
<xs:element name="username" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP request extensions --> <xs:complexType name="confsResponseType">
<xs:complexType name="ccmp-extended-request-message-type"> <xs:sequence>
<xs:complexContent> <xs:element name="confsInfo" type="info:uris-type"
<xs:extension base="tns:ccmp-request-message-type"> minOccurs="0"/>
<xs:sequence> <xs:any namespace="##other" processContents="lax"
<xs:element ref="extendedRequest"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:extension> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexContent> </xs:complexType>
</xs:complexType>
<xs:element name="extendedRequest" type="extendedRequestType"/> <!-- confResponse -->
<xs:complexType name="extendedRequestType"> <xs:complexType name="ccmp-conf-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="0"/> <xs:element name="confInfo" type="info:conference-type"
<xs:any namespace="##other" processContents="lax" minOccurs="0" minOccurs="0"/>
maxOccurs="unbounded" /> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP response extensions --> <!-- usersResponse -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent> <xs:complexType name="ccmp-users-response-message-type">
<xs:extension base="tns:ccmp-response-message-type"> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="usersResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType">
<xs:sequence> <xs:sequence>
<xs:element ref="extendedResponse"/> <xs:element name="usersInfo" type="info:users-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:extension> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexContent> </xs:complexType>
</xs:complexType>
<xs:element name="extendedResponse" type="extendedResponseType"/> <!-- userResponse -->
<xs:complexType name="extendedResponseType"> <xs:complexType name="ccmp-user-response-message-type">
<xs:sequence> <xs:complexContent>
<xs:element name="extensionName" type="xs:string" minOccurs="0"/> <xs:extension base="tns:ccmp-response-message-type">
<xs:any namespace="##other" processContents="lax" minOccurs="0" <xs:sequence>
maxOccurs="unbounded" /> <xs:element ref="userResponse" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- options --> <!-- userResponseType -->
<xs:complexType name="ccmp-options-request-message-type"> <xs:element name="userResponse" type="userResponseType" />
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:complexType name="userResponseType">
</xs:complexContent> <xs:sequence>
</xs:complexType> <xs:element name="userInfo" type="info:user-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValResponse -->
<xs:complexType name="ccmp-sidebarsByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse"
type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByValResponseType">
<xs:sequence>
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByRefResponse -->
<xs:complexType name="ccmp-sidebarsByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType">
<xs:sequence>
<xs:element name="sidebarsByRefInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByValResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByRefResponse -->
<xs:complexType name="ccmp-sidebarByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extendedResponse -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="extendedResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedResponseType -->
<xs:element name="extendedResponse" type="extendedResponseType"/>
<xs:complexType name="extendedResponseType">
<xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- optionsResponse -->
<xs:complexType name="ccmp-options-response-message-type"> <xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="optionsResponse"/> <xs:element ref="optionsResponse"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- optionsResponseType -->
<xs:element name="optionsResponse" <xs:element name="optionsResponse"
type="optionsResponseType" /> type="optionsResponseType" />
<xs:complexType name="optionsResponseType"> <xs:complexType name="optionsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="options" <xs:element name="options"
type="options-type" minOccurs="0"/> type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- CCMP ELEMENT TYPES -->
<!-- response-codeType-->
<xs:element name="response-code" type="response-codeType" />
<xs:simpleType name="response-codeType">
<xs:restriction base="xs:positiveInteger">
<xs:pattern value="[0-9][0-9][0-9]" />
</xs:restriction>
</xs:simpleType>
<!-- operationType -->
<xs:simpleType name="operationType">
<xs:restriction base="xs:token">
<xs:enumeration value="retrieve"/>
<xs:enumeration value="create"/>
<xs:enumeration value="update"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
<!-- subject-type -->
<xs:complexType name="subject-type">
<xs:sequence>
<xs:element name="username" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- options-type -->
<xs:complexType name="options-type"> <xs:complexType name="options-type">
<xs:sequence> <xs:sequence>
<xs:element name="standard-message-list" type="standard-message-list-type" <xs:element name="standard-message-list" type="standard-message-list-type" minOccurs="1"/>
minOccurs="1"/> <xs:element name="extended-message-list" type="extended-message-list-type" minOccurs="0"/>
<xs:element name="extended-message-list" type="extended-message-list-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="standard-message-list-type"> <!-- standard-message-list-type -->
<xs:complexType name="standard-message-list-type">
<xs:sequence> <xs:sequence>
<xs:element name="standard-message" type="standard-message-type" minOccurs="1" maxOccurs="10"/> <xs:element name="standard-message" type="standard-message-type" minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- standard-message-type -->
<xs:complexType name="standard-message-type"> <xs:complexType name="standard-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="name" type="standard-message-name-type" minOccurs="1"/> <xs:element name="name" type="standard-message-name-type" minOccurs="1"/>
<xs:element name="operations" type="operations-type" minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" minOccurs="0"/> <xs:element name="schema-def" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/> <xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- standard-message-name-type -->
<xs:simpleType name="standard-message-name-type"> <xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/> <xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/> <xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/> <xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/> <xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/> <xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/> <xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/> <xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/> <xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/> <xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/> <xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="extended-message-list-type"> <!-- operations-type -->
<xs:complexType name="operations-type">
<xs:sequence>
<xs:element name="operation" type="operation-type"
minOccurs="1" maxOccurs="4"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extended-message-list-type -->
<xs:complexType name="extended-message-list-type">
<xs:sequence> <xs:sequence>
<xs:element name="extended-message" type="extended-message-type" minOccurs="0"/> <xs:element name="extended-message" type="extended-message-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- extended-message-type -->
<xs:complexType name="extended-message-type"> <xs:complexType name="extended-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="name" type="xs:string" /> <xs:element name="name" type="xs:string" />
<xs:element name="operations" type="operations-type" minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" /> <xs:element name="schema-def" type="xs:string" />
<xs:element name="description" type="xs:string" minOccurs="0"/> <xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- options --> </xs:schema>
</xs:schema>
Figure 26 Figure 30
12. IANA Considerations 12. IANA Considerations
This document registers a new XML namespace, a new XML schema, and This document registers a new XML namespace, a new XML schema, and
the MIME type for the schema. This document also registers the the MIME type for the schema. This document also registers the
"XCON" Application Service tag and the "CCMP" Application Protocol "XCON" Application Service tag and the "CCMP" Application Protocol
tag. This document also defines registries for the CCMP operation tag. This document also defines registries for the CCMP operation
types and response codes. types and response codes.
12.1. URN Sub-Namespace Registration 12.1. URN Sub-Namespace Registration
skipping to change at page 95, line 4 skipping to change at page 104, line 16
"optionsResponse" message) to the list of CCMP messages. "optionsResponse" message) to the list of CCMP messages.
2. Clarified discussion about notifications management, by 2. Clarified discussion about notifications management, by
clarifying they are out of the scope of the present document, but clarifying they are out of the scope of the present document, but
at the same time providing some pointers to potential ways for at the same time providing some pointers to potential ways for
implementing them. implementing them.
3. Clarified discussion about policies in XCON, by clarifying they 3. Clarified discussion about policies in XCON, by clarifying they
are out of the scope of the present document, but at the same are out of the scope of the present document, but at the same
time providing some pointers to potential ways for implementing time providing some pointers to potential ways for implementing
them. them.
4. Corrected minor typos in the schema. 4. Corrected minor typos in the schema.
5. Corrected schema definitions which brought to Unique Particle 5. Corrected schema definitions which brought to Unique Particle
Attribution exceptions. Attribution exceptions.
6. Added the newly defined "optionsRequest" and "optionsResponse" 6. Added the newly defined "optionsRequest" and "optionsResponse"
messages to the schema. messages to the schema.
7. Misc editorial nits... 7. Misc editorial nits...
The following summarizes the changes between the WG 08 and the 09:
1. Added a section on the extendedRequest/extendedResponse message
pair.
2. Added a section on the optionsRequest/optionsResponse message
pair.
3. Added an example sub-section about the use of the optionsRequest/
optionsResponse message pair.
4. Added an example sub-section about the use of the
extendedRequest/extendedResponse message pair.
5. Updated the schema in order to reflect the latest modifications
and add-ons.
6. Misc editorial nits...
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
skipping to change at page 96, line 37 skipping to change at page 106, line 13
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[I-D.ietf-xcon-examples] [I-D.ietf-xcon-examples]
Barnes, M., Miniero, L., Presta, R., and S. Romano, Barnes, M., Miniero, L., Presta, R., and S. Romano,
"Centralized Conferencing Manipulation Protocol (CCMP) "Centralized Conferencing Manipulation Protocol (CCMP)
Call Flow Examples", draft-ietf-xcon-examples-04 (work in Call Flow Examples", draft-ietf-xcon-examples-04 (work in
progress), April 2010. progress), April 2010.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Hadley, M., Gudgin, M., Nielsen, H., Moreau, J., and N. Gudgin, M., Hadley, M., Moreau, J., Nielsen, H., and N.
Mendelsohn, "SOAP Version 1.2 Part 1: Messaging Mendelsohn, "SOAP Version 1.2 Part 1: Messaging
Framework", World Wide Web Consortium FirstEdition REC- Framework", World Wide Web Consortium FirstEdition REC-
soap12-part1-20030624, June 2003, soap12-part1-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and Mendelsohn, N., Moreau, J., Nielsen, H., Gudgin, M., and
M. Hadley, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Hadley, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
Appendix A. Appendix A: Other protocol models and transports considered Appendix A. Appendix A: Other protocol models and transports considered
for CCMP for CCMP
The operations on the objects can be implemented in at least two The operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as different ways, namely as remote procedure calls - using SOAP as
 End of changes. 202 change blocks. 
754 lines changed or deleted 1165 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/