draft-ietf-xcon-ccmp-07.txt   draft-ietf-xcon-ccmp-08.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: October 28, 2010 NS-Technologies Expires: December 20, 2010 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
April 26, 2010 June 18, 2010
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-07 draft-ietf-xcon-ccmp-08
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 October 28, 2010. This Internet-Draft will expire on December 20, 2010.
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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. blueprintsRequest and blueprintsResponse . . . . . . . 18 5.3.1. optionsRequest and optionsResponse . . . . . . . . . . 19
5.3.2. confsRequest and confsResponse . . . . . . . . . . . . 20 5.3.2. blueprintsRequest and blueprintsResponse . . . . . . . 21
5.3.3. blueprintRequest and blueprintResponse . . . . . . . . 22 5.3.3. confsRequest and confsResponse . . . . . . . . . . . . 23
5.3.4. confRequest and confResponse . . . . . . . . . . . . . 24 5.3.4. blueprintRequest and blueprintResponse . . . . . . . . 25
5.3.5. usersRequest and usersResponse . . . . . . . . . . . . 28 5.3.5. confRequest and confResponse . . . . . . . . . . . . . 27
5.3.6. userRequest and userResponse . . . . . . . . . . . . . 30 5.3.6. usersRequest and usersResponse . . . . . . . . . . . . 31
5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . . 34 5.3.7. userRequest and userResponse . . . . . . . . . . . . . 33
5.3.8. sidebarByValRequest and sidebarByValResponse . . . . . 36 5.3.8. sidebarsByValRequest and sidebarsByValResponse . . . . 37
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . . 39 5.3.9. sidebarByValRequest and sidebarByValResponse . . . . . 39
5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . . 40 5.3.10. sidebarsByRefRequest and sidebarsByRefResponse . . . . 42
5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 43 5.3.11. sidebarByRefRequest and sidebarByRefResponse . . . . . 43
6. A complete example of the CCMP in action . . . . . . . . . . . 46 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 46
6.1. Alice retrieves the available blueprints . . . . . . . . . 47 6. A complete example of the CCMP in action . . . . . . . . . . . 49
6.1. Alice retrieves the available blueprints . . . . . . . . . 50
6.2. Alice gets detailed information about a specific 6.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 49 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3. Alice creates a new conference through a cloning 6.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 51 operation . . . . . . . . . . . . . . . . . . . . . . . . 54
6.4. Alice updates conference information . . . . . . . . . . . 54 6.4. Alice updates conference information . . . . . . . . . . . 57
6.5. Alice inserts a list of users in the conference object . . 56 6.5. Alice inserts a list of users in the conference object . . 59
6.6. Alice joins the conference . . . . . . . . . . . . . . . . 57 6.6. Alice joins the conference . . . . . . . . . . . . . . . . 60
6.7. Alice adds a new user to the conference . . . . . . . . . 59 6.7. Alice adds a new user to the conference . . . . . . . . . 62
7. Locating a Conference Control Server . . . . . . . . . . . . . 61 7. Locating a Conference Control Server . . . . . . . . . . . . . 64
8. Managing Notifications . . . . . . . . . . . . . . . . . . . . 63 8. Managing Notifications . . . . . . . . . . . . . . . . . . . . 66
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 63 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 67
10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69
10.1. Assuring that the Proper Conferencing Server has been 10.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 66 contacted . . . . . . . . . . . . . . . . . . . . . . . . 69
10.2. User Authentication and Authorization . . . . . . . . . . 66 10.2. User Authentication and Authorization . . . . . . . . . . 70
10.3. Security and Privacy of Identity . . . . . . . . . . . . . 67 10.3. Security and Privacy of Identity . . . . . . . . . . . . . 71
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 68 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 72
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 82 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 88
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 83 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 89
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 83 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 89
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 84 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 90
12.4.1. Registration of a Conference Control Server 12.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 84 Application Service Tag . . . . . . . . . . . . . . . 90
12.4.2. Registration of a Conference Control Server 12.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 84 Application Protocol Tag for CCMP . . . . . . . . . . 91
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 85 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 91
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 85 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 91
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 86 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 92
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94
14. Changes since last Version . . . . . . . . . . . . . . . . . . 87 14. Changes since last Version . . . . . . . . . . . . . . . . . . 94
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95
15.1. Normative References . . . . . . . . . . . . . . . . . . . 89 15.1. Normative References . . . . . . . . . . . . . . . . . . . 95
15.2. Informative References . . . . . . . . . . . . . . . . . . 90 15.2. Informative References . . . . . . . . . . . . . . . . . . 95
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . . 91 considered for CCMP . . . . . . . . . . . . . . . . . 97
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 91 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 97
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 92 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 98
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99
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.6 representing the case of a user at his first out in Section 5.3.7 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.6. will be provided in Section 5.3.7.
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. blueprintsRequest/blueprintsResponse 1. optionsRequest/optionsResponse
2. confsRequest/confsResponse 2. blueprintsRequest/blueprintsResponse
3. blueprintRequest/blueprintResponse 3. confsRequest/confsResponse
4. confRequest/confResponse 4. blueprintRequest/blueprintResponse
5. usersRequest/usersResponse 5. confRequest/confResponse
6. userRequest/userResponse 6. usersRequest/usersResponse
7. sidebarsByValRequest/sidebarsByValResponse 7. userRequest/userResponse
8. sidebarsByRefRequest/sidebarsByRefResponse 8. sidebarsByValRequest/sidebarsByValResponse
9. sidebarByValRequest/sidebarByValResponse 9. sidebarsByRefRequest/sidebarsByRefResponse
10. sidebarByRefRequest/sidebarByRefResponse 10. sidebarByValRequest/sidebarByValResponse
11. sidebarByRefRequest/sidebarByRefResponse
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. Table 1 as defined in Section 4.1 to manipulate the conference data. The
summarizes the CCMP operations and corresponding actions that are optionsRequest/optionsResponse message pair deserves a specific
valid for a specific CCMP request type, noting that neither the discussion, since it is not used for manipulating information about
blueprintsRequest/blueprintsResponse nor confsRequest/confsResponse either conferences or conference users, but rather to retrieve
require an "operation" parameter. The corresponding response MUST general information about conference server capabilities, in terms of
contain the same operation. Note that some entries are labeled "N/A" standard CCMP messages it supports, plus potential extension messages
indicating the operation is invalid for that request type. In the it understands, as it will be further explained in Section 5.3.1.
case of an "N/A*", the operation MAY be allowed for specific Table 1 summarizes the remaining CCMP operations and corresponding
privileged users or system administrators, but is not part of the actions that are valid for a specific CCMP request type, noting that
functionality included in this document. neither the blueprintsRequest/blueprintsResponse nor confsRequest/
confsResponse require an "operation" parameter. The corresponding
response MUST contain the same operation. Note that some entries are
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
specific privileged users or system administrators, but is not part
of the functionality included in this document.
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | Update | Delete | | Operation | Retrieve | Create | Update | Delete |
| ------------- | | | | | | ------------- | | | | |
| Request Type | | | | | | Request Type | | | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| blueprints | Get list | N/A | N/A | N/A | | blueprints | Get list | N/A | N/A | N/A |
| Request | of | | | | | Request | of | | | |
| | blueprints | | | | | | blueprints | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
skipping to change at page 18, line 38 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. blueprintsRequest and blueprintsResponse 5.3.1. optionsRequest and optionsResponse
A "blueprintsRequest" (Figure 4) message is sent to request the list 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
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.3. The specific blueprintRequest message per Section 5.3.4. 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 4, a "blueprintsInfo" parameter containing the above in Figure 5, 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 19, line 49 skipping to change at page 23, line 4
<!-- blueprintsResponse --> <!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type"> <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="blueprintsResponse" /> <xs:element ref="blueprintsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintsResponseType --> <!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="blueprintsResponseType"/> <xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
<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 4: Structure of the blueprintsRequest and blueprintsResponse Figure 5: Structure of the blueprintsRequest and blueprintsResponse
messages messages
5.3.2. confsRequest and confsResponse 5.3.3. 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 21, line 49 skipping to change at page 25, line 4
<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
Figure 5: Structure of the confsRequest and confsResponse messages 5.3.4. blueprintRequest and blueprintResponse
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 23, line 44 skipping to change at page 26, line 47
<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 6: Structure of the blueprintRequest and blueprintResponse Figure 7: Structure of the blueprintRequest and blueprintResponse
messages messages
5.3.4. confRequest and confResponse 5.3.5. 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 25, line 25 skipping to change at page 28, line 25
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 8: Updating a conference object: removing the title of a Figure 9: 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 26, line 44 skipping to change at page 29, line 44
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 9. Figure 10.
<!-- 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 28, line 4 skipping to change at page 31, line 4
<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 9: Structure of the confRequest and confResponse messages Figure 10: Structure of the confRequest and confResponse messages
5.3.5. usersRequest and usersResponse 5.3.6. 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 30, line 7 skipping to change at page 33, line 7
<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 10: Structure of the usersRequest and usersResponse messages Figure 11: Structure of the usersRequest and usersResponse messages
5.3.6. userRequest and userResponse 5.3.7. 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 31, line 41 skipping to change at page 34, line 41
... ...
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 11: userRequest and userResponse in the absence of an xcon- Figure 12: 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 34, line 28 skipping to change at page 37, line 28
<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 12: Structure of the userRequest and userResponse messages Figure 13: Structure of the userRequest and userResponse messages
5.3.7. sidebarsByValRequest and sidebarsByValResponse 5.3.8. 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.8. which is described in Section 5.3.9.
<!-- 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 36, line 13 skipping to change at page 39, line 13
<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 13: Structure of the sidebarsByValRequest and Figure 14: Structure of the sidebarsByValRequest and
sidebarsByValResponse messages sidebarsByValResponse messages
5.3.8. sidebarByValRequest and sidebarByValResponse 5.3.9. 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 37, line 6 skipping to change at page 40, line 6
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.4. included in a confRequest message as detailed in Section 5.3.5.
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.4. A included in a confRequest message as detailed in Section 5.3.5. 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 39, line 4 skipping to change at page 42, line 4
<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 14: Structure of the sidebarByValRequest and Figure 15: Structure of the sidebarByValRequest and
sidebarByValResponse messages sidebarByValResponse messages
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 5.3.10. 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.10. A "sidebarByRef" request message, described in Section 5.3.11. 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 40, line 36 skipping to change at page 43, line 36
<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 15: Structure of the sidebarsByRefRequest and Figure 16: Structure of the sidebarsByRefRequest and
sidebarsByRefResponse messages sidebarsByRefResponse messages
5.3.10. sidebarByRefRequest and sidebarByRefResponse 5.3.11. 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 41, line 29 skipping to change at page 44, line 29
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.4. Section 5.3.5.
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.4. A confRequest message as detailed in Section 5.3.5. 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 43, line 27 skipping to change at page 46, line 27
<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.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
skipping to change at page 44, line 17 skipping to change at page 47, line 17
420 User Not Found: Target user missing at the server (it is related 420 User Not Found: Target user missing at the server (it is related
to the XCON-USERID in the "entity" attribute of the "userInfo" to the XCON-USERID in the "entity" attribute of the "userInfo"
parameter when it is included in userRequests) parameter when it is included in userRequests)
421 Invalid confUserID: User missing at the server (this code is 421 Invalid confUserID: User missing at the server (this code is
returned in the case of requests in which the "confUserID" of the returned in the case of requests in which the "confUserID" of the
sender is invalid). sender is invalid).
422 Invalid Conference Password: Target conference object's password 422 Invalid Conference Password: Target conference object's password
contained in the request is wrong. contained in the request is wrong.
423 Conference Password Required: "conference-password" missing in a 423 Conference Password Required: "conference-password" missing in a
request to access a password-protected conference object. request to access a password-protected conference object.
424 Authentication Required: User's authentication information 424 Authentication Required: User's authentication information is
missing in a request to perform the requested operation. "subject" missing or invalid.
parameter needed in the request.
425 Forbidden Delete Parent: Cancel operation failed since the 425 Forbidden Delete Parent: Cancel operation failed since the
target object is a parent of child objects which depend on it, or target object is a parent of child objects which depend on it, or
because it effects, based on the "parent-enforceable" mechanism, because it effects, based on the "parent-enforceable" mechanism,
the corresponding element in a child object. the corresponding element in a child object.
426 Forbidden Change Protected: Update refused by the server because 426 Forbidden Change Protected: Update refused by the server because
the target element cannot be modified due to its implicit the target element cannot be modified due to its implicit
dependence on the value of a parent object ("parent-enforceable" dependence on the value of a parent object ("parent-enforceable"
mechanism). mechanism).
500 Server Internal Error: The server cannot complete the required 500 Server Internal Error: The server cannot complete the required
service due to a system internal error. service due to a system internal error.
skipping to change at page 49, line 33 skipping to change at page 52, line 33
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 17: Getting blueprints from the server Figure 18: 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 51, line 31 skipping to change at page 54, 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 18: Getting info about a specific blueprint Figure 19: 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 54, line 10 skipping to change at page 57, line 10
<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 19: Creating a new conference by cloning a blueprint Figure 20: 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 56, line 4 skipping to change at page 59, line 4
<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 20: Updating conference information Figure 21: 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 57, line 37 skipping to change at page 60, line 37
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 21: Updating the list of allowed users for the conference Figure 22: 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 59, line 33 skipping to change at page 62, line 33
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 22: Alice joins the conference through the CCMP Figure 23: 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 61, line 42 skipping to change at page 64, line 42
</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 23: Alice adds a new user to the conference through the CCMP Figure 24: Alice adds a new user to the conference through the CCMP
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 62, line 21 skipping to change at page 65, line 21
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 24 demonstrate the The NAPTR records in the following example Figure 25 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 62, line 46 skipping to change at page 65, line 46
"" ; 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 24: Sample XCON:CCMP Service NAPTR Records Figure 25: 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
which have been formally identified within the XCON framework:
Conference Control Protocol: between Conference and Media Control
Client and Conference Server. Such protocol is the subject of the
present document.
Binary floor Control Protocol: between the Floor Control Client and
the Floor Control Server. Such protocol is the BFCP, specified in
[RFC4582].
Call Signaling Protocol: between the Call Signaling Client and the
Focus. Such protocol can be either SIP or any other call
signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating
a conferencing session.
Notification Protocol: between the Notification Client and the XCON
Notification Service. Such protocol has not been identified as
yet.
The CCMP protocol specified in this document is a pro-active one and
is used by a conferencing client to send requests to a conferencing
server in order to retrieve information about the conference objects
it stores and potentially manipulate them. Though, it stands clear
that a complete conferencing solution cannot refrain from providing
clients with a means for receiving asynchronous updates about the
status of the objects available at the server. The notification
protocol to be adopted in XCON, while conceptually independent of all
the mentioned companion protocols, can nonetheless be chosen in a way
that is consistent with the overall protocol architecture
characterizing a specific deployment, as it is discussed in the
following.
When the conference control client uses SIP [RFC3261] as the When the conference control client uses SIP [RFC3261] as the
signaling protocol to participate in the conference, SIP event signaling protocol to participate in the conference, SIP event
notification can be used. In such a case, the conference control notification can be used. In such a case, the conference control
client MUST implement the Conference event package for XCON client MUST implement the Conference event package for XCON
[I-D.ietf-xcon-event-package]. This is the default mechanism for [I-D.ietf-xcon-event-package]. This is the default mechanism for
conferencing clients as is SIP for signaling per the XCON Framework conferencing clients as is SIP for signaling per the XCON Framework
[RFC5239]. [RFC5239].
In the case where the interface to the conference server is entirely In the case where the interface to the conference server is entirely
web based, there is a common mechanism for web-based systems that web based, there is a common mechanism for web-based systems that
skipping to change at page 67, line 22 skipping to change at page 70, line 49
mechanisms available on the conference server, the conference server mechanisms available on the conference server, the conference server
MUST allocate a conference user identifier (XCON-USERID) and SHOULD MUST allocate a conference user identifier (XCON-USERID) and SHOULD
associate the XCON-USERID with any signaling specific user associate the XCON-USERID with any signaling specific user
identifiers that were used for authentication and authorization. identifiers that were used for authentication and authorization.
This XCON-USERID can be provided to a specific user through the This XCON-USERID can be provided to a specific user through the
conference notification interface and MUST be provided to users that conference notification interface and MUST be provided to users that
interact with the conferencing system using the CCMP (i.e., in the interact with the conferencing system using the CCMP (i.e., in the
appropriate CCMP response messages). This conference user identifier appropriate CCMP response messages). This conference user identifier
is REQUIRED for any subsequent operations on the conference object. is REQUIRED for any subsequent operations on the conference object.
We herein remark that the definition of a complete solution for
policy-based management of an XCON-compliant conference system is out
of the scope of this document, as well as of the XCON WG. We believe
that the specification of such a framework is orthogonal to the
overall XCON architecture, especially if a Role Based Access Control
(RBAC) approach is embraced. In RBAC, the following elements are
identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations;
(v) Permissions. For all of the above elements a direct mapping
exists onto the main XCON entities. As an example, RBAC objects map
onto XCON data model objects and RBAC operations map onto CCMP
operations.
Future documents might work on the definition of an RBAC framework
for XCON, by first focusing on the definition of roles and eventually
arriving at the specification of the needed permission policy sets
and role policy sets (used to associate policy permission sets with
specific roles). With these policies in place, access to a
conference object compliant with the XCON data model can be
appropriately controlled. Finally, coming to the issue of assigning
users to roles, this can be done through so-called role-assignment
policies. Such assignment should be under the responsibility of an
ad-hoc dedicated Role Assignment entity.
10.3. Security and Privacy of Identity 10.3. Security and Privacy of Identity
An overview of the required privacy and anonymity for users of a An overview of the required privacy and anonymity for users of a
conferencing system are provided in the XCON Framework [RFC5239]. conferencing system are provided in the XCON Framework [RFC5239].
The security of the identity in the form of the XCON-USERID is The security of the identity in the form of the XCON-USERID is
provided in the CCMP protocol through the use of TLS. provided in the CCMP protocol through the use of TLS.
The conference server SHOULD provide mechanisms to ensure the privacy The conference server SHOULD provide mechanisms to ensure the privacy
of the XCON-USERID. This is accomplished by the conference client of the XCON-USERID. This is accomplished by the conference client
manipulation of the "provide-anonymity" element defined in the XCON manipulation of the "provide-anonymity" element defined in the XCON
skipping to change at page 68, line 11 skipping to change at page 72, line 13
userRequest message with an "update" or "create" operation, to ensure userRequest message with an "update" or "create" operation, to ensure
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 <xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp" targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:xcon:ccmp" xmlns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:tns="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:dm="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"> xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info" <xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
schemaLocation="DataModel.xsd"/> schemaLocation="DataModel.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-info" <xs:import namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="rfc4575.xsd"/> schemaLocation="rfc4575.xsd"/>
<xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpRequest" type="ccmp-request-type" />
<xs:element name="ccmpResponse" type="ccmp-response-type" /> <xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- CCMP request definition --> <!-- CCMP request definition -->
<xs:complexType name="ccmp-request-type"> <xs:complexType name="ccmp-request-type">
<xs:sequence> <xs:sequence>
<xs:element name="ccmpRequest" <xs:element name="ccmpRequest"
type="ccmp-request-message-type" /> type="ccmp-request-message-type" />
</xs:sequence> </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:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsRequestType">
<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>
<!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- CCMP response definition --> <!-- confRequestType -->
<xs:complexType name="ccmp-response-type"> <xs:element name="confRequest" type="confRequestType" />
<xs:sequence>
<xs:element name="ccmpResponse" <xs:complexType name="confRequestType">
type="ccmp-response-message-type" /> <xs:sequence>
</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:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- Definition of ccmp-request-message-type --> <!-- userRequest -->
<xs:complexType abstract="true"
name="ccmp-request-message-type"> <xs:complexType name="ccmp-user-request-message-type">
<xs:sequence> <xs:complexContent>
<xs:element name="subject" type="subject-type" <xs:extension base="tns:ccmp-request-message-type">
minOccurs="0" maxOccurs="1" /> <xs:sequence>
<xs:element name="confUserID" type="xs:string" <xs:element ref="userRequest" />
minOccurs="0" maxOccurs="1" /> </xs:sequence>
<xs:element name="confObjID" type="xs:string" </xs:extension>
minOccurs="0" maxOccurs="1" /> </xs:complexContent>
<xs:element name="operation" type="operationType" </xs:complexType>
minOccurs="0" maxOccurs="1" />
<xs:element name="conference-password" type="xs:string" <!-- userRequestType -->
minOccurs="0" maxOccurs="1" />
<xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType">
<xs:sequence>
<xs:element name="userInfo" type="info:user-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>
<!-- blueprintsRequest --> <!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-blueprints-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="blueprintsRequest" /> <xs:element ref="sidebarsByValRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintsRequestType --> <!-- sidebarsByValRequestType -->
<xs:element name="blueprintsRequest" type="blueprintsRequestType"/> <xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" />
<xs:complexType name="blueprintsRequestType"> <xs:complexType name="sidebarsByValRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="xpathFilter" type="xs:string" <xs:element name="xpathFilter"
minOccurs="0"/> 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>
<!-- blueprintRequest --> <!-- sidebarsByRefRequest -->
<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="blueprintRequest" /> <xs:element ref="sidebarsByRefRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintRequestType --> <!-- sidebarsByRefRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType" /> <xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="blueprintRequestType"> <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:complexType name="blueprintResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" <xs:element name="blueprintInfo" type="info:conference-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>
<!-- confsRequest --> <!-- confsResponse -->
<xs:complexType name="ccmp-confs-request-message-type"> <xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confsRequest" /> <xs:element ref="confsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confsRequestType --> <!-- confsResponseType -->
<xs:element name="confsRequest" type="confsRequestType" /> <xs:element name="confsResponse" type="confsResponseType" />
<xs:complexType name="confsRequestType"> <xs:complexType name="confsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="xpathFilter" type="xs:string" <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>
<!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type"> <!-- confResponse -->
<xs:complexType name="ccmp-conf-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confRequest" /> <xs:element ref="confResponse"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confRequestType --> <!-- confResponseType -->
<xs:element name="confRequest" type="confRequestType" /> <xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confRequestType"> <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>
<!-- usersRequest --> <!-- usersResponse -->
<xs:complexType name="ccmp-users-request-message-type"> <xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="usersRequest" /> <xs:element ref="usersResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersRequestType --> <!-- usersResponseType -->
<xs:element name="usersRequest" type="usersRequestType" /> <xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersRequestType"> <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>
<!-- userRequest --> </xs:complexType>
<xs:complexType name="ccmp-user-request-message-type"> <!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userRequest" /> <xs:element ref="userResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- userRequestType --> <!-- userResponseType -->
<xs:element name="userRequest" type="userRequestType" /> <xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userRequestType"> <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>
<!-- sidebarsByValRequest --> <!-- sidebarsByValResponse -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type"> <xs:complexType name="ccmp-sidebarsByVal-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByValRequest" /> <xs:element ref="sidebarsByValResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValRequestType --> <!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" />
<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" <xs:element name="sidebarsByValResponse"
type="sidebarsByRefRequestType" /> type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByRefRequestType"> <xs:complexType name="sidebarsByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="xpathFilter" type="xs:string" <xs:element name="sidebarsByValInfo"
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>
<!-- sidebarByValRequest --> <!-- sidebarsByRefResponse -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type"> <xs:complexType name="ccmp-sidebarsByRef-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByValRequest" /> <xs:element ref="sidebarsByRefResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest" <!-- sidebarsByRefResponseType -->
type="sidebarByValRequestType"/>
<xs:complexType name="sidebarByValRequestType"> <xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarsByRefInfo" 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>
<!-- sidebarByRefRequest --> <!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type"> <xs:complexType name="ccmp-sidebarByVal-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByRefRequest" /> <xs:element ref="sidebarByValResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefRequestType --> <!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse"
<xs:element name="sidebarByRefRequest" type="sidebarByValResponseType" />
type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType"> <xs:complexType name="sidebarByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <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>
<!-- 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> </xs:complexType>
<!-- blueprintsResponse --> <!-- sidebarByRefResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type"> <xs:complexType name="ccmp-sidebarByRef-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="blueprintsResponse" /> <xs:element ref="sidebarByRefResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintsResponseType --> <!-- sidebarByRefResponseType -->
<xs:element name="blueprintsResponse" type="blueprintsResponseType"/> <xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" />
<xs:complexType name="blueprintsResponseType"> <xs:complexType name="sidebarByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintsInfo" type="info:uris-type" <xs:element name="sidebarByRefInfo"
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>
<!-- blueprintResponse --> <!-- response-code -->
<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:complexType name="blueprintResponseType"> <xs:element name="response-code" type="response-codeType" />
<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>
<!-- confsResponse --> <xs:simpleType name="response-codeType">
<xs:restriction base="xs:positiveInteger">
<xs:pattern value="[0-9][0-9][0-9]" />
</xs:restriction>
<xs:complexType name="ccmp-confs-response-message-type"> </xs:simpleType>
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsResponseType --> <!-- operationType -->
<xs:element name="confsResponse" type="confsResponseType" /> <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>
<xs:complexType name="confsResponseType"> <!-- subject-type -->
<xs:sequence>
<xs:element name="confsInfo" 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>
<!-- confResponse --> <xs:complexType name="subject-type">
<xs:complexType name="ccmp-conf-response-message-type"> <xs:sequence>
<xs:complexContent> <xs:element name="username" type="xs:string"
<xs:extension base="tns:ccmp-response-message-type"> minOccurs="0" maxOccurs="1" />
<xs:sequence> <xs:element name="password" type="xs:string"
<xs:element ref="confResponse"/> minOccurs="0" maxOccurs="1" />
</xs:sequence> <xs:any namespace="##other" processContents="lax"
</xs:extension> minOccurs="0" maxOccurs="unbounded"/>
</xs:complexContent> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confResponseType --> <!-- CCMP request extensions -->
<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>
<xs:element name="confResponse" type="confResponseType" /> <xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="confResponseType"> <xs:complexType name="extendedRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" type="info:conference-type" <xs:element name="extensionName" type="xs:string" minOccurs="0"/>
minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0"
<xs:any namespace="##other" processContents="lax" maxOccurs="unbounded" />
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType>
</xs:complexType>
<!-- usersResponse -->
<xs:complexType name="ccmp-users-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"> <!-- CCMP response extensions -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="usersInfo" type="info:users-type" <xs:element ref="extendedResponse"/>
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> </xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="userResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userResponseType --> <xs:element name="extendedResponse" type="extendedResponseType"/>
<xs:element name="userResponse" type="userResponseType" /> <xs:complexType name="extendedResponseType">
<xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="userResponseType"> <!-- options -->
<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>
<!-- sidebarsByValResponse --> <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-sidebarsByVal-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="sidebarsByValResponse" /> <xs:element ref="optionsResponse"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValResponseType --> <xs:element name="optionsResponse"
type="optionsResponseType" />
<xs:element name="sidebarsByValResponse"
type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByValResponseType"> <xs:complexType name="optionsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByValInfo" <xs:element name="options"
type="info:sidebars-by-val-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>
<!-- sidebarsByRefResponse --> <xs:complexType name="options-type">
<xs:sequence>
<xs:complexType name="ccmp-sidebarsByRef-response-message-type"> <xs:element name="standard-message-list" type="standard-message-list-type"
<xs:complexContent> minOccurs="1"/>
<xs:extension base="tns:ccmp-response-message-type"> <xs:element name="extended-message-list" type="extended-message-list-type"
<xs:sequence> minOccurs="0"/>
<xs:element ref="sidebarsByRefResponse" /> <xs:any namespace="##other" processContents="lax"
</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"/> 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 --> <xs:complexType name="standard-message-list-type">
<xs:sequence>
<xs:complexType name="ccmp-sidebarByVal-response-message-type"> <xs:element name="standard-message" type="standard-message-type" minOccurs="1" maxOccurs="10"/>
<xs:complexContent> <xs:any namespace="##other" processContents="lax"
<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"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <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> </xs:complexType>
<!-- sidebarByRefResponseType --> <xs:complexType name="standard-message-type">
<xs:sequence>
<xs:element name="sidebarByRefResponse" <xs:element name="name" type="standard-message-name-type" minOccurs="1"/>
type="sidebarByRefResponseType" /> <xs:element name="schema-def" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:complexType name="sidebarByRefResponseType"> <xs:any namespace="##other" processContents="lax"
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<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 --> <xs:simpleType name="standard-message-name-type">
<xs:element name="response-code" type="response-codeType" />
<xs:simpleType name="response-codeType">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xs:simpleType>
<!-- operationType -->
<xs:simpleType name="operationType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="retrieve"/> <xs:enumeration value="confsRequest"/>
<xs:enumeration value="create"/> <xs:enumeration value="confRequest"/>
<xs:enumeration value="update"/> <xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="delete"/> <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:restriction>
</xs:simpleType> </xs:simpleType>
<!-- subject-type --> <xs:complexType name="extended-message-list-type">
<xs:sequence>
<xs:complexType name="subject-type"> <xs:element name="extended-message" type="extended-message-type" minOccurs="0"/>
<xs:sequence> <xs:any namespace="##other" processContents="lax"
<xs:element name="username" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
minOccurs="0" maxOccurs="1" /> </xs:sequence>
<xs:element name="password" type="xs:string" <xs:anyAttribute namespace="##any" processContents="lax"/>
minOccurs="0" maxOccurs="1" /> </xs:complexType>
<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="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- CCMP response extensions... --> <xs:complexType name="extended-message-type">
<xs:complexType name="ccmp-extended-response-message-type"> <xs:sequence>
<xs:complexContent> <xs:element name="name" type="xs:string" />
<xs:extension base="tns:ccmp-response-message-type"> <xs:element name="schema-def" type="xs:string" />
<xs:sequence> <xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" <xs:any namespace="##other" processContents="lax"
maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:extension> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:complexContent> <!-- options -->
</xs:complexType>
</xs:schema> </xs:schema>
Figure 25 Figure 26
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 85, line 27 skipping to change at page 92, line 5
Related Registry: CCMP Message Types Registry Related Registry: CCMP Message Types Registry
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: New CCMP message types are Registration/Assignment Procedures: New CCMP message types are
allocated on a specification required basis. allocated on a specification required basis.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
This section pre-registers the following initial CCMP message types: This section pre-registers the following initial CCMP message types:
optionsRequest: Used by a conference control client to query a
conferencing system for its capabilities, in terms of supported
messages (both standard and non-standard).
optionsResponse: The optionsResponse returns a list of CCMP messages
(both standard and non-standard) supported by the specific
conference server.
blueprintsRequest: Used by a conference control client to query a blueprintsRequest: Used by a conference control client to query a
conferencing system for its capabilities, in terms of available conferencing system for its capabilities, in terms of available
conference blueprints. conference blueprints.
blueprintsResponse: The blueprintsResponse returns a list of blueprintsResponse: The blueprintsResponse returns a list of
blueprints supported by the specific conference server. blueprints supported by the specific conference server.
confsRequest: Used by a conference control client to query a confsRequest: Used by a conference control client to query a
conferencing system for its scheduled/active conferences. conferencing system for its scheduled/active conferences.
confsResponse: The "confsResponse" returns the list of the currently confsResponse: The "confsResponse" returns the list of the currently
activated/scheduled conferences at the server. activated/scheduled conferences at the server.
confRequest: The "confRequest" is used to create a conference object confRequest: The "confRequest" is used to create a conference object
skipping to change at page 88, line 4 skipping to change at page 94, line 33
extracted. extracted.
14. Changes since last Version 14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
The following summarizes the changes between the WG 03 and the 04: The following summarizes the changes between the WG 03 and the 04:
1. Re-organized document based on feedback from Richard Barnes. 1. Re-organized document based on feedback from Richard Barnes.
2. Editorial clarifications and nits, including those identified by 2. Editorial clarifications and nits, including those identified by
Richard and Simo Veikkolainen. Richard and Simo Veikkolainen.
The following summarizes the changes between the WG 02 and the 03: The following summarizes the changes between the WG 07 and the 08:
1. Clarified that the confUserID is optional in the generic CCMP
request message for a userRequest with a "create" operation.
2. Added response-code (error cases) handling - a general section
for each of the operations (as part of CCMP Response Code
section), so we don't need to re-iterate for each of the messages
and message specific cases as appropriate (e.g., 425, modified)
3. Moved "operation" parameter to be part of general CCMP request
and response messages since it is used for more than one message
type. And, it's necessary to define before describing the
operation specific response-code handling.
4. Revised normative statements for the various protocol messages
and operations - e.g., messages MUST include parameter x versus
SHOULD, adding text for handling of cases where the SHOULDs don't
happen and the SHOULD NOTs do. Added descriptions for all the
operation types, as appropriate.
5. Added lots more details in the security section.
6. Added section to describe requirements for an HTTP implementation
to support CCMP.
7. Updated section on notifications - XCON SIP event package is
default, with some discussion of an HTTP callback mechanism
(ffs).
8. Misc editorial nits: qualifying message names in the text, etc.,
etc., etc.
The following summarizes the changes between the WG 01 and the 02:
1. Changed the basic approach from REST to HTTP as a transport.
This impacted most of the document - i.e., a major rewrite - 02
is closer to 00 than the 01.
2. Added full example based on prototype.
The following summarizes the changes between the WG 00 and the 01:
1. Changed the basic approach from using SOAP to REST - the 1. Added a new "optionsRequest" message (and related
fundamentals are the same in terms of schema, basic operations. "optionsResponse" message) to the list of CCMP messages.
This impacted most sections, in particular introduction and 2. Clarified discussion about notifications management, by
motivation. clarifying they are out of the scope of the present document, but
2. Added new request types - blueprintsRequest, blueprintRequest and at the same time providing some pointers to potential ways for
confsRequest. The first replaces the optionsRequest and the implementing them.
latter allows the client to get a list of all active conferences. 3. Clarified discussion about policies in XCON, by clarifying they
3. Merged all requests into the basic operations table. Added are out of the scope of the present document, but at the same
summary of RESTful examples (referenced by the basic operations time providing some pointers to potential ways for implementing
table. them.
4. Corrected minor typos in the schema.
4. Added examples showing RESTful approach - i.e., HTTP methods for 5. Corrected schema definitions which brought to Unique Particle
message exchange. Attribution exceptions.
5. Removed requestID from the schema (it should be handle by the 6. Added the newly defined "optionsRequest" and "optionsResponse"
transport - e.g., HTTP). Updated schema (based on current messages to the schema.
prototype - it still needs another revision. 7. Misc editorial nits...
6. Added placeholders for Notifications and Role Based Access
Control.
7. Added some text for discovery using DNS (including IANA
registrations)
8. Updated References: updated XCON FW RFC, SOAP/W3C moved to
informational section.
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
skipping to change at page 89, line 50 skipping to change at page 95, line 44
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-18 Conferencing (XCON)", draft-ietf-xcon-common-data-model-19
(work in progress), February 2010. (work in progress), May 2010.
15.2. Informative References 15.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network- [REST] Fielding, "Architectural Styles and the Design of Network-
based Software Architectures", 2000. based Software Architectures", 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 90, line 25 skipping to change at page 96, line 20
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
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]
Gudgin, M., Nielsen, H., Hadley, M., Moreau, J., and N. Hadley, M., Gudgin, M., Nielsen, H., Moreau, J., 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]
Mendelsohn, N., Nielsen, H., Hadley, M., Moreau, J., and Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and
M. Gudgin, "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
described in Appendix A.1 and by defining resources following a described in Appendix A.1 and by defining resources following a
 End of changes. 204 change blocks. 
624 lines changed or deleted 886 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/