draft-ietf-xcon-ccmp-09.txt   draft-ietf-xcon-ccmp-10.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Polycom
Intended status: Standards Track C. Boulton Intended status: Standards Track C. Boulton
Expires: January 3, 2011 NS-Technologies Expires: January 13, 2011 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
July 2, 2010 July 12, 2010
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-09 draft-ietf-xcon-ccmp-10
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 3, 2011. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21 5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21
5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22 5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22
5.3.4. confRequest and confResponse . . . . . . . . . . . . 24 5.3.4. confRequest and confResponse . . . . . . . . . . . . 24
5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28
5.3.6. userRequest and userResponse . . . . . . . . . . . . 30 5.3.6. userRequest and userResponse . . . . . . . . . . . . 30
5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35
5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 36 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 36
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39
5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41
5.3.11. extendedRequest and extendedResponse . . . . . . . . 44 5.3.11. extendedRequest and extendedResponse . . . . . . . . 44
5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 45
5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49
6. A complete example of the CCMP in action . . . . . . . . . . 52 6. A complete example of the CCMP in action . . . . . . . . . . 52
6.1. Alice retrieves the available blueprints . . . . . . . . 53 6.1. Alice retrieves the available blueprints . . . . . . . . 53
6.2. Alice gets detailed information about a specific 6.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3. Alice creates a new conference through a cloning 6.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 57 operation . . . . . . . . . . . . . . . . . . . . . . . . 57
6.4. Alice updates conference information . . . . . . . . . . 60 6.4. Alice updates conference information . . . . . . . . . . 60
6.5. Alice inserts a list of users in the conference object . 62 6.5. Alice inserts a list of users in the conference object . 62
6.6. Alice joins the conference . . . . . . . . . . . . . . . 63 6.6. Alice joins the conference . . . . . . . . . . . . . . . 63
skipping to change at page 3, line 17 skipping to change at page 3, line 17
8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77
10.1. Assuring that the Proper Conferencing Server has been 10.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 78 contacted . . . . . . . . . . . . . . . . . . . . . . . . 78
10.2. User Authentication and Authorization . . . . . . . . . . 78 10.2. User Authentication and Authorization . . . . . . . . . . 78
10.3. Security and Privacy of Identity . . . . . . . . . . . . 79 10.3. Security and Privacy of Identity . . . . . . . . . . . . 79
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 98 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 99
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 99 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 100
12.4.1. Registration of a Conference Control Server 12.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 100 Application Service Tag . . . . . . . . . . . . . . . 100
12.4.2. Registration of a Conference Control Server 12.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 100 Application Protocol Tag for CCMP . . . . . . . . . . 100
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 100 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 101
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 100 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 101
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 103 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104
14. Changes since last Version . . . . . . . . . . . . . . . . . 103 14. Changes since last Version . . . . . . . . . . . . . . . . . 104
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 105
15.1. Normative References . . . . . . . . . . . . . . . . . . 104 15.1. Normative References . . . . . . . . . . . . . . . . . . 105
15.2. Informative References . . . . . . . . . . . . . . . . . 105 15.2. Informative References . . . . . . . . . . . . . . . . . 106
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . 106 considered for CCMP . . . . . . . . . . . . . . . . 106
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 107 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 108
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108
1. Introduction 1. Introduction
The Framework for Centralized Conferencing [RFC5239] (XCON Framework) The Framework for Centralized Conferencing [RFC5239] (XCON Framework)
defines a signaling-agnostic framework, naming conventions and defines a signaling-agnostic framework, naming conventions and
logical entities required for building advanced conferencing systems. logical entities required for building advanced conferencing systems.
The XCON Framework introduces the conference object as a logical The XCON Framework introduces the conference object as a logical
representation of a conference instance, representing the current representation of a conference instance, representing the current
state and capabilities of a conference. state and capabilities of a conference.
skipping to change at page 32, line 34 skipping to change at page 32, line 34
Figure 11: userRequest and userResponse in the absence of an xcon- Figure 11: userRequest and userResponse in the absence of an xcon-
userid userid
o Conferencing client is unaware of the XCON-USERID of a third user: o Conferencing client is unaware of the XCON-USERID of a third user:
In this case, the XCON-USERID in the request "confUserID" is the In this case, the XCON-USERID in the request "confUserID" is the
sender's one and the "entity" attribute of the attached userInfo sender's one and the "entity" attribute of the attached userInfo
is filled with the pre-defined fake value is filled with the pre-defined fake value
"xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the
third user MUST be returned to the client issuing the request in third user MUST be returned to the client issuing the request in
the "entity" attribute of the response "userInfo" parameter, if the "entity" attribute of the response "userInfo" parameter, if
the "response-code" is "200". [RP] This scenario is intended to the "response-code" is "200". This scenario is intended to
support both the case where a brand new conferencing system user support both the case where a brand new conferencing system user
is added to a conference by a third party (i.e. a user who is not is added to a conference by a third party (i.e. a user who is not
yet provided with an XCON-USERID) and the case where the CCMP yet provided with an XCON-USERID) and the case where the CCMP
client issuing the request does not know the to-be-added user's client issuing the request does not know the to-be-added user's
XCON-USERID (which means such an identifier could already exist on XCON-USERID (which means such an identifier could already exist on
the server's side for that user). In this last case, the the server's side for that user). In this last case, the
conferencing server is in charge of avoiding XCON-URI duplicates conferencing server is in charge of avoiding XCON-URI duplicates
for the same conferencing client, looking at key fields in the for the same conferencing client, looking at key fields in the
request provided "userInfo" parameter, such as the signalling URI: request provided "userInfo" parameter, such as the signalling URI:
if the joining user is a brand new one, then the generation of a if the joining user is a brand new one, then the generation of a
skipping to change at page 40, line 7 skipping to change at page 40, line 7
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.10. A
"sidebarsByRefResponse" message MUST carry back to the client a "sidebarsByRefResponse" message MUST carry back to the client a
"version" element related to the current version of the main "version" element related to the current version of the main
conference object (i.e. the one whose identifier is contained in the conference object (i.e. the one whose identifier is contained in the
"confObjId" field of the request) to which the sidebars in question "confObjId" field of the request) to which the sidebars in question
are associated. are associated.
<!-- sidebarsByRefRequest --> <!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type"> <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByRefRequest"/> <xs:element ref="sidebarsByRefRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefRequestType --> <!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest" <xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" /> type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType"> <xs:complexType name="sidebarsByRefRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="xpathFilter" type="xs:string" minOccurs="0"/> <xs:element name="xpathFilter"
<xs:any namespace="##other" processContents="lax" type="xs:string" minOccurs="0"/>
minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax"
</xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByRefResponse --> <!-- sidebarsByRefResponse -->
<xs:complexType name="ccmp-sidebarsByref-response-message-type"> <xs:complexType name="ccmp-sidebarsByref-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="sidebarsByRefResponse"/> <xs:element ref="sidebarsByRefResponse"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefResponseType --> <!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse" <xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" /> type="sidebarsByRefResponseType" />
<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 15: Structure of the sidebarsByRefRequest and
sidebarsByRefResponse messages sidebarsByRefResponse messages
5.3.10. sidebarByRefRequest and sidebarByRefResponse 5.3.10. sidebarByRefRequest and sidebarByRefResponse
A sidebarByRefRequest message MUST contain the "operation" parameter A sidebarByRefRequest message MUST contain the "operation" parameter
which discriminates among retrieval, creation, modification and which discriminates among retrieval, creation, modification and
deletion of a specific sidebar. The other required parameters depend deletion of a specific sidebar. The other required parameters depend
upon the type of operation. upon the type of operation.
skipping to change at page 45, line 20 skipping to change at page 45, line 4
<xs:sequence> <xs:sequence>
<xs:element ref="extendedRequest"/> <xs:element ref="extendedRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- extendedRequestType --> <!-- extendedRequestType -->
<xs:element name="extendedRequest" type="extendedRequestType"/> <xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="extendedRequestType"> <xs:complexType name="extendedRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="1"/> <xs:element name="extensionName"
<xs:any namespace="##other" processContents="lax" minOccurs="0" type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded" /> maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- extendedResponse --> <!-- extendedResponse -->
<xs:complexType name="ccmp-extended-response-message-type"> <xs:complexType name="ccmp-extended-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>
skipping to change at page 45, line 47 skipping to change at page 45, line 32
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- extendedResponseType --> <!-- extendedResponseType -->
<xs:element name="extendedResponse" type="extendedResponseType"/> <xs:element name="extendedResponse" type="extendedResponseType"/>
<xs:complexType name="extendedResponseType"> <xs:complexType name="extendedResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="1"/> <xs:element name="extensionName"
<xs:any namespace="##other" processContents="lax" minOccurs="0" type="xs:string"
maxOccurs="unbounded" /> minOccurs="1"/>
<xs:any namespace="##other"
processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 17: Structure of the extendedRequest and extendedResponse Figure 17: Structure of the extendedRequest and extendedResponse
messages messages
5.3.12. optionsRequest and optionsResponse 5.3.12. optionsRequest and optionsResponse
An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e. An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e.
it does not represent a specialization of the general CCMP request. it does not represent a specialization of the general CCMP request.
It allows a CCMP client to become aware of CCMP server capabilities It allows a CCMP client to become aware of CCMP server capabilities
in terms of CCMP supported messages. in terms of CCMP supported messages.
skipping to change at page 46, line 51 skipping to change at page 46, line 42
messages further than those explicitly defined in the CCMP messages further than those explicitly defined in the CCMP
specification. specification.
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 <standard-message-list> MUST appear in the optionsResponse and The <standard-message-list> MUST appear in the optionsResponse and
MUST not be void, since a CCMP server MUST be able to handle at least MUST NOT be void, since a CCMP server MUST be able to handle at least
one of the standard messages in at least one of the envisioned one of the standard messages in at least one of the envisioned
operations, i.e. the aforementioned list MUST carry at least one operations, i.e. the aforementioned list MUST carry at least one
<standard-message> containing at least one <operation> element. <standard-message> containing at least one <operation> element.
<!-- optionsRequest --> <!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponse -->
<xs:complexType name="ccmp-options-response-message-type"> <xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-request-message-type"/>
<xs:sequence> </xs:complexContent>
<xs:element ref="optionsResponse"/> </xs:complexType>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponseType --> <!-- optionsResponse -->
<xs:element name="optionsResponse" <xs:complexType name="ccmp-options-response-message-type">
type="optionsResponseType" /> <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:complexType name="optionsResponseType"> <!-- optionsResponseType -->
<xs:sequence>
<xs:element name="options"
type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- options-type --> <xs:element name="optionsResponse"
type="optionsResponseType" />
<xs:complexType name="options-type"> <xs:complexType name="optionsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="standard-message-list" <xs:element name="options"
type="standard-message-list-type" minOccurs="1"/> 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:element name="extended-message-list" <!-- options-type -->
type="extended-message-list-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-list-type --> <xs:complexType name="options-type">
<xs:sequence>
<xs:element name="standard-message-list"
type="standard-message-list-type"
minOccurs="1"/>
<xs:element name="extended-message-list"
type="extended-message-list-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-list-type -->
<xs:complexType name="standard-message-list-type"> <xs:complexType name="standard-message-list-type">
<xs:sequence> <xs:sequence>
<xs:element name="standard-message" type="standard-message-type" minOccurs="1" maxOccurs="10"/> <xs:element name="standard-message"
<xs:any namespace="##other" processContents="lax" type="standard-message-type"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="1" maxOccurs="10"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
<xs:anyAttribute namespace="##any" processContents="lax"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:complexType> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-type --> <!-- standard-message-type -->
<xs:complexType name="standard-message-type"> <xs:complexType name="standard-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="name" type="standard-message-name-type" minOccurs="1"/> <xs:element name="name"
<xs:element name="operations" type="operations-type" minOccurs="0"/> type="standard-message-name-type"
<xs:element name="schema-def" type="xs:string" minOccurs="0"/> minOccurs="1"/>
<xs:element name="description" type="xs:string" minOccurs="0"/> <xs:element name="operations"
<xs:any namespace="##other" processContents="lax" type="operations-type"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0"/>
</xs:sequence> <xs:element name="schema-def"
<xs:anyAttribute namespace="##any" processContents="lax"/> type="xs:string" minOccurs="0"/>
</xs:complexType> <xs:element name="description"
type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-name-type --> <!-- standard-message-name-type -->
<xs:simpleType name="standard-message-name-type"> <xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/> <xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/> <xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/> <xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/> <xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/> <xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/> <xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/> <xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/> <xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/> <xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/> <xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- operations-type --> <!-- operations-type -->
<xs:complexType name="operations-type"> <xs:complexType name="operations-type">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operation-type" <xs:element name="operation" type="operation-type"
minOccurs="1" maxOccurs="4"/> minOccurs="1" maxOccurs="4"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 18: Structure of the optionsRequest and optionsResponse Figure 18: Structure of the optionsRequest and optionsResponse
messages 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.
skipping to change at page 82, line 9 skipping to change at page 82, line 9
</xs:complexType> </xs:complexType>
<!-- ccmp-response-message-type --> <!-- ccmp-response-message-type -->
<xs:complexType abstract="true" name="ccmp-response-message-type"> <xs:complexType abstract="true" name="ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="confUserID" type="xs:string" <xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" /> minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType" minOccurs="0" <xs:element name="operation" type="operationType"
minOccurs="0"
maxOccurs="1" /> maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1" <xs:element ref="response-code" minOccurs="1"
maxOccurs="1" /> maxOccurs="1" />
<xs:element name="response-string" type="xs:string" <xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger" <xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
skipping to change at page 88, line 16 skipping to change at page 88, line 20
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- extendedRequestType --> <!-- extendedRequestType -->
<xs:element name="extendedRequest" type="extendedRequestType"/> <xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="extendedRequestType"> <xs:complexType name="extendedRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="1"/> <xs:element name="extensionName"
type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" <xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" /> maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- 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">
skipping to change at page 94, line 29 skipping to change at page 94, line 33
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- extendedResponseType --> <!-- extendedResponseType -->
<xs:element name="extendedResponse" type="extendedResponseType"/> <xs:element name="extendedResponse" type="extendedResponseType"/>
<xs:complexType name="extendedResponseType"> <xs:complexType name="extendedResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="1"/> <xs:element name="extensionName"
<xs:any namespace="##other" processContents="lax" minOccurs="0" type="xs:string" minOccurs="1"/>
maxOccurs="unbounded" /> <xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- optionsResponse --> <!-- optionsResponse -->
<xs:complexType name="ccmp-options-response-message-type"> <xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="optionsResponse"/> <xs:element ref="optionsResponse"/>
skipping to change at page 95, line 46 skipping to change at page 96, line 4
<!-- subject-type --> <!-- subject-type -->
<xs:complexType name="subject-type"> <xs:complexType name="subject-type">
<xs:sequence> <xs:sequence>
<xs:element name="username" type="xs:string" <xs:element name="username" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string" <xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- options-type --> <!-- options-type -->
<xs:complexType name="options-type"> <xs:complexType name="options-type">
<xs:sequence> <xs:sequence>
<xs:element name="standard-message-list" type="standard-message-list-type" minOccurs="1"/> <xs:element name="standard-message-list"
<xs:element name="extended-message-list" type="extended-message-list-type" minOccurs="0"/> 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" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- standard-message-list-type --> <!-- standard-message-list-type -->
<xs:complexType name="standard-message-list-type"> <xs:complexType name="standard-message-list-type">
<xs:sequence> <xs:sequence>
<xs:element name="standard-message" type="standard-message-type" minOccurs="1" maxOccurs="10"/> <xs:element name="standard-message"
type="standard-message-type"
minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- standard-message-type --> <!-- standard-message-type -->
<xs:complexType name="standard-message-type"> <xs:complexType name="standard-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="name" type="standard-message-name-type" minOccurs="1"/> <xs:element name="name"
<xs:element name="operations" type="operations-type" minOccurs="0"/> type="standard-message-name-type"
minOccurs="1"/>
<xs:element name="operations"
type="operations-type"
minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" minOccurs="0"/> <xs:element name="schema-def" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/> <xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- standard-message-name-type --> <!-- standard-message-name-type -->
skipping to change at page 97, line 22 skipping to change at page 97, line 38
<xs:element name="operation" type="operation-type" <xs:element name="operation" type="operation-type"
minOccurs="1" maxOccurs="4"/> minOccurs="1" maxOccurs="4"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- extended-message-list-type --> <!-- extended-message-list-type -->
<xs:complexType name="extended-message-list-type"> <xs:complexType name="extended-message-list-type">
<xs:sequence> <xs:sequence>
<xs:element name="extended-message" type="extended-message-type" minOccurs="0"/> <xs:element name="extended-message"
type="extended-message-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- extended-message-type --> <!-- extended-message-type -->
<xs:complexType name="extended-message-type"> <xs:complexType name="extended-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="name" type="xs:string" /> <xs:element name="name" type="xs:string" />
<xs:element name="operations" type="operations-type" minOccurs="0"/> <xs:element name="operations"
type="operations-type"
minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" /> <xs:element name="schema-def" type="xs:string" />
<xs:element name="description" type="xs:string" minOccurs="0"/> <xs:element name="description"
type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 30 Figure 30
skipping to change at page 98, line 20 skipping to change at page 98, line 36
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
This section registers a new XML namespace, This section registers a new XML namespace,
""urn:ietf:params:xml:ns:xcon:ccmp"". ""urn:ietf:params:xml:ns:xcon:ccmp"".
URI: "urn:ietf:params:xml:ns:xcon:ccmp" URI: "urn:ietf:params:xml:ns:xcon:ccmp"
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Registrant Contact: IETF, XCON working group, (xcon@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.ietf.barnes@gmail.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>CCMP Messages</title> <title>CCMP Messages</title>
</head> </head>
<body> <body>
<h1>Namespace for CCMP Messages</h1> <h1>Namespace for CCMP Messages</h1>
<h2>urn:ietf:params:xml:ns:xcon:ccmp</h2> <h2>urn:ietf:params:xml:ns:xcon:ccmp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
12.2. XML Schema Registration 12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:xcon:ccmp URI: urn:ietf:params:xml:schema:xcon:ccmp
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.ietf.barnes@gmail.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 11 of this document. Section 11 of this document.
12.3. MIME Media Type Registration for 'application/ccmp+xml' 12.3. MIME Media Type Registration for 'application/ccmp+xml'
This section registers the "application/ccmp+xml" MIME type. This section registers the "application/ccmp+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/ccmp+xml Subject: Registration of MIME media type application/ccmp+xml
MIME media type name: application MIME media type name: application
skipping to change at page 99, line 36 skipping to change at page 100, line 17
be considered private and thus should be protected. be considered private and thus should be protected.
Interoperability considerations: None. Interoperability considerations: None.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Centralized Conferencing Applications which use this media type: Centralized Conferencing
control clients and servers. control clients and servers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.ietf.barnes@gmail.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/ccmp+xml. described there also apply to application/ccmp+xml.
12.4. DNS Registrations 12.4. DNS Registrations
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
skipping to change at page 101, line 12 skipping to change at page 101, line 39
The CCMP messages are described in Section 4.1 and defined in the XML The CCMP messages are described in Section 4.1 and defined in the XML
schema in Section 11. The following summarizes the requested schema in Section 11. The following summarizes the requested
registry: registry:
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.ietf.barnes@gmail.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 optionsRequest: Used by a conference control client to query a
conferencing system for its capabilities, in terms of supported conferencing system for its capabilities, in terms of supported
messages (both standard and non-standard). messages (both standard and non-standard).
optionsResponse: The optionsResponse returns a list of CCMP messages optionsResponse: The optionsResponse returns a list of CCMP messages
(both standard and non-standard) supported by the specific (both standard and non-standard) supported by the specific
conference server. 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 102, line 19 skipping to change at page 102, line 47
The following summarizes the requested registry for CCMP Response The following summarizes the requested registry for CCMP Response
codes: codes:
Related Registry: CCMP Response Code Registry Related Registry: CCMP Response Code 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 response codes are allocated Registration/Assignment Procedures: New response codes are allocated
on a first-come/first-serve basis with specification required. on a first-come/first-serve basis with specification required.
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.ietf.barnes@gmail.com).
This section pre-registers the following thirteen initial response This section pre-registers the following thirteen initial response
codes as described above in Section 4.1: codes as described above in Section 4.1:
200: This code indicates that the request was successfully 200: This code indicates that the request was successfully
processed. processed.
409: This code indicates that a requested "update" cannot be 409: This code indicates that a requested "update" cannot be
successfully completed by the server. An example of such successfully completed by the server. An example of such
situation is when the modification of an object cannot be applied situation is when the modification of an object cannot be applied
due to conflicts arising at the server's side (e.g. because the due to conflicts arising at the server's side (e.g. because the
skipping to change at page 105, line 42 skipping to change at page 106, line 22
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
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",
RFC 3966, December 2004.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006. 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]
Barnes, M., Miniero, L., Presta, R., and S. Romano,
"Centralized Conferencing Manipulation Protocol (CCMP)
Call Flow Examples", draft-ietf-xcon-examples-04 (work in
progress), April 2010.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Hadley, M., Moreau, J., Nielsen, H., and N. Nielsen, H., Gudgin, M., Hadley, M., 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., Moreau, J., Nielsen, H., Gudgin, M., and Mendelsohn, N., Nielsen, H., Moreau, J., Hadley, M., and
M. Hadley, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Gudgin, "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
skipping to change at page 108, line 32 skipping to change at page 109, line 8
Change: Either HTTP PATCH or HTTP POST could be used to change the Change: Either HTTP PATCH or HTTP POST could be used to change the
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
Nortel Polycom
TX
US
Email: mary.barnes@nortel.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
Via Claudio 21 Via Claudio 21
Napoli 80125 Napoli 80125
 End of changes. 68 change blocks. 
186 lines changed or deleted 216 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/