< draft-miniero-bfcp-control-package-00.txt		draft-miniero-bfcp-control-package-01.txt >
	Network Working Group L. Miniero		Network Working Group L. Miniero
	Internet-Draft A. Amirante		Internet-Draft S P. Romano
	Expires: August 15, 2008 T. Castaldi		Expires: January 9, 2009 University of Napoli
	S P. Romano		R. Even
	University of Napoli		Polycom
	February 12, 2008		S. McGlashan
			Hewlett-Packard
			July 8, 2008
	A Binary Floor Control Protocol (BFCP) Control Package for the Session		A Binary Floor Control Protocol (BFCP) Control Package for the Media
	Initiation Protocol (SIP)		Control Channel Framework
	draft-miniero-bfcp-control-package-00.txt		draft-miniero-bfcp-control-package-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 39 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 15, 2008.		This Internet-Draft will expire on January 9, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document defines a Session Initiation Protocol (SIP) Control		This document defines a Media Control Channel Framework Package for
	Package for BFCP-based conference moderation. The control of Media		BFCP-based conference moderation. The control of Media Servers and
	Servers and their related resources in decomposed network		their related resources in decomposed network architectures plays an
	architectures plays an important role in various Next Generation		important role in various Next Generation Networks. This Control
	Networks. This Control Package aims at adding BFCP functionality to		Package aims at adding BFCP functionality to conferences using the
	conferences using the SIP Control Framework.		Media Control Channel Framework.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Control Package Definition . . . . . . . . . . . . . . . . . . 4		5. Control Package Definition . . . . . . . . . . . . . . . . . . 4
	5.1. Control Package Name . . . . . . . . . . . . . . . . . . . 4		5.1. Control Package Name . . . . . . . . . . . . . . . . . . . 5
	5.2. Framework Message Usage . . . . . . . . . . . . . . . . . 4		5.2. Framework Message Usage . . . . . . . . . . . . . . . . . 5
	5.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 5		5.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 6
	5.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 5		5.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 6
	5.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 5		5.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 6
	6. Element Definitions . . . . . . . . . . . . . . . . . . . . . 6		5.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Floors Manipulation . . . . . . . . . . . . . . . . . . . . . 7
	6.1.1. <moderateconference> . . . . . . . . . . . . . . . . . 6		7. Element Definitions . . . . . . . . . . . . . . . . . . . . . 8
	6.1.2. <unmoderateconference> . . . . . . . . . . . . . . . . 7		7.1. <mscbfcp> . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1.3. <addfloor> . . . . . . . . . . . . . . . . . . . . . . 8		7.1.1. Shared elements . . . . . . . . . . . . . . . . . . . 10
	6.1.4. <modifyfloor> . . . . . . . . . . . . . . . . . . . . 8		7.1.2. Requests . . . . . . . . . . . . . . . . . . . . . . . 11
	6.1.5. <removefloor> . . . . . . . . . . . . . . . . . . . . 9		7.1.3. Responses . . . . . . . . . . . . . . . . . . . . . . 17
	6.1.6. <addparticipant> . . . . . . . . . . . . . . . . . . . 10		7.1.4. Notifications . . . . . . . . . . . . . . . . . . . . 18
	6.1.7. <removeparticipant> . . . . . . . . . . . . . . . . . 10		7.2. Audit Elements . . . . . . . . . . . . . . . . . . . . . . 19
	6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 10		7.2.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 19
	6.2.1. <response> . . . . . . . . . . . . . . . . . . . . . . 10		7.2.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 19
	6.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 11		8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.3.1. <subscribe> . . . . . . . . . . . . . . . . . . . . . 11		9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.3.2. <event> . . . . . . . . . . . . . . . . . . . . . . . 11		10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	6.4. Floors Manipulation . . . . . . . . . . . . . . . . . . . 12		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	6.4.1. <floor> . . . . . . . . . . . . . . . . . . . . . . . 13		12. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 19
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
	8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		Intellectual Property and Copyright Statements . . . . . . . . . . 23
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The SIP Control Framework [11] provides a generic approach for		The Media Control Channel Framework
	establishment and reporting capabilities of remotely initiated		[I-D.ietf-mediactrl-sip-control-framework] provides a generic
	commands. The Framework utilizes many functions provided by the		approach for establishment and reporting capabilities of remotely
	Session Initiation Protocol (SIP) [4] for the rendezvous and		initiated commands. The Framework utilizes many functions provided
	establishment of a reliable channel for control interactions. The		by the Session Initiation Protocol (SIP) [RFC3261] for the rendezvous
	Control Framework also introduces the concept of a Control Package.		and establishment of a reliable channel for control interactions.
	A Control Package is an explicit usage of the Control Framework for a		The Control Framework also introduces the concept of a Control
	particular interaction set. This specification defines a package for		Package. A Control Package is an explicit usage of the Control
	floor control in conferences based on the use of the Binary Floor		Framework for a particular interaction set. This specification
	Control Protocol (BFCP) [8].		defines a package for floor control in conferences based on the use
			of the Binary Floor Control Protocol (BFCP) [RFC4582].
	2. Conventions		2. Conventions
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
	RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as		RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
	described in BCP 14, RFC 2119 [2] and indicate requirement levels for		described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
	compliant implementations.		levels for compliant implementations.
	3. Terminology		3. Terminology
	TBD.		TBD. Inherited from other documents, including
			[I-D.ietf-mediactrl-sip-control-framework] and
			[I-D.ietf-mediactrl-mixer-control-package].
			Application Server: TBD.
			Media Server: TBD.
			Control Package: TBD.
	4. Overview		4. Overview
	The SIP Control Framework [11] provides a generic approach for		The Media Control Channel Framework
	establishment and reporting capabilities of remotely initiated		[I-D.ietf-mediactrl-sip-control-framework] provides a generic
	commands. The Framework utilizes many functions provided by the		approach for establishment and reporting capabilities of remotely
	Session Initiation Protocol (SIP) [4] for the rendezvous and		initiated commands. The Framework utilizes many functions provided
	establishment of a reliable channel for control interactions. The		by the Session Initiation Protocol (SIP) [RFC3261] for the rendezvous
	Control Framework also introduces the concept of a Control Package.		and establishment of a reliable channel for control interactions.
	A Control Package is an explicit usage of the Control Framework for a		The Control Framework also introduces the concept of a Control
	particular interaction set. This specification defines a package for		Package. A Control Package is an explicit usage of the Control
	floor control in conferences based on the use of the Binary Floor		Framework for a particular interaction set. This specification
	Control Protocol (BFCP) [8].		defines a package for floor control in conferences based on the use
			of the Binary Floor Control Protocol (BFCP) [RFC4582].
	Floor control is needed whenever access to a resource, or set of		Floor control is needed whenever access to a resource, or set of
	resources, needs to be moderated. A typical example is the right to		resources, needs to be moderated. A typical example is the right to
	talk in a conference. In such a scenario, a participant willing to		talk in a conference. In such a scenario, a participant willing to
	talk would first have to place a request concerning the floor		talk would first have to place a request concerning the floor
	associated with such audio resource. The participant would then be		associated with such audio resource. The participant would then be
	added to the conference mix only when his request has been granted,		added to the conference mix only when his request has been granted,
	by the server itself or by a designated chair. RFC4582 [8] defines a		by the server itself or by a designated chair. RFC4582 [RFC4582]
	Binary Floor Control Protocol (BFCP) to specifically deal with such a		defines a Binary Floor Control Protocol (BFCP) to specifically deal
	need. It defines all the relevant entities (floors, queues,		with such a need. It defines all the relevant entities (floors,
	requests) and related actors (floor control servers, participants and		queues, requests) and related actors (floor control servers,
	chairs). So, the scope of this package is adding BFCP-based floor		participants and chairs). So, the scope of this package is adding
	control functionality to complementary packages that might need it,		BFCP-based floor control functionality to complementary packages that
	as the Conference Control Package [13].		might need it, as the Mixer Control Package
			[I-D.ietf-mediactrl-mixer-control-package]. In particular, this
			package aims at dealing with the case where the Floor Control Server
			(FCS), as defined in [RFC4582], is co-located with the Media Server
			(MS). In fact, if the FCS were co-located with the Application
			Server (AS), floor control would be part of the AS application logic,
			and thus out of scope for the MS. A typical example of how this
			could be accomplished is the 'controller' mechanism as specified in
			[I-D.ietf-mediactrl-mixer-control-package], where mixing in the MS
			and its contributors are actively setup by the AS, according to any
			policy the AS might be enforcing, including floor control.
	In particular, this package aims at dealing with the case where the
	Floor Control Server (FCS), as defined in [8], is co-located with the
	Media Server (MS). In fact, if the FCS were co-located with the
	Application Server (AS), floor control would be part of the AS
	application logic, and consequently out of scope for the MS.
	Considering users are added by the AS to the MS by means of a 3PCC		Considering users are added by the AS to the MS by means of a 3PCC
	[6] mechanism, a way to include BFCP negotiation is needed. In fact,		[RFC3725] mechanism, a way to include BFCP negotiation is needed. In
	users willing to act as floor participants will need to be made aware		fact, users willing to act as floor participants will need to be made
	of all the relevant identifiers (i.e. the transport address of the		aware of all the relevant identifiers (i.e. the transport address of
	floor control server, the BFCP conference ID associated with the mix,		the floor control server, the BFCP conference ID associated with the
	the BFCP user ID the user has been assigned, all the floor		mix, the BFCP user ID the user has been assigned, all the floor
	identifiers and their mapping with existing resources, and so on) to		identifiers and their mapping with existing resources, and so on) to
	opportunely interact with a floor control server. To achieve this,		properly interact with a floor control server. To achieve this,
	RFC4583 [8] provides with a way to negotiate BFCP connections within		RFC4583 [RFC4583] provides with a way to negotiate BFCP connections
	the context of a SDP offer/answer [5].		within the context of a SDP offer/answer [RFC3264].
	5. Control Package Definition		5. Control Package Definition
	This section fulfills the mandatory requirement for information that		This section fulfills the mandatory requirement for information that
	MUST be specified during the definition of a Control Framework		MUST be specified during the definition of a Control Framework
	Package, as detailed in Section 9 of [11].		Package, as detailed in Section 9 of
			[I-D.ietf-mediactrl-sip-control-framework].
	5.1. Control Package Name		5.1. Control Package Name
	The Control Framework requires a Control Package definition to		The Control Framework requires a Control Package definition to
	specify and register a unique name and version.		specify and register a unique name and version.
	The name and version of this Control Package is "msc-conf-bfcp/1.0"		The name and version of this Control Package is "msc-bfcp/1.0" (Media
	(Media Server Control - Conferencing - BFCP - version 1.0 ).		Server Control - Binary Floor Control - version 1.0).
	5.2. Framework Message Usage		5.2. Framework Message Usage
	BFCP functionality includes several different capabilities. There		BFCP functionality includes several different capabilities. There
	must be means to appropriately create, modify and destroy each of the		must be means to appropriately create, modify and destroy each of the
	available resources. This includes means to create a BFCP conference		available resources. This includes means to create a BFCP conference
	with specified settings, adding and removing floors to the		with specified settings, adding and removing floors to the
	conference, setting or unsetting designated chairs for such floors		conference, setting or unsetting designated chairs for such floors
	and so on.		and so on. Proper subscription and notification mechanisms must also
			be made available, in order to make the AS aware of all the relevant
			events it might be interested to.
	This package defines XML elements in Section 6 and provides an XML		This package defines XML elements in Section 7 and provides an XML
	Schema in Section 8. Additionally, some examples are provided in		Schema in Section 9. Additionally, some examples are provided in
	Section 7.		Section 8.
	The XML elements in this package are split into requests, responses		The XML elements in this package are split into requests, responses
	and event notifications. Requests are carried in CONTROL message		and event notifications, all of which are contained within a root
	bodies; <moderateconference> and <addfloor> elements are examples of		<mscbfcp> element. Requests are carried in CONTROL message bodies;
	package requests. Responses are carried either in REPORT message or		<moderateconference> and <addfloor> elements are examples of package
	Control Framework 200 response bodies; the <response> element is		requests. Responses are carried either in REPORT message or Control
	defined as a package response. Event notifications are also carried		Framework 200 response bodies; the <response> element is defined as a
	in REPORT message bodies; the <event> element is defined for package		package response. Event notifications are instead carried in CONTROL
	event notifications. Event subscription is accomplished by means of		message bodies; the <event> element is defined for package event
	the <subscribe> element.		notifications. Event subscription is accomplished by means of the
			<subscribe> element.
	Note that package responses are different from framework response		Note that package responses are different from framework response
	codes. Framework error response codes (see Section 8 of [11]) are		codes. Framework error response codes (see Section 8 of
	used when the request or event notification is invalid; for example,		[I-D.ietf-mediactrl-sip-control-framework]) are used when the request
	a request is invalid XML (400), or not understood (500). Package		or event notification is invalid; for example, a request is invalid
	responses are carried in 200 response or REPORT message bodies. This		XML (400), or not understood (500). Package responses are carried in
	package's response codes are defined in Section 6.2.1.		200 response or REPORT message bodies. This package's response codes
			are defined in Section 7.1.3.1.
	The schema uses the "connection-id" and "conf-id" attributes which		The schema uses the "connection-id" and "conf-id" attributes which
	are imported from the schema defined in the core Control Framework		are imported from the schema defined in the core Control Framework
	[11].		[I-D.ietf-mediactrl-sip-control-framework].
	5.3. Common XML Support		5.3. Common XML Support
	The Control Framework requires a Control Package definition to		The Control Framework requires a Control Package definition to
	specify if the attributes for media dialog or conference references		specify if the attributes for media dialog or conference references
	are required.		are required.
	This package requires that the XML Schema in Section 16.1 of [11]		This package requires that the XML Schema in Section 17.1 of
	MUST be supported for media dialogs and conferences.		[I-D.ietf-mediactrl-sip-control-framework] MUST be supported for
			media dialogs and conferences.
	5.4. CONTROL Message Body		5.4. CONTROL Message Body
	A valid CONTROL body message MUST conform to the schema defined in		The Control Framework requires a Control Package to define the
	Section 8 and described in Section 6. XML messages appearing in		control body that can be contained within a CONTROL command request
	CONTROL messages MUST contain one of the elements described in		and to indicate the location of detailed syntax definitions and
	Section 6.1.		semantics for the appropriate body types.
			When operating as Control Framework Server, the MS receives CONTROL
			messages with a body containing an <mscbfcp> element with either a
			floor control management or audit request child element.
			The following mixer management request elements are carried in
			CONTROL message bodies to MS: <moderateconference> (Section 7.1.2.1),
			<unmoderateconference> (Section 7.1.2.2), <addfloor>
			(Section 7.1.2.3), <modifyfloor> (Section 7.1.2.4), <removefloor>
			(Section 7.1.2.5), <addparticipant> (Section 7.1.2.6),
			<modifyparticipant> (Section 7.1.2.7) and <removeparticipant>
			(Section 7.1.2.8) elements.
			The <audit> request element (Section 7.2.1) is also carried in
			CONTROL message bodies.
			When operating as Control Framework Client, the MS sends CONTROL
			messages with a body containing a notification <event&gT; element
			(Section 7.1.4.2).
	5.5. REPORT Message Body		5.5. REPORT Message Body
	A valid REPORT body MUST conform to the schema defined in Section 8		A valid REPORT body MUST conform to the schema defined in Section 9
	and described in Section 6. XML messages appearing in REPORT		and described in Section 7. XML messages appearing in REPORT
	messages MUST contain a <response> (Section 6.2.1), or a		messages MUST contain a <response> (Section 7.1.3.1), or a
	(notification) <event> element (Section 6.3.2).		(notification) <event> element (Section 7.1.4.2).
	6. Element Definitions		5.6. Audit
			The Control Framework encourages Control Packages to specify whether
			auditing is available, how it is triggered as well as the query/
			response formats.
			This Control Packages supports auditing of package capabilities and
			dialogs on the MS. An audit request is carried in a CONTROL messages
			and an audit response in a REPORT message (or a 200 reponse to the
			CONTROL if it can execute the audit in time).
			The syntax and semantics of audit request and response elements is
			defined in Section 4.4.
			6. Floors Manipulation
			Before delving into the details of the package elements, a few words
			are worth being spent with respect to how floors are assumed to be
			manipulated in this package.
			Floors are defined as tokens associated with a resource, or set of
			resources, in order to moderate the access to their functionality by
			users. This introduces the need for a mechanism in the package to
			properly take care of this kind of association, especially when
			dealing about resources directly manipulated by the Media Server
			(e.g. andio and video).
			Let's consider the following figure, which presents the view of an
			audio conference with three participants, and the related media
			labels associated with each participant's media stream:
			MS
			+---------------+
			UAC A | | UAC B
			o-----------+--x x--+-----------o
			a1b2c3 | | d4e5f6
			| |
			| x |
			| | |
			+-------+-------+
			|
			| g7h8i9
			|
			o
			UAC C
			Figure 1: Audio Conference with labels
			Even if each participant sees a different label for the stream it has
			with the mixer, the floor associated with the only available resource
			in the conference (audio) is the same. This means that the package
			needs to have a way to address each resource in the conference
			according to how it is defined in
			[I-D.ietf-mediactrl-mixer-control-package], e.g. "associate media
			'audio' with floor 11" or any other more complex assignment involving
			labels and the like. Once a participant's media stream is attached
			to the resource, the related label is consequently associated with
			the floor as specified in [RFC4583]. Figure 2 depicts such the case
			where all the participants have been attached to the mix.
			MS
			+---------------+
			UAC A | | UAC B
			o-----------+--+~~>[ ]<~~+--+-----------o
			a1b2c3 | ^ | d4e5f6
			(floor 11) | | | (floor 11)
			| + |
			| | |
			+-------+-------+
			|
			| g7h8i9
			| (floor 11)
			o
			UAC C
			Figure 2: Audio Conference with labels and floors
			The same approach can be considered when dealing with different
			floors associated with one or more different resources, e.g.
			conferences with an audio and a video stream, conferences with two
			different audio streams, and so on. Each floor needs to be
			unambiguously associated with a subset of the available resources
			(e.g. floor 11 is audio1 and floor 22 is video, or floor 11 is audio1
			while floor 22 is audio2, or floor 11 is audio1 AND audio2 AND
			video2, and so on).
			To achieve this, each floor, together with its configuration, is
			defined in the package by the <floor> element, as described in
			Section 7.1.1.1.
			7. Element Definitions
	This section defines the XML messages for this control package.		This section defines the XML messages for this control package.
	[Editors Note: since XML Schema may not be able to express all		[Editors Note: since XML Schema may not be able to express all
	constraints expressed in these definitions, in cases where there is a		constraints expressed in these definitions, in cases where there is a
	difference in constraints, the definitions in the section take		difference in constraints, the definitions in the section take
	priority.]		priority.]
	6.1. Requests		7.1. <mscbfcp>
	The following request elements are defined:		The <mscbfcp> element has the following attributes (in addition to
			standard XML namspace attributes such as xmlns):
			version: a string specifying the mscbfcp package version. The value
			is fixed as '1.0' for this version of the package. The attribute is
			mandatory.
			The <mscbfcp> element has the following defined child elements, only
			one of which can occur:
	<moderateconference>: create and configure a new BFCP conference,		<moderateconference>: create and configure a new BFCP conference,
	associated with an existing framework conference instance to		associated with an existing framework conference instance to
	moderate - see Section 6.1.1 for details;		moderate - see Section 7.1.2.1 for details;
	<unmoderateconference>: destroy a BFCP conference, thus stopping the		<unmoderateconference>: destroy a BFCP conference, thus stopping the
	moderation of the associated framework conference instance - see		moderation of the associated framework conference instance - see
	Section 6.1.2 for details;		Section 7.1.2.2 for details;
	<addfloor>: add and configure a new floor to an existing BFCP		<addfloor>: add and configure a new floor to an existing BFCP
	conference - see Section 6.1.3 for details;		conference - see Section 7.1.2.3 for details;
	<modifyfloor>: modify the configuration of a currently handled floor		<modifyfloor>: modify the configuration of a currently handled floor
	in an existing BFCP conference - see Section 6.1.4 for details;		in an existing BFCP conference - see Section 7.1.2.4 for details;
	<removefloor>: remove a currently handled floor from an existing		<removefloor>: remove a currently handled floor from an existing
	BFCP conference - see Section 6.1.5 for details;		BFCP conference - see Section 7.1.2.5 for details;
	<addparticipant>: add a floor participant to a BFCP conference - see		<addparticipant>: add a floor participant to a BFCP conference - see
	Section 6.1.6 for details;		Section 7.1.2.6 for details;
			<modifyparticipant>: modify an existing floor participant in a BFCP
			conference - see Section 7.1.2.7 for details;
	<removeparticipant>: remove a floor participant from a BFCP		<removeparticipant>: remove a floor participant from a BFCP
	conference - see Section 6.1.7 for details.		conference - see Section 7.1.2.8 for details.
	6.1.1. <moderateconference>		<response>: response to a floor control request - see Section 7.1.3
			for details.
			<event>: bfcp or subscription notification - see Section 7.1.4 for
			details.
			7.1.1. Shared elements
			All the previously introduced requests make use of the same element
			specification to describe the desired operation. Specifically,
			<moderateconference>, <addfloor> and <modifyfloor> make use of the
			<floor> element (Section 7.1.1.1), while <addparticipant>,
			<modifyparticipant> and <removeparticipant> make use of the
			<participant> element (Section 7.1.1.2).
			7.1.1.1. <floor>
			The <floor> element is used in the package to configure a floor in a
			BFCP conference. It addresses all the relevant settings for a floor,
			including the resource (or, again, set of resources) it must be
			associated with, the maximum number of users that can be granted the
			floor at the same time, the maximum number of requests the same
			participant can place for this floor at the same time, and the
			default policy the FCS considers for incoming requests about the
			floor.
			The <floor> element has the following attributes:
			bfcp-floor-id: string indicating the name of the BFCP floor. This
			attribute is optional.
			<media>: an element indicating the type of media associated with the
			floor, i.e. the resource associated with the floor, as defined in
			[I-D.ietf-mediactrl-mixer-control-package]. The string might be a
			comma-separated list in case the floor is associated with more
			than one resource (e.g. media="audio,video"). This element is
			mandatory.
			<max-users>: an element indicating the maximum number of users that
			can be granted this floor at the same time: this basically sets
			the size of the granted floor queue. In case all the queue slots
			have already been granted, subsequent requests are put on hold.
			This element is optional: if missing, the default value (max-
			users="1") is used.
			<max-requests>: an element indicating the maximum number of requests
			each user can place for the floor before being granted it. This
			element is optional: if missing, the default value (max-
			requests"="1) is used.
			<policy>: an element indicating the default policy the FCS must take
			whenever receiving requests for this floor and the chair is
			missing. In fact, in case a chair is involved, the request is
			forwarded to him, which then takes a decision about it. The
			policy can be an 'autodeny' (deny all the requests for this
			floor), 'autoaccept' (accept all the requests for this floor) or
			'ignore' (ignore all the requests for this floor and put them on
			ice, waiting for a chair to appear) policy. This element is
			optional: if missing, the default value (policy="autoaccept") is
			used.
			The "bfcp-floor-id" attribute has different roles according to the
			request the <floor> element is part of. The behaviour of the package
			changes accordingly. Specifically:
			<moderateconference|addfloor>: if the attribute is not specified,
			the MS creates a unique name for the BFCP floor. The value is
			used in subsequent references to the conference (e.g. as bfcp-
			floor-id in a <modifyfloor>). The new value of this attribute
			MUST be unique or else a 403 'Floor already exists' package level
			error will be reported.
			<modifyfloor>: if the attribute is not specified, the value of the
			attribute in the father element is used. If it is specified,
			instead, it must not conflict with the value of the attribute in
			the father element, otherwise it is an error.
			TBD. Elaborate the floor mechanism.
			[Note: the first problem that comes to mind is the actual association
			between a floor and a resource in the MS. Specifically, enforcing
			the decisions might be an issue, since there's no way this package
			and msc-mixer can talk with each other...]
			7.1.1.2. <participant>
			TBD. Elaborate the participant mechanism.
			[Note: this element will include the same mechanism used in other
			packages to address a connection, in order to associate a BFCP user
			identifier to it. Besides, it will include means to specify whether
			or not a participant is chair of any of the available floors.]
			7.1.2. Requests
			7.1.2.1. <moderateconference>
	<moderateconference> is used in a request by the AS to moderate an		<moderateconference> is used in a request by the AS to moderate an
	existing conference instance, by associating to it a new, properly		existing conference instance, by associating to it a new, properly
	configured, BFCP conference.		configured, BFCP conference.
	The <moderateconference> element has the following attributes:		The <moderateconference> element has the following attributes:
	conf-id: string indicating the name of the conference to moderate.		conf-id: string indicating the name of the conference to moderate.
	The conference MUST be known by the receiving entity or else a 404		The conference MUST be known by the receiving entity or else a 404
	'Conference does not exist' package level error will be generated.		'Conference does not exist' package level error will be generated.
	This attribute is mandatory.		This attribute is mandatory.
	bfcp-conf-id: string (an unsigned integer) indicating a unique name		bfcp-conf-id: string (an unsigned integer) indicating a unique name
	for the BFCP conference. If this attribute is not specified, the		for the BFCP conference. If this attribute is not specified, the
	MS creates a unique name for the BFCP conference. The value is		MS creates a unique name for the BFCP conference. The value is
	used in subsequent references to the conference (e.g. as bfcp-		used in subsequent references to the conference (e.g. as bfcp-
	conf-id in a <response>). When present in a <moderateconference>		conf-id in a <response>), and in actual BFCP protocol contents as
	request, the new value of this attribute MUST be unique or else a		well, and as such MUST adhere to the syntax defined in [RFC4582].
	403 'Conference already exists' package level error will be		When present in a <moderateconference> request, the new value of
	reported. The attribute is optional.		this attribute MUST be unique or else a 403 'Conference already
			exists' package level error will be reported. The attribute is
			optional.
	Additionally, to configure the new BFCP conference, the		Additionally, to configure the new BFCP conference, the
	<moderateconference> element has the following child elements		<moderateconference> element has the following child elements
	defined:		defined:
	<floor>: an element to configure a floor in the new BFCP conference		<floor>: an element (Section 7.1.1.1) to configure a floor in the
	(see Section 6.4.1 for more details). This element only refers to		new BFCP conference (see Section 7.1.1.1 for more details). This
	floors already available at creation time. New floors can still		element only refers to floors already available at creation time.
	be added subsequently by means of an <addfloor> request (see		New floors can still be added subsequently by means of an
	Section 6.1.3). This element is optional.		<addfloor> request (see Section 7.1.2.3). This element is
			optional.
	<subscribe>: an element to request subscription to conference		<subscribe>: an element to request subscription to conference
	events. (see Section 6.3.1 for more details). This element is		events. (see Section 7.1.4.1 for more details). This element is
	optional.		optional.
	Multiple <floor> elements may be defined, in case several floors are		Multiple <floor> elements may be defined, in case several floors are
	needed.		needed.
	When a MS has finished processing a <moderateconference> request, it		When a MS has finished processing a <moderateconference> request, it
	MUST reply with an appropriate <response> element (Section 6.2.1).		MUST reply with an appropriate <response> element (Section 7.1.3).
	6.1.2. <unmoderateconference>		7.1.2.2. <unmoderateconference>
	<unmoderateconference> is used in a request by the AS to destroy a		<unmoderateconference> is used in a request by the AS to destroy a
	BFCP conference, thus stopping the moderatation of the associated		BFCP conference, thus stopping the moderatation of the associated
	existing framework conference instance. A successful processing of		existing framework conference instance. A successful processing of
	this request does NOT result in a destruction of the associated media		this request does NOT result in a destruction of the associated media
	conference: it only results in the media conference not being		conference: it only results in the media conference not being
	moderated by means of BFCP anymore. The actual destruction of the		moderated by means of BFCP anymore. The actual destruction of the
	media conference itself is accomplished through the means provided in		media conference itself is accomplished through the means provided in
	[13].		[I-D.ietf-mediactrl-mixer-control-package].
	The <unmoderateconference> element has the following attributes:		The <unmoderateconference> element has the following attributes:
	bfcp-conf-id: string indicating the name of the BFCP conference to		bfcp-conf-id: string indicating the name of the BFCP conference to
	destroy. The conference MUST be known by the receiving entity or		destroy. The conference MUST be known by the receiving entity or
	else a 404 'Conference does not exist' package level error will be		else a 404 'Conference does not exist' package level error will be
	generated. This attribute is mandatory.		generated. This attribute is mandatory.
	The <unmoderateconference> element does not specify any child		The <unmoderateconference> element does not specify any child
	elements.		elements.
	When a MS has finished processing an <unmoderateconference> request,		When a MS has finished processing an <unmoderateconference> request,
	it MUST reply with an appropriate <response> element (Section 6.2.1).		it MUST reply with an appropriate <response> element
			(Section 7.1.3.1).
	6.1.3. <addfloor>		7.1.2.3. <addfloor>
	<addfloor> is used in a request by the AS to add one or more floors		<addfloor> is used in a request by the AS to add one or more floors
	to an existing BFCP conference instance.		to an existing BFCP conference instance.
	The <addfloor> element has the following attributes:		The <addfloor> element has the following attributes:
	bfcp-conf-id: string indicating the name of the BFCP conference to		bfcp-conf-id: string indicating the name of the BFCP conference to
	add the floor(s) to. The conference MUST be known by the		add the floor(s) to. The conference MUST be known by the
	receiving entity or else a 404 'Conference does not exist' package		receiving entity or else a 404 'Conference does not exist' package
	level error will be generated. This attribute is mandatory.		level error will be generated. This attribute is mandatory.
	Additionally, to configure the new floor(s), the <addfloor> element		Additionally, to configure the new floor(s), the <addfloor> element
	has the following child elements defined:		has the following child elements defined:
	<floor>: an element to configure a new floor in the specified BFCP		<floor>: an element to configure a new floor in the specified BFCP
	conference (see Section 6.4.1 for more details). This element is		conference (see Section 7.1.1.1 for more details). This element
	mandatory.		is mandatory.
	Multiple <floor> elements may be defined, in case several floors are		Multiple <floor> elements may be defined, in case several floors are
	to be added at the same time.		to be added at the same time.
	When a MS has finished processing a <addfloor> request, it MUST reply		When a MS has finished processing an <addfloor> request, it MUST
	with an appropriate <response> element (Section 6.2.1).		reply with an appropriate <response> element (Section 7.1.3.1).
	6.1.4. <modifyfloor>		7.1.2.4. <modifyfloor>
			<modifyfloor> is used in a request by the AS to modify the
			configuration of a floor in an existing BFCP conference instance.
			The <modifyfloor> element has the following attributes:
			bfcp-conf-id: string indicating the name of the BFCP conference to
			modify the floor's in. The conference MUST be known by the
			receiving entity or else a 404 'Conference does not exist' package
			level error will be generated. This attribute is mandatory.
			bfcp-floor-id: string indicating the name of the BFCP floor to
			modify the floor. The floor MUST be known by the receiving entity
			or else a 404 'Floor does not exist' package level error will be
			generated. This attribute is mandatory.
			Additionally, to modify the configuration of the floor, the
			<modifyfloor> element has the following child elements defined:
			<floor>: an element to configure the specified floor in the
			specified BFCP conference (see Section 7.1.1.1 for more details).
			This element is mandatory.
			It is an error if the provided <floor> element conflicts with the
			BFCP floor identifier attribute.
			When a MS has finished processing a <modifyfloor> request, it MUST
			reply with an appropriate <response> element (Section 7.1.3.1).
			7.1.2.5. <removefloor>
	<removefloor> is used in a request by the AS to remove an existing		<removefloor> is used in a request by the AS to remove an existing
	floor from the BFCP conference instance it is in. A successful		floor from the BFCP conference instance it is in. A successful
	processing of this request does NOT result in a destruction of the		processing of this request does NOT result in a destruction of the
	associated resource (or set of resources): it only results in the		associated resource (or set of resources): it only results in the
	associated resource not being moderated by means of BFCP anymore.		associated resource not being moderated by means of BFCP anymore.
	The actual destruction of the resource (in case it is directly		The actual destruction of the resource (in case it is directly
	handled and manipulated by the MS itself) is accomplished through the		handled and manipulated by the MS itself) is accomplished through the
	means provided in [13].		means provided in [I-D.ietf-mediactrl-mixer-control-package].
	The <removefloor> element has the following attributes:		The <removefloor> element has the following attributes:
	bfcp-conf-id: string indicating the name of the BFCP conference to		bfcp-conf-id: string indicating the name of the BFCP conference to
	remove the floor from. The conference MUST be known by the		remove the floor from. The conference MUST be known by the
	receiving entity or else a 404 'Conference does not exist' package		receiving entity or else a 404 'Conference does not exist' package
	level error will be generated. This attribute is mandatory.		level error will be generated. This attribute is mandatory.
	bfcp-floor-id: string indicating the name of the BFCP floor to		bfcp-floor-id: string indicating the name of the BFCP floor to
	remove. The floor MUST be known by the receiving entity or else a		remove. The floor MUST be known by the receiving entity or else a
	404 'Floor does not exist' package level error will be generated.		404 'Floor does not exist' package level error will be generated.
	This attribute is mandatory.		This attribute is mandatory.
	The <removefloor> element does not specify any child elements.		The <removefloor> element does not specify any child elements.
	When a MS has finished processing a <removefloorfloor> request, it		When a MS has finished processing a <removefloor> request, it MUST
	MUST reply with an appropriate <response> element (Section 6.2.1).		reply with an appropriate <response> element (Section 7.1.3.1).
	6.1.5. <removefloor>		7.1.2.6. <addparticipant>
	<modifyfloor> is used in a request by the AS to modify the		<addparticipant> is used in a request by the AS to add a new BFCP
	configuration of a floor in an existing BFCP conference instance.		participant instance to an existing BFCP conference. Some additional
			details can also be provided about the new participant, if it will be
			the chair of one of the floors for example.
	The <modifyfloor> element has the following attributes:		The <addparticipant> element has the following attributes:
			bfcp-conf-id: string indicating the name of the BFCP conference to
			add the participant to. The conference MUST be known by the
			receiving entity or else a 404 'Conference does not exist' package
			level error will be generated. This attribute is mandatory.
			bfcp-user-id: string (an unsigned integer) indicating a unique name
			for the new BFCP participant. If this attribute is not specified,
			the MS creates a unique name for the BFCP participant. The value
			is used in subsequent references to the conference (e.g. as bfcp-
			conf-id in a <response>), and in actual BFCP protocol contents as
			well, and as such MUST adhere to the syntax defined in [RFC4582].
			When present in an <addparticipant> request, the new value of this
			attribute MUST be unique or else a 405 'User already exists'
			package level error will be reported. The attribute is optional.
			Additionally, to configure the new participant, the <addparticipant>
			element has the following child elements defined:
			<participant>: an element to configure a new floor in the specified
			BFCP conference (see Section 7.1.1.2 for more details). This
			element is mandatory.
			Only one <participant> element can be present, which means only one
			BFCP participant instance can be added at the same time.
			When a MS has finished processing an <addparticipant> request, it
			MUST reply with an appropriate <response> element (Section 7.1.3.1).
			[Note: is this really needed? there may be RFC4583 for that...]
			7.1.2.7. <modifyparticipant>
			<modifyparticipant> is used in a request by the AS to modify the
			configuration of a participant in an existing BFCP conference
			instance. A typical use case for this request is to set or unset a
			participant as chair of a floor in a conference.
			The <modifyparticipant> element has the following attributes:
	bfcp-conf-id: string indicating the name of the BFCP conference to		bfcp-conf-id: string indicating the name of the BFCP conference to
	modify the floor's in. The conference MUST be known by the		modify the floor's in. The conference MUST be known by the
	receiving entity or else a 404 'Conference does not exist' package		receiving entity or else a 404 'Conference does not exist' package
	level error will be generated. This attribute is mandatory.		level error will be generated. This attribute is mandatory.
	bfcp-floor-id: string indicating the name of the BFCP floor to		bfcp-user-id: string indicating the name of the BFCP participant
	modify the floor. The floor MUST be known by the receiving entity		whose settings must be modified. The participant MUST be known by
	or else a 404 'Floor does not exist' package level error will be		the receiving entity or else a 406 'User does not exist' package
	generated. This attribute is mandatory.		level error will be generated. This attribute is mandatory.
	Additionally, to modify the configuration of the floor, the		Additionally, to modify the configuration of the participant, the
	<modifyfloor> element has the following child elements defined:		<modifyparticipant> element has the following child elements defined:
	<floor>: an element to configure the specified floor in the		<participant>: an element to configure the specified participant in
	specified BFCP conference (see Section 6.4.1 for more details).		the specified BFCP conference (see Section 7.1.1.2 for more
	This element is mandatory.		details). This element is mandatory.
	It is an error if the provided <floor> element conflicts with the		It is an error if the provided <participant> element conflicts with
	BFCP floor identifier attribute.		the BFCP participant identifier attribute.
	When a MS has finished processing a <modifyfloor> request, it MUST		When a MS has finished processing a <modifyparticipant> request, it
	reply with an appropriate <response> element (Section 6.2.1).		MUST reply with an appropriate <response> element (Section 7.1.3.1).
	6.1.6. <addparticipant>		7.1.2.8. <removeparticipant>
	TBD. (is this really needed? there's RFC4583 for that...)		<removeparticipant> is used in a request by the AS to remove an
			existing participant from the BFCP conference instance it is in. A
			successful processing of this request does NOT result in a
			termination of the participant's media session: it only results in
			the associated media streams not being moderated by means of BFCP
			anymore..
	6.1.7. <removeparticipant>		The <removeparticipant> element has the following attributes:
	TBD. (is this really needed? there's RFC4583 for that...)		bfcp-conf-id: string indicating the name of the BFCP conference to
			remove the floor from. The conference MUST be known by the
			receiving entity or else a 404 'Conference does not exist' package
			level error will be generated. This attribute is mandatory.
	6.2. Responses		bfcp-user-id: string indicating the name of the BFCP participant to
			remove. The participant MUST be known by the receiving entity or
			else a 406 'User does not exist' package level error will be
			generated. This attribute is mandatory.
			The <removeparticipant> element does not specify any child elements.
			When a MS has finished processing a <removeparticipant> request, it
			MUST reply with an appropriate <response> element (Section 7.1.3.1).
			[Note: is this really needed? there may be RFC4583 for that...]
			7.1.3. Responses
	All responses to the previously described requests are specified in a		All responses to the previously described requests are specified in a
	<response> element. This element may be contained in the body either		<response> element. This element may be contained in the body either
	of a REPORT framework message or in a 200 framework message.		of a REPORT framework message or in a 200 framework message.
	6.2.1. <response>		7.1.3.1. <response>
	Reponses to requests are indicated by a <response> element.		Reponses to requests are indicated by a <response> element.
	The <response> element has the following attributes:		The <response> element has the following attributes:
	status: numeric code indicating the response status. This attribute		status: numeric code indicating the response status. This attribute
	is mandatory.		is mandatory.
	reason: string specifying a human readable description of the reason		reason: string specifying a human readable description of the reason
	for the response status. This attribute is optional.		for the response status. This attribute is optional.
	skipping to change at page 11, line 5 ¶		skipping to change at page 18, line 16 ¶
	| code | description |		| code | description |
	+------+-------------+		+------+-------------+
	| 200 | OK |		| 200 | OK |
	| 4xx | whatever |		| 4xx | whatever |
	+------+-------------+		+------+-------------+
	Table 1: <response> Status codes		Table 1: <response> Status codes
	TBD. Add all error codes and their meanings		TBD. Add all error codes and their meanings
	6.3. Notifications		7.1.4. Notifications
	In case the a controlling client is interested in receiving events		In case the AS is interested in receiving events regarding a BFCP
	regarding a BFCP conference, a notification mechanism is provided in		conference, a notification mechanism is provided in the package. The
	the package. The client requests subscription to such events by		AS requests subscription to such events by adding a <subscribe> child
	adding a <subscribe> child element to the <moderateconference>		element to the <moderateconference> request, whereas the MS triggers
	request, whereas the MS triggers the related events in subsequent		the related events in subsequent REPORT messages. Event
	REPORT messages. Event notifications are then delivered using the		notifications are then delivered using the <event> element.
	<event> element.
	6.3.1. <subscribe>		7.1.4.1. <subscribe>
	BFCP event notifications are defined when a controlling client		BFCP event notifications are defined when an AS subscribes to
	subscribes to notifications for BFCP-related events using the		notifications for BFCP-related events using the <subscribe> element
	<subscribe> element in a <moderateconference> request.		in a <moderateconference> request.
	The <subscribe> element has no attributes, but has the following		The <subscribe> element has no attributes, but has the following
	child elements defined:		child elements defined:
	<notify>: contains the following attributes:		<notify>: contains the following attributes:
	name a string indicating the name of the event to be notified.		name: a string indicating the name of the event to be notified.
	The attribute is mandatory.		This attribute is mandatory.
	Multiple <notify> elements may be specified.		Multiple <notify> elements may be specified.
	The MS would then use the <event> element to send notifications to		The MS would then use the <event> element to send notifications to
	the controlling client.		the AS.
	6.3.2. <event>		7.1.4.2. <event>
	Delivery of events the AS subscribed for is accomplished by means of		Delivery of events the AS subscribed for is accomplished by means of
	an <event> element.		an <event> element.
	The <event> element has the following attributes:		The <event> element has the following attributes:
	name: string indicating the name of the BFCP event. This attribute		name: string indicating the name of the BFCP event. This attribute
	is mandatory.		is mandatory.
	bfcp-conf-id: string identifying the BFCP conference the event		bfcp-conf-id: string identifying the BFCP conference the event
	happened in. This attribute is mandatory.		happened in. This attribute is mandatory.
	Additionally, to provide the AS with details upon the event, the		Additionally, to provide the AS with details upon the event, the
	<event> element has the following child elements defined:		<event> element has the following child elements defined:
	TBD. Elaborate the notification mechanism.		TBD. Elaborate the notification mechanism.
	6.4. Floors Manipulation		7.2. Audit Elements
	Floors are defined as tokens associated with a resource, or set of
	resources, in order to moderate the access to their functionality by
	users. This introduces the need for a mechanism in the package to
	properly take care of this kind of association, especially when
	dealing about resources directly manipulated by the Media Server
	(e.g. andio and video).
	Let's consider the following figure, which presents the view of an
	audio conference with three participants, and the related media
	labels associated with each participant's media stream:
	MS
	+---------------+
	UAC A | | UAC B
	o-----------+--x x--+-----------o
	a1b2c3 | | d4e5f6
	| |
	| x |
	| | |
	+-------+-------+
	|
	| g7h8i9
	|
	o
	UAC C
	Figure 1: Audio Conference with labels
	Even if each participant sees a different label for the stream he has
	with the mixer, the floor associated with the only available resource
	in the conference (audio) is the same. This means that the package
	needs to have a way to address each resource in the conference
	according to how it is defined in [13], e.g. "associate media 'audio'
	with floor 11". Once a participant's media stream is attached to the
	resource, the related label is consequently associated with the floor
	as specified in [9]. Figure 2 depicts such the case where all the
	participants have been attached to the mix.
	MS
	+---------------+
	UAC A | | UAC B
	o-----------+--+~~>[ ]<~~+--+-----------o
	a1b2c3 | ^ | d4e5f6
	(floor 11) | | | (floor 11)
	| + |
	| | |
	+-------+-------+
	|
	| g7h8i9
	| (floor 11)
	o
	UAC C
	Figure 2: Audio Conference with labels and floors
	The same approach can be considered when dealing with different
	floors associated with one or more different resources, e.g.
	conferences with an audio and a video stream, conferences with two
	different audio streams, and so on. Each floor needs to be
	unambiguously associated with a subset of the available resources
	(e.g. floor 11 is audio1 and floor 22 is video, or floor 11 is audio1
	while floor 22 is audio2, or floor 11 is audio1 AND audio2 AND
	video2, and so on).
	To achieve this, each floor, together with its configuration, is
	defined in the package by the <floor> element.
	6.4.1. <floor>
	The <floor> element is used in the package to configure a floor in a
	BFCP conference. It addresses all the relevant settings for a floor,
	including the resource (or, again, set of resources) it must be
	associated with, the maximum number of users that can be granted the
	floor at the same time, the maximum number of requests the same
	participant can place for this floor at the same time, and the
	default policy the FCS considers for incoming requests about the
	floor.
	The <floor> element has the following attributes:		7.2.1. <audit>
	bfcp-floor-id: string indicating the name of the BFCP floor. This		TBD.
	attribute is optional.
	<media>: an element indicating the type of media associated with the		7.2.2. <auditresponse>
	floor, i.e. the resource associated with the floor, as defined in
	[13]. The string might be a comma-separated list in case the
	floor is associated with more than one resource (e.g.
	media="audio,video"). This element is mandatory.
	<max-users>: an element indicating the maximum number of users that		TBD.
	can be granted this floor at the same time: this basically sets
	the size of the granted floor queue. In case all the queue slots
	have already been granted, subsequent requests are put on hold.
	This element is optional: if missing, the default value (max-
	users="1") is used.
	<max-requests>: an element indicating the maximum number of requests		8. Examples
	each user can place for the floor before being granted it. This
	element is optional: if missing, the default value (max-
	requests"="1) is used.
	<policy>: an element indicating the default policy the FCS must take		TBD.
	whenever receiving requests for this floor and the chair is
	missing. In fact, in case a chair is involved, the request is
	forwarded to him, which then takes a decision about it. The
	policy can be an 'autodeny' (deny all the requests for this
	floor), 'autoaccept' (accept all the requests for this floor) or
	'ignore' (ignore all the requests for this floor and put them on
	ice, waiting for a chair to appear) policy. This element is
	optional: if missing, the default value (policy="autoaccept") is
	used.
	The "bfcp-floor-id" attribute has different roles according to the		9. Formal Syntax
	request the <floor> element is part of. The behaviour of the package
	changes accordingly. Specifically:
	<moderateconference|addfloor>: if the attribute is not specified,		TBD.
	the MS creates a unique name for the BFCP floor. The value is
	used in subsequent references to the conference (e.g. as bfcp-
	floor-id in a <modifyfloor>). The new value of this attribute
	MUST be unique or else a 403 'Floor already exists' package level
	error will be reported.
	<modifyfloor>: if the attribute is not specified, the value of the		10. Security Considerations
	attribute in the father element is used. If it is specified,
	instead, it must not conflict with the value of the attribute in
	the father element, otherwise it is an error.
	TBD. Elaborate the floor mechanism.		TBD.
	7. Examples		11. IANA Considerations
	TBD.		TBD.
	8. Formal Syntax		12. Change Summary
	TBD.		The following are the major changes between the -00 and the -01
			versions of the draft:
	9. Security Considerations		o updated references (mixer draft);
	TBD.		o updated authors;
	10. IANA Considerations		o aligned syntax to the one used in msc-ivr and msc-mixer
			(<mscbfcp>);
	TBD.		o added placeholders for event notifications and auditing;
	11. Acknowledgements		o added participant related methods, and moved floor related
			discussions;
			13. Acknowledgements
	TBD.		TBD.
	12. References		14. References
	[1] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.		Specifications: ABNF", RFC 2234, November 1997.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	Considerations Section in RFCs", BCP 26, RFC 2434,		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		A., Peterson, J., Sparks, R., Handley, M., and E.
	Session Initiation Protocol", RFC 3261, June 2002.		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			June 2002.
	[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	Session Description Protocol (SDP)", RFC 3264, June 2002.		with Session Description Protocol (SDP)", RFC 3264,
			June 2002.
	[6] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,		[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
	"Best Current Practices for Third Party Call Control (3pcc) in		Camarillo, "Best Current Practices for Third Party Call
	the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,		Control (3pcc) in the Session Initiation Protocol (SIP)",
	April 2004.		BCP 85, RFC 3725, April 2004.
	[7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	"RTP: A Transport Protocol for Real-Time Applications", STD 64,		Jacobson, "RTP: A Transport Protocol for Real-Time
	RFC 3550, July 2003.		Applications", STD 64, RFC 3550, July 2003.
	[8] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control		[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
	Protocol (BFCP)", RFC 4582, November 2006.		Control Protocol (BFCP)", RFC 4582, November 2006.
	[9] Camarillo, G., "Session Description Protocol (SDP) Format for		[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
	Binary Floor Control Protocol (BFCP) Streams", RFC 4583,		for Binary Floor Control Protocol (BFCP) Streams",
	November 2006.		RFC 4583, November 2006.
	[10] Levin, O. and G. Camarillo, "The Session Description Protocol		[RFC4574] Levin, O. and G. Camarillo, "The Session Description
	(SDP) Label Attribute", RFC 4574, August 2006.		Protocol (SDP) Label Attribute", RFC 4574, August 2006.
	[11] Boulton, C., "A Control Framework for the Session Initiation		[I-D.ietf-mediactrl-sip-control-framework]
	Protocol (SIP)", draft-ietf-mediactrl-sip-control-framework-00		Boulton, C., Melanchuk, T., and S. McGlashan, "Media
	(work in progress), September 2007.		Control Channel Framework",
			draft-ietf-mediactrl-sip-control-framework-02 (work in
			progress), April 2008.
	[12] Boulton, C., Melanchuk, T., and S. McGlashan, "A Basic		[I-D.ietf-mediactrl-ivr-control-package]
	Interactive Voice Response (IVR) Control Package for the		McGlashan, S., Melanchuk, T., and C. Boulton, "An
	Session Initiation Protocol (SIP)",		Interactive Voice Response (IVR) Control Package for the
	draft-boulton-ivr-control-package-05 (work in progress),		Media Control Channel Framework",
	November 2007.		draft-ietf-mediactrl-ivr-control-package-00 (work in
			progress), June 2008.
	[13] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A		[I-D.ietf-mediactrl-mixer-control-package]
	Conference Control Package for the Session Initiation Protocol		Melanchuk, T., McGlashan, S., and C. Boulton, "A Mixer
	(SIP)", draft-boulton-conference-control-package-03 (work in		Control Package for the Media Control Channel Framework",
	progress), November 2007.		draft-ietf-mediactrl-mixer-control-package-00 (work in
			progress), July 2008.
	[14] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A		[I-D.boulton-ivr-vxml-control-package]
	VoiceXML Interactive Voice Response (IVR) Control Package for		Boulton, C., Melanchuk, T., and S. McGlashan, "A VoiceXML
	the Session Initiation Protocol (SIP)",		Control Package for the Media Control Channel Framework",
	draft-boulton-ivr-vxml-control-package-03 (work in progress),		draft-boulton-ivr-vxml-control-package-04 (work in
	November 2007.		progress), February 2008.
	Authors' Addresses		Authors' Addresses
	Lorenzo Miniero		Lorenzo Miniero
	University of Napoli		University of Napoli
	Via Claudio 21		Via Claudio 21
	Napoli 80125		Napoli 80125
	Italy		Italy
	Email: lorenzo.miniero@unina.it		Email: lorenzo.miniero@unina.it
	Alessandro Amirante		Simon Pietro Romano
	University of Napoli		University of Napoli
	Via Claudio 21		Via Claudio 21
	Napoli 80125		Napoli 80125
	Italy		Italy
	Email: alessandro.amirante@unina.it		Email: spromano@unina.it
	Tobia Castaldi		Roni Even
	University of Napoli		Polycom
	Via Claudio 21		94 Derech Em Hamoshavot
	Napoli 80125		Petach Tikva 49130
	Italy		Israel
	Email: tobia.castaldi@unina.it		Email: roni.even@polycom.co.il
	Simon Pietro Romano		Scott McGlashan
	University of Napoli		Hewlett-Packard
	Via Claudio 21		Gustav III:s boulevard 36
	Napoli 80125		Stockholm SE-16985
	Italy		Sweden
	Email: spromano@unina.it		Email: scott.mcglashan@hp.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	skipping to change at page 18, line 44 ¶		skipping to change at line 1010 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 109 change blocks.
	382 lines changed or deleted		607 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/