draft-ietf-xcon-ccmp-14.txt   draft-ietf-xcon-ccmp-15.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Intended status: Standards Track C. Boulton Intended status: Standards Track C. Boulton
Expires: January 13, 2012 NS-Technologies Expires: February 4, 2012 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
July 12, 2011 August 3, 2011
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-14 draft-ietf-xcon-ccmp-15
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 January 13, 2012. This Internet-Draft will expire on February 4, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 4, line 48 skipping to change at page 4, line 48
survey of the methods that can be used to locate a Conference Control survey of the methods that can be used to locate a Conference Control
Server is provided in Section 7, whereas Section 8 discusses Server is provided in Section 7, whereas Section 8 discusses
potential approaches to notifications management. CCMP transport potential approaches to notifications management. CCMP transport
over HTTP is highlighted in Section 9. Security considerations are over HTTP is highlighted in Section 9. Security considerations are
presented in Section 10. Finally, Section 11 provides the XML presented in Section 10. Finally, Section 11 provides the XML
schema. schema.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
In additon to the terms defined in the Framework for Centralized In additon to the terms defined in the Framework for Centralized
Conferencing [RFC5239], this document uses the following terms and Conferencing [RFC5239], this document uses the following terms and
acronyms: acronyms:
XCON aware client: An XCON conferencing system client which is able XCON aware client: An XCON conferencing system client which is able
to issue CCMP requests. to issue CCMP requests.
skipping to change at page 18, line 35 skipping to change at page 18, line 35
11. extendedRequest/extendedResponse 11. extendedRequest/extendedResponse
12. optionsRequest/optionsResponse 12. optionsRequest/optionsResponse
These CCMP request/response pairs use the fundamental CCMP operations These CCMP request/response pairs use the fundamental CCMP operations
as defined in Section 4.1 to manipulate the conference data. These as defined in Section 4.1 to manipulate the conference data. These
request/response pairs are included in an IANA registry as defined in request/response pairs are included in an IANA registry as defined in
Section 12.5. Table 1 summarizes the remaining CCMP operations and Section 12.5. Table 1 summarizes the remaining CCMP operations and
corresponding actions that are valid for a specific CCMP request corresponding actions that are valid for a specific CCMP request
type, noting that neither the blueprintsRequest/blueprintsResponse type, noting that neither the blueprintsRequest/blueprintsResponse
nor confsRequest/confsResponse require an "operation" parameter. The nor confsRequest/confsResponse require an "operation" parameter. An
corresponding response MUST contain the same operation. Note that entity MUST support the response message for each of the request
some entries are labeled "N/A" indicating the operation is invalid messages that are supported. The corresponding response message MUST
for that request type. In the case of an "N/A*", the operation MAY contain the same operation. Note that some entries are labeled "N/A"
be allowed for specific privileged users or system administrators, indicating the operation is invalid for that request type. In the
but is not part of the functionality included in this document. 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 20, line 4 skipping to change at page 20, line 4
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByRef | Gets | Creates | Changes | Deletes | | sidebarByRef | Gets | Creates | Changes | Deletes |
| Request | sidebar- | sidebar- | sidebar- | sidebar- | | Request | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-ref | by-ref | by-ref | by-ref | | | by-ref | by-ref | by-ref | by-ref |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 1: Request Type Operation Specific Processing Table 1: Request Type Operation Specific Processing
(**): These operations are not allowed for a usersRequest message, (**): These operations are not allowed for a usersRequest message,
since the <users> section, which is the target element of such a since the <users> section, which is the target element of such a
request, is created and removed in conjuntcion with, respectively, request, is created and removed in conjunction with, respectively,
the creation and deletion of the associated conference document. the creation and deletion of the associated conference document.
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. If a response messages are detailed in the subsequent sections. If a
skipping to change at page 47, line 48 skipping to change at page 47, line 48
o <description> (OPTIONAL): human readable information about the o <description> (OPTIONAL): human readable information about the
related message related message
The only parameter needed in the optionsRequest is the sender The only parameter needed in the optionsRequest is the sender
confUserID, which is mirrored in the homologous parameter of the confUserID, which is mirrored in the homologous parameter of the
corresponding optionsResponse. corresponding optionsResponse.
The CCMP server MUST include the <standard-message-list> containing The CCMP server MUST include the <standard-message-list> containing
at least one <operation> element in the optionsResponse, since a CCMP at least one <operation> element in the optionsResponse, since a CCMP
server is required to be able to handle at least one of the standard server is REQUIRED to be able to handle both the request and response
messages for at least one of the operations. messages for at least one of the operations.
<!-- optionsRequest --> <!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type"> <xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 77, line 37 skipping to change at page 77, line 37
is intended that a conference server can easily be built using an is intended that a conference server can easily be built using an
HTTP server with extensibility mechanisms, and that a conferencing HTTP server with extensibility mechanisms, and that a conferencing
client can trivially use existing HTTP libraries. This subset of client can trivially use existing HTTP libraries. This subset of
requirements helps implementors avoid ambiguity with the many options requirements helps implementors avoid ambiguity with the many options
the full HTTP protocol offers. the full HTTP protocol offers.
Support of HTTP authentication [RFC2617] and cookies [RFC6265] is Support of HTTP authentication [RFC2617] and cookies [RFC6265] is
OPTIONAL for a conferencing client that conforms to this OPTIONAL for a conferencing client that conforms to this
specification. These mechanism are unnecessary because CCMP requests specification. These mechanism are unnecessary because CCMP requests
carry their own authentication information (in the "subject" field; carry their own authentication information (in the "subject" field;
see Section 5.1). see Section 5.1). A conferencing client SHOULD include support for
HTTP proxy authentication.
A CCMP request is carried in the body of an HTTP POST request. The A CCMP request is carried in the body of an HTTP POST request. The
conferencing client MUST include a Host header in the request. conferencing client MUST include a Host header in the request.
The MIME type of CCMP request and response bodies is "application/ The MIME type of CCMP request and response bodies is "application/
ccmp+xml". The conference server and conferencing client MUST ccmp+xml". The conference server and conferencing client MUST
provide this value in the HTTP Content-Type and Accept header fields. provide this value in the HTTP Content-Type and Accept header fields.
If the conference server does not receive the appropriate Content- If the conference server does not receive the appropriate Content-
Type and Accept header fields, the conference server SHOULD fail the Type and Accept header fields, the conference server SHOULD fail the
request, returning a 406 (not acceptable) response. CCMP responses request, returning a 406 (not acceptable) response. CCMP responses
skipping to change at page 92, line 36 skipping to change at page 92, line 36
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintResponseType --> <!-- blueprintResponseType -->
<xs:element name="blueprintResponse" type="blueprintResponseType"/> <xs:element name="blueprintResponse" type="blueprintResponseType"/>
<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>
<!-- confsResponse --> <!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type"> <xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
skipping to change at page 110, line 28 skipping to change at page 110, line 28
[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-31 Conferencing (XCON)", draft-ietf-xcon-common-data-model-31
(work in progress), June 2011. (work in progress), June 2011.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Mendelsohn, N., Thompson, H., Maloney, M., and D. Beech, Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
14.2. Informative References 14.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
skipping to change at page 111, line 27 skipping to change at page 111, line 27
May 2008. May 2008.
[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.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Moreau, J., Gudgin, M., Hadley, M., Nielsen, H., and N. Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and H.
Mendelsohn, "SOAP Version 1.2 Part 1: Messaging Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework",
Framework", World Wide Web Consortium FirstEdition REC- World Wide Web Consortium FirstEdition REC-soap12-part1-
soap12-part1-20030624, June 2003, 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]
Moreau, J., Mendelsohn, N., Nielsen, H., Hadley, M., and Mendelsohn, N., Hadley, M., Moreau, J., Gudgin, M., and H.
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Nielsen, "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: Evaluation of other protocol models and Appendix A. Appendix A: Evaluation of other protocol models and
transports considered for CCMP transports considered for CCMP
This section provides some background as to the selection of HTTP as This section provides some background as to the selection of HTTP as
the transport for the CCMP requests/responses. In addition to HTTP, the transport for the CCMP requests/responses. In addition to HTTP,
the operations on the objects can be implemented in at least two the operations on the objects can be implemented in at least two
skipping to change at page 114, line 13 skipping to change at page 114, line 13
conference object identified by the XCON-URI. conference object identified by the XCON-URI.
Delete: HTTP DELETE could be used to delete conference objects and Delete: HTTP DELETE could be used to delete conference objects and
parameters within conference objects identified by the XCON-URI. parameters within conference objects identified by the XCON-URI.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Polycom Polycom
TX TX
US USA
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
Simon Pietro Romano Simon Pietro Romano
University of Napoli University of Napoli
 End of changes. 16 change blocks. 
25 lines changed or deleted 28 lines changed or added

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