draft-ietf-xcon-ccmp-11.txt		draft-ietf-xcon-ccmp-12.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: April 29, 2011 NS-Technologies		Expires: August 20, 2011 NS-Technologies
	S P. Romano		S P. Romano
	University of Napoli		University of Napoli
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	October 26, 2010		February 16, 2011
	Centralized Conferencing Manipulation Protocol		Centralized Conferencing Manipulation Protocol
	draft-ietf-xcon-ccmp-11		draft-ietf-xcon-ccmp-12
	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 April 29, 2011.		This Internet-Draft will expire on August 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
	3. XCON Conference Control System Architecture . . . . . . . . . 5		3. XCON Conference Control System Architecture . . . . . . . . . 5
	3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7		3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7
	3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7		3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9		4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9
	4.2. Implementation Approach . . . . . . . . . . . . . . . . . 11		4.2. Data Management . . . . . . . . . . . . . . . . . . . . . 10
	5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 12		4.3. Data Model Compliance . . . . . . . . . . . . . . . . . . 11
	5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12		4.4. Implementation Approach . . . . . . . . . . . . . . . . . 12
	5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14		5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16		5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 13
	5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19		5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 15
	5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21		5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 17
	5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22		5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 20
	5.3.4. confRequest and confResponse . . . . . . . . . . . . 24		5.3.2. confsRequest and confsResponse . . . . . . . . . . . 22
	5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28		5.3.3. blueprintRequest and blueprintResponse . . . . . . . 23
	5.3.6. userRequest and userResponse . . . . . . . . . . . . 30		5.3.4. confRequest and confResponse . . . . . . . . . . . . 25
	5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35		5.3.5. usersRequest and usersResponse . . . . . . . . . . . 29
	5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 37		5.3.6. userRequest and userResponse . . . . . . . . . . . . 31
	5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39		5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36
	5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41		5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 38
	5.3.11. extendedRequest and extendedResponse . . . . . . . . 44		5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 40
	5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46		5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42
	5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49		5.3.11. extendedRequest and extendedResponse . . . . . . . . 45
	6. A complete example of the CCMP in action . . . . . . . . . . 52		5.3.12. optionsRequest and optionsResponse . . . . . . . . . 47
	6.1. Alice retrieves the available blueprints . . . . . . . . 53		5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 50
			6. A complete example of the CCMP in action . . . . . . . . . . 53
			6.1. Alice retrieves the available blueprints . . . . . . . . 54
	6.2. Alice gets detailed information about a specific		6.2. Alice gets detailed information about a specific
	blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55		blueprint . . . . . . . . . . . . . . . . . . . . . . . . 57
	6.3. Alice creates a new conference through a cloning		6.3. Alice creates a new conference through a cloning
	operation . . . . . . . . . . . . . . . . . . . . . . . . 57		operation . . . . . . . . . . . . . . . . . . . . . . . . 59
	6.4. Alice updates conference information . . . . . . . . . . 60		6.4. Alice updates conference information . . . . . . . . . . 61
	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 . 63
	6.6. Alice joins the conference . . . . . . . . . . . . . . . 63		6.6. Alice joins the conference . . . . . . . . . . . . . . . 65
	6.7. Alice adds a new user to the conference . . . . . . . . . 65		6.7. Alice adds a new user to the conference . . . . . . . . . 67
	6.8. Alice asks for the CCMP server capabilities . . . . . . . 68		6.8. Alice asks for the CCMP server capabilities . . . . . . . 69
	6.9. Alice exploits a CCMP server extension . . . . . . . . . 70		6.9. Alice exploits a CCMP server extension . . . . . . . . . 72
	7. Locating a Conference Control Server . . . . . . . . . . . . 73		7. Locating a Conference Control Server . . . . . . . . . . . . 74
	8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74		8. Managing Notifications . . . . . . . . . . . . . . . . . . . 76
	9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75		9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 77
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 77		10. Security Considerations . . . . . . . . . . . . . . . . . . . 79
	10.1. Assuring that the Proper Conferencing Server has been		10.1. Assuring that the Proper Conferencing Server has been
	contacted . . . . . . . . . . . . . . . . . . . . . . . . 78		contacted . . . . . . . . . . . . . . . . . . . . . . . . 80
	10.2. User Authentication and Authorization . . . . . . . . . . 79		10.2. User Authentication and Authorization . . . . . . . . . . 80
	10.3. Security and Privacy of Identity . . . . . . . . . . . . 80		10.3. Security and Privacy of Identity . . . . . . . . . . . . 81
	11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80		11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 82
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 100
	12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98		12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 100
	12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 99		12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 101
	12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99		12.3. MIME Media Type Registration for 'application/ccmp+xml' . 101
	12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 100		12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 102
	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 . . . . . . . . . . . . . . . 103
	12.4.2. Registration of a Conference Control Server		12.4.2. Registration of a Conference Control Server
	Application Protocol Tag for CCMP . . . . . . . . . . 101		Application Protocol Tag for CCMP . . . . . . . . . . 103
	12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 101		12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 103
	12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 101		12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 103
	12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102		12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 105
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107
	14. Changes since last Version . . . . . . . . . . . . . . . . . 104		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 107
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 105		14.1. Normative References . . . . . . . . . . . . . . . . . . 107
	15.1. Normative References . . . . . . . . . . . . . . . . . . 105		14.2. Informative References . . . . . . . . . . . . . . . . . 108
	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 . . . . . . . . . . . . . . . . 107		considered for CCMP . . . . . . . . . . . . . . . . 109
	A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107		A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 109
	A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 108		A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 110
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111
	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 9, line 12		skipping to change at page 9, line 12
	specifically conceived to provide users with the necessary means for		specifically conceived to provide users with the necessary means for
	the creation, retrieval, modification and deletion of conference		the creation, retrieval, modification and deletion of conference
	objects. CCMP is also state-less, which means implementations can		objects. CCMP is also state-less, which means implementations can
	safely handle transactions independently from each other.		safely handle transactions independently from each other.
	Conference-related information is encapsulated into CCMP messages in		Conference-related information is encapsulated into CCMP messages in
	the form of XML documents or XML document fragments compliant with		the form of XML documents or XML document fragments compliant with
	the XCON data model representation.		the XCON data model representation.
	Section 4.1 specifies the basic operations that can create, retrieve,		Section 4.1 specifies the basic operations that can create, retrieve,
	modify and delete conference-related information in a centralized		modify and delete conference-related information in a centralized
	conference. The core set of objects manipulated in the CCMP protocol		conference. The core set of objects manipulated in the CCMP includes
	includes conference blueprints, the conference object, users, and		conference blueprints, the conference object, users, and sidebars.
	sidebars.
			Each operation in the protocol model, as summarized in Section 4.1 is
			atomic and either succeeds or fails as a whole. The conference
			server must ensure that the operations are atomic in that the
			operation invoked by a specific conference client completes prior to
			another client's operation on the same conference object. While the
			details for this data locking functionality are out of scope for the
			CCMP protocol specification and are implementation specific for a
			conference server, some core functionality for ensuring the integrity
			of the data is provided by the CCMP as described in Section 4.2.
			While the XML documents that are carried in the CCMP need to comply
			with the XCON data model, there are situations in which the values
			for mandatory elements are unknown by the client. The mechanism for
			ensuring compliance with the data model in these cases is described
			in Section 4.3.
	CCMP has been conceived as completely independent from underlying		CCMP has been conceived as completely independent from underlying
	protocols, which means that there can be different ways to carry CCMP		protocols, which means that there can be different ways to carry CCMP
	messages across the network, from a conferencing client to a		messages across the network, from a conferencing client to a
	conferencing server. The specification recommends the use of HTTP as		conferencing server. The specification recommends the use of HTTP as
	a transport solution, including CCMP requests in HTTP POST messages		a transport solution, including CCMP requests in HTTP POST messages
	and CCMP responses in HTTP 200 OK replies. Implementation details		and CCMP responses in HTTP 200 OK replies. This implementation
	are presented in Section 4.2		approach is further described in Section 4.4.
	4.1. Protocol Operations		4.1. Protocol Operations
	The main operations provided by CCMP belong in four general		The main operations provided by CCMP belong in four general
	categories:		categories:
	create: for the creation of a conference, a conference user, a		create: for the creation of a conference, a conference user, a
	sidebar, or a blueprint.		sidebar, or a blueprint.
	retrieve: to get information about the current state of either a		retrieve: to get information about the current state of either a
	conference object (be it an actual conference or a blueprint, or a		conference object (be it an actual conference or a blueprint, or a
	sidebar) or a conference user. A retrieve operation can also be		sidebar) or a conference user. A retrieve operation can also be
	used to obtain the XCON-URIs of the current conferences (active or		used to obtain the XCON-URIs of the current conferences (active or
	registered) handled by the conferencing server and/or the		registered) handled by the conferencing server and/or the
	available blueprints.		available blueprints.
	update: to modify the current features of a specified conference or		update: to modify the current features of a specified conference or
	conference user.		conference user.
	delete: to remove from the system a conference object or a		delete: to remove from the system a conference object or a
	conference user.		conference user.
	Thus, the main targets of CCMP operations are:		Thus, the main targets of CCMP operations are:
	o conference objects associated with either active or registered		o conference objects associated with either active or registered
	conferences,		conferences,
	o conference objects associated with blueprints,		o conference objects associated with blueprints,
	o conference objects associated with sidebars, both embedded in the		o conference objects associated with sidebars, both embedded in the
	main conference (i.e. <entry> elements in <sidebars-by-value>) and		main conference (i.e. <entry> elements in <sidebars-by-value>) and
	external to it (i.e. whose xcon-uris are included in the <entry>		external to it (i.e. whose xcon-uris are included in the <entry>
	elements of <sidebars-by-ref>),		elements of <sidebars-by-ref>),
	o <user> elements associated with conference users,		o <user> elements associated with conference users,
	o the list of XCON-URIs related to conferences and blueprints		o the list of XCON-URIs related to conferences and blueprints
	available at the server, for which only retrieval operations are		available at the server, for which only retrieval operations are
	allowed.		allowed.
	Each operation in the protocol model is atomic and either succeeds or		4.2. Data Management
	fails as a whole. The conference server must ensure that the
	operations are atomic in that the operation invoked by a specific		In order to ensure the integrity of the data, the conference server
	conference client completes prior to another client's operation on		first checks all the parameters, before making any changes to the
	the same conference object. The details for this data locking		internal representation of the conference object. For example, it
	functionality are out of scope for the CCMP protocol specification		would be undesirable to change the <subject> of the conference, but
	and are implementation specific for a conference server. Thus, the		then detect an invalid URI in one of the <service-uris> and abort the
	conference server first checks all the parameters, before making any		remaining updates. Also, since multiple clients can modify the same
	changes to the internal representation of the conference object. For		conference objects, conference clients should first obtain the
	example, it would be undesirable to change the <subject> of the		current object from the conference server and then update the
	conference, but then detect an invalid URI in one of the <service-		relevant data elements in the conference object prior to invoking a
	uris> and abort the remaining updates. Also, since multiple clients		specific operation on the conference server.
	can modify the same conference objects, conference clients should
	first obtain the current object from the conference server and then		In order to effectively manage modifications to conference data, a
	update the relevant data elements in the conference object prior to		versioning approach is provided by the CCMP. Specifically, each
	invoking a specific operation on the conference server. In order to		conference object is associated with a version number indicating the
	effectively manage modifications to conference data, a versioning		most up to date view of the conference at the server's side. The
	approach is provided by the CCMP. Specifically, each conference		version number is reported to the clients when answering their
	object is associated with a version number indicating the most up to		requests. A client willing to make modifications to a conference
	date view of the conference at the server's side. The version number		object has to send an update message to the server. If the
	is reported to the clients when answering their requests. A client		modifications are all successfully applied, the server sends back to
	willing to make modifications to a conference object has to send an		the client a "200" response which also carries information about the
	update message to the server. If the modifications are all		current server-side version of the modified object. With this
	successfully applied, the server sends back to the client a "200"		approach, a client working on version "X" of a conference object that
	response which also carries information about the current server-side		finds a "200" response with a version number which is "X+1" can be
	version of the modified object. With this approach, a client working		sure that the version it was aware of was the most up to date. On
	on version "X" of a conference object that finds a "200" response		the other hand, if the "200" response contains a version which is at
	with a version number which is "X+1" can be sure that the version it		least "X+2", the client can detect that the object that has been
	was aware of was the most up to date. On the other hand, if the		modified at the server's side was more up to date than the one it was
	"200" response contains a version which is at least "X+2", the client		working upon. This is clearly due to the effect of concurrent
	can detect that the object that has been modified at the server's		modification requests issued by independent clients. Hence, for the
	side was more up to date than the one it was working upon. This is		sake of having available the latest version of the modified object,
	clearly due to the effect of concurrent modification requests issued		the client can send to the conference server a further "retrieve"
	by independent clients. Hence, for the sake of having available the		request. In the case that a copy of the conference object is not
	latest version of the modified object, the client can send to the		returned to the client as part of the update response message, the
	conference server a further "retrieve" request. In the case that a		client can always obtain a copy through an ad-hoc "retrieve" message.
	copy of the conference object is not returned to the client as part
	of the update response message, the client can always obtain a copy
	through an ad-hoc "retrieve" message.
	Based on the above considerations, all CCMP response messages		Based on the above considerations, all CCMP response messages
	containing a conference document (or a fragment of it) MUST contain a		containing a conference document (or a fragment of it) MUST contain a
	"version" parameter. The "version" parameter is not REQUIRED for		"version" parameter. The "version" parameter is not REQUIRED for
	requests, since it represents useless information for the server: as		requests, since it represents useless information for the server: as
	long as the required modifications can be applied to the target		long as the required modifications can be applied to the target
	conference object with no conflicts, the server does not care whether		conference object with no conflicts, the server does not care whether
	the client has stored an up to date view of the information.		the client has stored an up to date view of the information.
	However, a client subscribed to the XCON event package		However, a client subscribed to the XCON event package
	[I-D.ietf-xcon-event-package] notifications about conference object		[I-D.ietf-xcon-event-package] notifications about conference object
	modifications, will always have the most up to date version of that		modifications, will always have the most up to date version of that
	object.		object.
	A final consideration concerns the relation between the CCMP and the		4.3. Data Model Compliance
	main entities it manages, i.e. conference objects. Such objects have
	to be compliant with the XCON data-model, which identifies some
	elements/attributes as mandatory. From the CCMP standpoint this can
	become a problem in cases of client-initiated operations, like the
	creation/update of conference objects. In such cases, not all of the
	mandatory data can be known in advance to the client issuing a CCMP
	request. As an example, a client has no means to know, at the time
	it issues a conference creation request, the XCON-URI that the server
	will assign to the yet-to-be-created conference and hence it is not
	able to appropriately fill with that value the mandatory "entity"
	attribute of the conference document contained in the request. To
	solve this kind of issues, the CCMP will fill all mandatory data
	model fields, for which no value is available at the client at the
	time the request is constructed, with fake values in the form of
	wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental
	index initialized to a value of 1). Upon reception of the mentioned
	kinds of requests, the server will: (i) generate the proper
	identifier(s); (ii) produce a response in which the received fake
	identifier(s) carried in the request has (have) been replaced by the
	newly created one(s). With this approach we maintain compatibility
	with the data model requirements, at the same time allowing for
	client-initiated manipulation of conference objects at the server's
	side (which is, by the way, one of the main goals for which the CCMP
	protocol has been conceived at the outset).
	4.2. Implementation Approach		The XCON data model identifies some elements/attributes as mandatory.
			Since the XML documents carried in the CCMP need to be compliant with
			the XCON data model, there can be a problem in cases of client-
			initiated operations, like the creation/update of conference objects.
			In such cases, not all of the mandatory data can be known in advance
			to the client issuing a CCMP request. As an example, a client has no
			means to know, at the time it issues a conference creation request,
			the XCON-URI that the server will assign to the yet-to-be-created
			conference and hence it is not able to appropriately fill with that
			value the mandatory "entity" attribute of the conference document
			contained in the request. To solve this issue, the CCMP client fills
			all mandatory data model fields, for which no value is available at
			the time the request is constructed, with fake values in the form of
			a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a
			unique numeric index for each data model field for which the value is
			unknown. This form of wildcard string is chosen, rather than the use
			of random unique strings (e.g, FOO_BAR_LA) or non-numeric values for
			X, to simplify processing at the server. The values of
			AUTO_GENERATE_X are only unique within the context of the specific
			request. The fake AUTO_GENERATE_X values MUST be within the value
			part of an attribute/element (e.g., <userinfo entity=
			"xcon-userid:AUTO_GENERATE_1@example.com">).
			When the server receives requests containing values in the form of
			AUTO_GENERATE_X, the server does the following:
			(a) Generates the proper identifier for each instance of
			AUTO_GENERATE_X in the document. If an instance of
			AUTO_GENERATE_X is not within the value part of the attribute/
			element, the server MUST respond with an error of 400 Bad
			Request. In cases where AUTO_GENERATE_X appears only in the
			user part of a URI (i.e., in the case of XCON-USERIDs or XCON-
			URIs), the server needs to ensure that the domain name is one
			that is within the server's domain of responsibility. If the
			domain name is NOT within the server's domain of responsibility,
			then the server MUST return a 500 Server Internal Error. The
			server MUST replace each instance of a specific wildcard field
			(e.g., AUTO_GENERATE_1) with the same identifier. The
			identifiers MUST be unique for each instance of AUTO_GENERATE_X
			within the same XML document received in the request - e.g., the
			value that replaces AUTO_GENERATE_1 MUST NOT be the same as the
			value that replaces AUTO_GENERATE_2. Note that the values that
			replace the instances of AUTO_GENERATE_X are not the same across
			all conference objects - e.g., different values can be used to
			replace AUTO_GENERATE_1 in two different documents.
			(b) Sends a response in which all values of AUTO_GENERATE_X received
			in the request has (have) been replaced by the newly created
			one(s).
			With this approach compatibility with the data model requirements is
			maintained, while allowing for client-initiated manipulation of
			conference objects at the server's side which is one of the main
			goals of the CCMP protocol.
			4.4. Implementation Approach
	There have been a number of different proposals as to the most		There have been a number of different proposals as to the most
	suitable implementation solution for the CCMP. A non-exhaustive		suitable implementation solution for the CCMP. A non-exhaustive
	summary of the most interesting ones is provided in Appendix A. The		summary of the most interesting ones is provided in Appendix A. The
	solution for the CCMP defined in this document is viewed as a good		solution for the CCMP defined in this document is viewed as a good
	compromise amongst the most notable past candidates and is referred		compromise amongst the most notable past candidates and is referred
	to as "HTTP single-verb transport plus CCMP body". With this		to as "HTTP single-verb transport plus CCMP body". With this
	approach, CCMP is able to take advantage of existing HTTP		approach, CCMP is able to take advantage of existing HTTP
	functionality. As with SOAP, the CCMP uses a "single HTTP verb" for		functionality. As with SOAP, the CCMP uses a "single HTTP verb" for
	transport (i.e. a single transaction type for each request/response		transport (i.e. a single transaction type for each request/response
	skipping to change at page 12, line 45		skipping to change at page 13, line 47
	subject: An optional parameter containing username and password of		subject: An optional parameter containing username and password of
	the client registered at the conferencing system. Each user who		the client registered at the conferencing system. Each user who
	subscribes to the conferencing system is assumed to be equipped		subscribes to the conferencing system is assumed to be equipped
	with those credentials and SHOULD enclose them in each CCMP		with those credentials and SHOULD enclose them in each CCMP
	request she issues. These fields can be used to control that the		request she issues. These fields can be used to control that the
	user sending the CCMP request has the authority to perform the		user sending the CCMP request has the authority to perform the
	entailed operation. The same fields can also be exploited to		entailed operation. The same fields can also be exploited to
	carry out other Authorization, Authentication and Accounting (AAA)		carry out other Authorization, Authentication and Accounting (AAA)
	procedures.		procedures.
	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		assigned 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.6.
	confObjID: An optional parameter containing the XCON-URI of the		confObjID: An optional parameter containing the XCON-URI of the
	target conference object.		target conference object.
	operation: An optional parameter refining the type of specialized		operation: An optional parameter refining the type of specialized
	request message. The "operation" parameter is REQUIRED in all		request message. The "operation" parameter is REQUIRED in all
	requests except for the "blueprintsRequest" and "confsRequest"		requests except for the "blueprintsRequest" and "confsRequest"
	specialized messages.		specialized messages.
	conference-password: An optional parameter that MUST be inserted in		conference-password: An optional parameter that MUST be inserted in
	all requests whose target conference object is password-protected		all requests whose target conference object is password-protected
	(as per the <conference-password> element in		(as per the <conference-password> element in
	[I-D.ietf-xcon-common-data-model]).		[I-D.ietf-xcon-common-data-model]).
	specialized request message: This is specialization of the generic		specialized request message: This is specialization of the generic
	request message (e.g., blueprintsRequest), containing parameters		request message (e.g., blueprintsRequest), containing parameters
	that are dependent on the specific request sent to the server. A		that are dependent on the specific request sent to the server. A
	specialized request message MUST be included in the CCMP request		specialized request message MUST be included in the CCMP request
	message. The details for the specialized messages and associated		message. The details for the specialized messages and associated
	parameters are provided in Section 5.3.		parameters are provided in Section 5.3.
	<!-- Definition of CCMP Request -->		<!-- Definition of CCMP Request -->
	<xs:element name="ccmpRequest" type="ccmp-request-type" />		<xs:element name="ccmpRequest" type="ccmp-request-type" />
	skipping to change at page 31, line 30		skipping to change at page 32, line 32
	depending upon the manner in which the user was created:		depending upon the manner in which the user was created:
	o Conferencing client with an XCON-USERID adds itself to the		o Conferencing client with an XCON-USERID adds itself to the
	conference: In this case, the "userInfo" parameter MAY be included		conference: In this case, the "userInfo" parameter MAY be included
	in the userRequest. The "userInfo" parameter MUST contain a		in the userRequest. The "userInfo" parameter MUST contain a
	<user> element (compliant with the XCON data model) and the		<user> element (compliant with the XCON data model) and the
	"entity" attribute MUST be set to a value which represents the		"entity" attribute MUST be set to a value which represents the
	XCON-USERID of the user initiating the request. No additional		XCON-USERID of the user initiating the request. No additional
	parameters beyond those previously described are required in the		parameters beyond those previously described are required in the
	userResponse message, in the case of a "response-code" of "200".		userResponse message, in the case of a "response-code" of "200".
	o Conferencing client acts on behalf of a third user whose XCON-		o Conferencing client acts on behalf of a third user whose XCON-
	USERID is known: in this case, the "userInfo" parameter MUST be		USERID is known: in this case, the "userInfo" parameter MUST be
	included in the userRequest. The "userInfo" parameter MUST		included in the userRequest. The "userInfo" parameter MUST
	contain a <user> element and the "entity" attribute value MUST be		contain a <user> element and the "entity" attribute value MUST be
	set to the XCON-USERID of the third user in question. No		set to the XCON-USERID of the third user in question. No
	additional parameters beyond those previously described are		additional parameters beyond those previously described are
	required in the userResponse message, in the case of a "response-		required in the userResponse message, in the case of a "response-
	code" of "200".		code" of "200".
	o A conferencing client who has no XCON-USERID and who wants to		o A conferencing client who has no XCON-USERID and who wants to
	enter, via CCMP, a conference whose identifier is known. In such		enter, via CCMP, a conference whose identifier is known. In this
	case, a side-effect of the request is that the user is provided		case, a side-effect of the request is that the user is provided
	with a new XCON-USERID (created by the server) carried inside the		with a new XCON-USERID (created by the server) carried inside the
	"confUserID" parameter of the response. This is the only case in		"confUserID" parameter of the response. This is the only case in
	which a CCMP request can be valid though carrying a void		which a CCMP request can be valid though carrying a void
	"confUserID" parameter. A "userInfo" parameter MUST be enclosed		"confUserID" parameter. A "userInfo" parameter MUST be enclosed
	in the request, providing at least a contact URI of the joining		in the request, providing at least a contact URI of the joining
	client, in order to let the focus instigate the signaling phase		client, in order to let the focus instigate the signaling phase
	needed to add her to the conference. The mandatory "entity"		needed to add her to the conference. The mandatory "entity"
	attribute of the "userInfo" parameter in the request is filled		attribute of the "userInfo" parameter in the request MUST be
	with a dummy value recognizable on the server side, so to conform		filled with a fake value with the user part of the XCON-USERID
	to the rules contained in the XCON data model XML schema. The		containing a value of AUTO_GENERATE_X as described in Section 4.3,
	involved messages (userRequest and userResponse) in such case		to conform to the rules contained in the XCON data model XML
			schema. The messages (userRequest and userResponse) in this case
	should look like the following:		should look like the following:
	Request fields:		Request fields:
	confUserID=null;		confUserID=null;
	confObjID=confXYZ;		confObjID=confXYZ;
	operation=create;		operation=create;
	userInfo=		userInfo=
	<userInfo entity="xcon-userid:AUTO_GENERATE@example.com">		<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
	<endpoint entity="sip:GHIL345@example.com">		<endpoint entity="sip:GHIL345@example.com">
	...		...
	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 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 fake value
	"xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the		"xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for
	third user MUST be returned to the client issuing the request in		the third user MUST be returned to the client issuing the request
	the "entity" attribute of the response "userInfo" parameter, if		in the "entity" attribute of the response "userInfo" parameter, if
	the "response-code" is "200". 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:
	skipping to change at page 46, line 21		skipping to change at page 47, line 23
	The "optionsResponse" returns, in the appropriate <options> field, a		The "optionsResponse" returns, in the appropriate <options> field, a
	list of the supported CCMP messages as defined in this specification.		list of the supported CCMP messages as defined in this specification.
	These messages are in the form of a list, <standard-message-list>		These messages are in the form of a list, <standard-message-list>
	including each of the supported messages as reflected by <standard-		including each of the supported messages as reflected by <standard-
	message> elements. The "optionsResponse" message also allows for an		message> elements. The "optionsResponse" message also allows for an
	<extended-message-list>, which is a list of additional message types		<extended-message-list>, which is a list of additional message types
	in the form of <extended-message-list> elements that are currently		in the form of <extended-message-list> elements that are currently
	undefined, to allow for future extensibility. The following		undefined, to allow for future extensibility. The following
	information is provided for both types of messages:		information is provided for both types of messages:
	o <name> (mandatory): in case of standard messages, it can be one of		o <name> (mandatory): in case of standard messages, it can be one of
	the ten standard message names defined in this document (i.e.		the ten standard message names defined in this document (i.e.
	"blueprintsRequest", "confsRequest", etc.). In case of		"blueprintsRequest", "confsRequest", etc.). In case of
	extensions, this element MUST carry the same value of the		extensions, this element MUST carry the same value of the
	<extension-name> inserted in the corresponding extendedRequest/		<extension-name> inserted in the corresponding extendedRequest/
	extendedResponse message pair		extendedResponse message pair
	o <operations> (optional): this field is a list of <operation>		o <operations> (optional): this field is a list of <operation>
	entries, each representing the CRUD operation supported by the		entries, each representing the CRUD operation supported by the
	server for the message. If this optional element is absent, the		server for the message. If this optional element is absent, the
	client SHOULD assume the server is able to handle the entire set		client SHOULD assume the server is able to handle the entire set
	of CRUD operations or, in case of standard messages, all the		of CRUD operations or, in case of standard messages, all the
	operations envisioned for that message in this document.		operations envisioned for that message in this document.
	o <schema-ref> (optional): since all CCMP messages can potentially		o <schema-ref> (optional): since all CCMP messages can potentially
	contain XML elements not envisioned in the CCMP schema (due to the		contain XML elements not envisioned in the CCMP schema (due to the
	presence of <any> elements and attributes), a reference to a		presence of <any> elements and attributes), a reference to a
	proper schema definition specifying such new elements/attributes		proper schema definition specifying such new elements/attributes
	can also be sent back to the clients by means of such field. If		can also be sent back to the clients by means of such field. If
	this element is absent, no new elements are introduced in the		this element is absent, no new elements are introduced in the
	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 CCMP server MUST include the <standard-message-list> containing
	MUST NOT be void, since a CCMP server MUST be able to handle at least		at least one <operation> element in the optionsResponse, since a CCMP
	one of the standard messages in at least one of the envisioned		server is required to be able to handle at least one of the standard
	operations, i.e. the aforementioned list MUST carry at least one		messages for at least one of the operations.
	<standard-message> containing at least one <operation> element.
	<!-- 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>
	<!-- optionsResponse -->		<!-- optionsResponse -->
	skipping to change at page 49, line 13		skipping to change at page 50, line 23
	<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="operationType"
	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
	skipping to change at page 66, line 4		skipping to change at page 67, line 18
	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,
	but has a fake "entity" attribute, "AUTO_GENERATE@example.com" as		but has a fake "entity" attribute, "AUTO_GENERATE_1@example.com" as
	discussed in Section 4, since the XCON-USERID is initially unknown to		discussed in Section 4.3, since the XCON-USERID is initially unknown
	Alice. Thus, the conference server is in charge of generating a new		to Alice. Thus, the conference server is in charge of generating a
	XCON-USERID for the user Alice indicates (i.e, Ciccio), and returning		new XCON-USERID for the user Alice indicates (i.e, Ciccio), and
	it in the "entity" attribute of the "userInfo" parameter carried in		returning it in the "entity" attribute of the "userInfo" parameter
	the response, as well as adding the user to the conference. The		carried in the response, as well as adding the user to the
	picture below shows the transaction.		conference. The picture below shows the transaction.
	Alice adds user "Ciccio" to the conference by issuing a third-party		Alice adds user "Ciccio" to the conference by issuing a third-party
	"userRequest/create" message to the server:		"userRequest/create" message to the server:
	CCMP Client CCMP Server		CCMP Client CCMP Server
	| |		| |
	| CCMP userRequest message |		| CCMP userRequest message |
	| - confUserID: Alice |		| - confUserID: Alice |
	| - confObjID: 8977794 |		| - confObjID: 8977794 |
	| - operation: create |		| - operation: create |
	skipping to change at page 67, line 5		skipping to change at page 68, line 21
	<ccmp:ccmpRequest		<ccmp:ccmpRequest
	xmlns:info="urn:ietf:params:xml:ns:conference-info"		xmlns:info="urn:ietf:params:xml:ns:conference-info"
	xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"		xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
	xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">		xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
	<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:type="ccmp:ccmp-user-request-message-type">		xsi:type="ccmp:ccmp-user-request-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:userRequest>		<ccmp:userRequest>
	<userInfo entity="xcon-userid:AUTO_GENERATE@example.com">		<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
	<info:associated-aors>		<info:associated-aors>
	<info:entry>		<info:entry>
	<info:uri>		<info:uri>
	mailto:Ciccio@example.com		mailto:Ciccio@example.com
	</info:uri>		</info:uri>
	<info:display-text>email</info:display-text>		<info:display-text>email</info:display-text>
	</info:entry>		</info:entry>
	</info:associated-aors>		</info:associated-aors>
	<info:endpoint entity="sip:Ciccio@example.com"/>		<info:endpoint entity="sip:Ciccio@example.com"/>
	</userInfo>		</userInfo>
	skipping to change at page 97, line 40		skipping to change at page 99, line 25
	<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="operationType"
	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"		<xs:element name="extended-message"
	skipping to change at page 101, line 42		skipping to change at page 104, line 7
	CCMP protocol including an initial registry for operation types and		CCMP protocol including an initial registry for operation types and
	response codes.		response codes.
	12.5.1. CCMP Message Types		12.5.1. CCMP Message Types
	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.ietf.barnes@gmail.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
	and/or to request an operation on the conference object as a		and/or to request an operation on the conference object as a
	whole.		whole.
	confResponse: The "confResponse" indicates the result of the		confResponse: The "confResponse" indicates the result of the
	operation on the conference object as a whole.		operation on the conference object as a whole.
	userRequest: The "userRequest" is used to request an operation on		userRequest: The "userRequest" is used to request an operation on
	the "user" element in the conference object.		the "user" element in the conference object.
	userResponse: The "userResponse" indicates the result of the		userResponse: The "userResponse" indicates the result of the
	requested operation on the "user" element in the conference		requested operation on the "user" element in the conference
	object.		object.
	usersRequest This "usersRequest" is used to manipulate the "users"		usersRequest This "usersRequest" is used to manipulate the "users"
	element in the conference object, including parameters such as the		element in the conference object, including parameters such as the
	"allowed-users-list", "join-handling", etc.		"allowed-users-list", "join-handling", etc.
	usersResponse: This "usersResponse" indicates the result of the		usersResponse: This "usersResponse" indicates the result of the
	request to manipulate the "users" element in the conference		request to manipulate the "users" element in the conference
	object.		object.
	sidebarRequest: This "sidebarRequest" is used to retrieve the		sidebarRequest: This "sidebarRequest" is used to retrieve the
	information related to a sidebar or to create, change or delete a		information related to a sidebar or to create, change or delete a
	specific sidebar.		specific sidebar.
	sidebarResponse: This "sidebarResponse" indicates the result of the		sidebarResponse: This "sidebarResponse" indicates the result of the
	sidebarRequest.		sidebarRequest.
	12.5.2. CCMP Response Codes		12.5.2. CCMP Response Codes
	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.ietf.barnes@gmail.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
	client version of the object is an obsolete one and the requested		client version of the object is an obsolete one and the requested
	modifications collide with the up-to-date state of the object		modifications collide with the up-to-date state of the object
	stored at the server).		stored at the server).
	400: This code indicates that the request was badly formed in some		400: This code indicates that the request was badly formed in some
	fashion.		fashion.
	401: This code indicates that the user was not authorized for the		401: This code indicates that the user was not authorized for the
	specific operation on the conference object.		specific operation on the conference object.
	403: This code indicates that the specific operation is not valid		403: This code indicates that the specific operation is not valid
	for the target conference object.		for the target conference object.
	404: This code indicates that the specific conference object was not		404: This code indicates that the specific conference object was not
	found.		found.
	420: This code is returned in answer to a "userRequest/create"		420: This code is returned in answer to a "userRequest/create"
	operation, in the case of a third-party invite, when the		operation, in the case of a third-party invite, when the
	"confUserID" (contained in the "entity" attribute of the		"confUserID" (contained in the "entity" attribute of the
	"userInfo" parameter) of the user to be added is unknown.		"userInfo" parameter) of the user to be added is unknown.
	421: This code is returned in the case of requests in which the		421: This code is returned in the case of requests in which the
	"confUserID" of the sender is invalid.		"confUserID" of the sender is invalid.
	422: This code is returned in response to all requests wishing to		422: This code is returned in response to all requests wishing to
	access/manipulate a password-protected conference object, when the		access/manipulate a password-protected conference object, when the
	"conference-password" parameter contained in the request is wrong.		"conference-password" parameter contained in the request is wrong.
	423: This code is returned in response to all requests wishing to		423: This code is returned in response to all requests wishing to
	access/manipulate a password-protected conference object, when the		access/manipulate a password-protected conference object, when the
	"conference-password" parameter is missing in the request.		"conference-password" parameter is missing in the request.
	424: This code is returned in response whenever the server wants to		424: This code is returned in response whenever the server wants to
	authenticate the requestor through the "subject" parameter and		authenticate the requestor through the "subject" parameter and
	such a parameter is not provided in the request.		such a parameter is not provided in the request.
	425: This code indicates that the conferencing system cannot delete		425: This code indicates that the conferencing system cannot delete
	the specific conference object because it is a parent for another		the specific conference object because it is a parent for another
	conference object.		conference object.
	426: This code indicates that the target conference object cannot be		426: This code indicates that the target conference object cannot be
	changed (e.g., due to policies, roles, privileges, etc.).		changed (e.g., due to policies, roles, privileges, etc.).
	510: This code indicates that the request could not be processed		510: This code indicates that the request could not be processed
	within a reasonable time, with the time specific to a conferencing		within a reasonable time, with the time specific to a conferencing
	system implementation.		system implementation.
	500: This code indicates that the conferencing system experienced		500: This code indicates that the conferencing system experienced
	some sort of internal error.		some sort of internal error.
	501: This code indicates that the specific operation is not		501: This code indicates that the specific operation is not
	implemented on that conferencing system.		implemented on that conferencing system.
	13. Acknowledgments		13. Acknowledgments
	The authors appreciate the feedback provided by Dave Morgan, Pierre		The authors appreciate the feedback provided by Dave Morgan, Pierre
	Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean		Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean
	Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special		Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage and
	thanks go to Roberta Presta for her invaluable contribution to this		Peter Reissner. Special thanks go to Roberta Presta for her
	document. Roberta has worked on the specification of the CCMP		invaluable contribution to this document. Roberta has worked on the
	protocol at the University of Napoli for the preparation of her		specification of the CCMP protocol at the University of Napoli for
	Master thesis. She has also implemented the CCMP prototype used for		the preparation of her Master thesis. She has also implemented the
	the trials and from which the dumps provided in Section 6 have been		CCMP prototype used for the trials and from which the dumps provided
	extracted.		in Section 6 have been extracted.
	14. Changes since last Version
	NOTE TO THE RFC-Editor: Please remove this section prior to
	publication as an RFC.
	The following summarizes the changes between the WG 03 and the 04:
	1. Re-organized document based on feedback from Richard Barnes.
	2. Editorial clarifications and nits, including those identified by
	Richard and Simo Veikkolainen.
	The following summarizes the changes between the WG 07 and the 08:
	1. Added a new "optionsRequest" message (and related
	"optionsResponse" message) to the list of CCMP messages.
	2. Clarified discussion about notifications management, by
	clarifying they are out of the scope of the present document, but
	at the same time providing some pointers to potential ways for
	implementing them.
	3. Clarified discussion about policies in XCON, by clarifying they
	are out of the scope of the present document, but at the same
	time providing some pointers to potential ways for implementing
	them.
	4. Corrected minor typos in the schema.
	5. Corrected schema definitions which brought to Unique Particle
	Attribution exceptions.
	6. Added the newly defined "optionsRequest" and "optionsResponse"
	messages to the schema.
	7. Misc editorial nits...
	The following summarizes the changes between the WG 08 and the 09:
	1. Added a section on the extendedRequest/extendedResponse message
	pair.
	2. Added a section on the optionsRequest/optionsResponse message
	pair.
	3. Added an example sub-section about the use of the optionsRequest/
	optionsResponse message pair.
	4. Added an example sub-section about the use of the
	extendedRequest/extendedResponse message pair.
	5. Updated the schema in order to reflect the latest modifications
	and add-ons.
	6. Misc editorial nits...
	15. References		14. References
	15.1. Normative References		14.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	skipping to change at page 106, line 11		skipping to change at page 108, line 6
	[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-20		Conferencing (XCON)", draft-ietf-xcon-common-data-model-23
	(work in progress), October 2010.		(work in progress), February 2011.
	15.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
	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,
	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,
	skipping to change at page 106, line 42		skipping to change at page 108, line 37
	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.
	[W3C.REC-soap12-part1-20030624]		[W3C.REC-soap12-part1-20030624]
	Popescu, V., Smith, V., and B. Pandit, "SOAP Version 1.2		Gudgin, M., Mendelsohn, N., Moreau, J., Nielsen, H., and
	Part 1: Messaging Framework", World Wide Web Consortium		M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
	FirstEdition REC-soap12-part1-20030624, June 2003,		World Wide Web Consortium FirstEdition REC-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]
	Popescu, V., Smith, V., and B. Pandit, "SOAP Version 1.2		Mendelsohn, N., Hadley, M., Gudgin, M., Moreau, J., and H.
	Part 2: Adjuncts", World Wide Web Consortium		Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
	FirstEdition REC-soap12-part2-20030624, June 2003,		Web Consortium FirstEdition REC-soap12-part2-20030624,
			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
	RESTful architecture Appendix A.2.		RESTful architecture Appendix A.2.
End of changes. 83 change blocks.
	219 lines changed or deleted		269 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/