One document matched: draft-miniero-bfcp-control-package-00.xml

<?xml version="1.0"?> 

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> 

<?rfc toc="yes" ?> 

<?rfc compact="yes" ?> 

<?rfc sortrefs="no" ?>

<rfc ipr="full3978" docName="draft-miniero-bfcp-control-package-00.txt">

<front>
	<title abbrev="BFCP Control Package">
		A Binary Floor Control Protocol (BFCP) Control Package for the Session Initiation Protocol (SIP)
	</title>

	<author initials="L." surname="Miniero" fullname="Lorenzo Miniero">
		<organization>University of Napoli</organization>
		<address>
			<postal>
				<street>Via Claudio 21</street>
				<code>80125</code> 
				<city>Napoli</city> 
				<country>Italy</country>
			</postal>
			<email>lorenzo.miniero@unina.it</email>
		</address>
	</author>
	
	<author initials="A." surname="Amirante" fullname="Alessandro Amirante">
		<organization>University of Napoli</organization>
		<address>
			<postal>
				<street>Via Claudio 21</street>
				<code>80125</code> 
				<city>Napoli</city> 
				<country>Italy</country>
			</postal>
			<email>alessandro.amirante@unina.it</email>
		</address>
	</author>
	
	<author initials="T." surname="Castaldi" fullname="Tobia Castaldi">
		<organization>University of Napoli</organization>
		<address>
			<postal>
				<street>Via Claudio 21</street>
				<code>80125</code> 
				<city>Napoli</city> 
				<country>Italy</country>
			</postal>
			<email>tobia.castaldi@unina.it</email>
		</address>
	</author>
	
	<author initials="S P" surname="Romano" fullname="Simon Pietro Romano">
		<organization>University of Napoli</organization>
		<address>
			<postal>
				<street>Via Claudio 21</street>
				<code>80125</code> 
				<city>Napoli</city> 
				<country>Italy</country>
			</postal>
			<email>spromano@unina.it</email>
		</address>
	</author>
	
	<date month="February" year="2008"/>
	<area>RAI</area>
	<workgroup>Network Working Group</workgroup>
	<keyword>MediaCtrl</keyword>
	<keyword>Media Server Control</keyword>
	<keyword>SIP Control Framework</keyword>
	<keyword>BFCP</keyword>
	
	<abstract>
		<t>
			This document defines a Session Initiation Protocol (SIP) Control Package for
			BFCP-based conference moderation. The control of
			Media Servers and their related resources in decomposed network
			architectures plays an important role in various Next Generation
			Networks. This Control Package aims at adding BFCP functionality
			to conferences using the SIP Control Framework.
		</t>
	</abstract>
	
</front>

<middle>
	
	<!-- Introduction -->
	<section title="Introduction" anchor="sec-intro">
		<t>
			The SIP Control Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/>
			provides a generic approach for establishment and reporting
			capabilities of remotely initiated commands. The Framework utilizes
			many functions provided by the Session Initiation Protocol
			(SIP) <xref target="RFC3261"/> for the rendezvous and establishment of a reliable channel for
			control interactions. The Control Framework also introduces the
			concept of a Control Package. A Control Package is an explicit usage
			of the Control Framework for a particular interaction set. This
			specification defines a package for floor control in conferences based
			on the use of the Binary Floor Control Protocol (BFCP) <xref target="RFC4582"/>.
		</t>
	</section>
	
	<!-- Conventions -->
	<section title="Conventions" anchor="sec-conv">
		<t>
			In this document, the key words "MUST", "MUST NOT", "REQUIRED",
			"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
			RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
			described in BCP 14, RFC 2119 <xref target="RFC2119"/> and
			indicate requirement levels for compliant implementations.
		</t>
	</section>
	
	<!-- Terminology -->
	<section title="Terminology" anchor="sec-teminology">
		<t>
			TBD.
		</t>
		<!--
		<list style="hanging">
			<vspace blankLines='1'/>
			<t hangText="Application Server:">
				<vspace blankLines='1'/>
			</t>
			<vspace blankLines='1'/>
			<t hangText="Media Server:">
				<vspace blankLines='1'/>
			</t>
		</list>
		-->
	</section>
	
	<!-- Overview -->
	<section title="Overview" anchor="sec-overview">
		<t>
			The SIP Control Framework <xref target="I-D.ietf-mediactrl-sip-control-framework"/>
			provides a generic approach for establishment and reporting
			capabilities of remotely initiated commands. The Framework utilizes
			many functions provided by the Session Initiation Protocol
			(SIP) <xref target="RFC3261"/> for the rendezvous and establishment of a reliable channel for
			control interactions. The Control Framework also introduces the
			concept of a Control Package. A Control Package is an explicit usage
			of the Control Framework for a particular interaction set. This
			specification defines a package for floor control in conferences based
			on the use of the Binary Floor Control Protocol (BFCP) <xref target="RFC4582"/>.
		</t>
		<t>
			Floor control is needed whenever access to a resource, or set of 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 would first have to place
			a request concerning the floor associated with such audio resource.
			The participant would then be added to the conference mix only when his
			request has been granted, by the server itself or by a designated chair.
			RFC4582 <xref target="RFC4582"/> defines a Binary Floor Control Protocol (BFCP)
			to specifically deal with such a need. It defines all the relevant entities
			(floors, queues, requests) and related actors (floor control servers, participants and chairs).
			So, the scope of this package is adding BFCP-based floor control functionality
			to complementary packages that might need it, as the Conference Control Package
			<xref target="I-D.boulton-conference-control-package"/>.
		</t>
		<t>
			In particular, this package aims at dealing with the case where the Floor Control Server (FCS),
			as defined in <xref target="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 consequently out of scope for the MS.
			Considering users are added by the AS to the MS by means of a 3PCC
			<xref target="RFC3725"/> mechanism, a way to include BFCP negotiation
			is needed. In fact, users willing to act as floor participants will need
			to be made aware of all the relevant identifiers (i.e. the transport
			address of the floor control server, the BFCP conference
			ID associated with the mix, the BFCP user ID the user has been assigned,
			all the floor identifiers and their mapping with existing resources, and
			so on) to opportunely interact with a floor control server.
			To achieve this, RFC4583 <xref target="RFC4582"/> provides with
			a way to negotiate BFCP connections within the context of a
			SDP offer/answer <xref target="RFC3264"/>.
		</t>
	</section>
	
	<!-- Control Package Definition -->
	<section title="Control Package Definition" anchor="sec-ctrlpkg">
		<t>
			This section fulfills the mandatory requirement for information that
			MUST be specified during the definition of a Control Framework
			Package, as detailed in Section 9 of
			<xref target="I-D.ietf-mediactrl-sip-control-framework"/>.

		</t>
		<section title="Control Package Name" anchor="sec-ctrlpkg-name">
			<t>
				<t>The Control Framework requires a Control Package definition to
				specify and register a unique name and version.</t>
				
				<t>The name and version of this Control Package is "msc-conf-bfcp/1.0"
				(Media Server Control - Conferencing - BFCP - version 1.0 ).</t>

			</t>
		</section>
		<section title="Framework Message Usage" anchor="sec-ctrlpkg-msg">
			<t>
				BFCP functionality includes several different capabilities.
				There must be means to appropriately create, modify and
				destroy each of the available resources. This includes means
				to create a BFCP conference with specified settings,
				adding and removing floors to the conference, setting
				or unsetting designated chairs for such floors and so on.
			</t>
			<t>
				This package defines XML elements in <xref target="sec-element"/>
				and provides an XML Schema in <xref target="sec-syntax"/>.
				Additionally, some examples are provided in <xref target="sec-examples"/>.
			</t>
			<t>
				The XML elements in this package are split into requests, responses
				and event notifications. Requests are carried in CONTROL message
				bodies; <moderateconference> and <addfloor> elements
				are examples of package requests. Responses are carried either in
				REPORT message or Control Framework 200 response bodies; the
				<response> element is defined as a package response. Event
				notifications are also carried in REPORT message bodies; the <event>
				element is defined for package event notifications. Event subscription
				is accomplished by means of the <subscribe> element.
			</t>
			<t>
				Note that package responses are different from framework response
				codes. Framework error response codes (see Section 8 of
				<xref target="I-D.ietf-mediactrl-sip-control-framework"/>)
				are used when the request or event notification is invalid; for example,
				a request is invalid XML (400), or not understood (500). Package
				responses are carried in 200 response or REPORT message bodies. This
				package's response codes are defined in <xref target="sec-response"/>.
			</t>
			<t>
				The schema uses the "connection-id" and "conf-id" attributes
				which are imported from the schema defined in the core Control Framework
				<xref target="I-D.ietf-mediactrl-sip-control-framework"/>.
			</t>
		</section>
		<section title="Common XML Support" anchor="sec-ctrlpkg-xml">
			<t>
				The Control Framework requires a Control Package definition to
				specify if the attributes for media dialog or conference references
				are required.
			</t>
			<t>
				This package requires that the XML Schema in Section 16.1 of
				<xref target="I-D.ietf-mediactrl-sip-control-framework"/>
				MUST be supported for media dialogs and conferences.
			</t>
		</section>
		<section title="CONTROL Message Body" anchor="sec-ctrlpkg-control">
			<t>
				A valid CONTROL body message MUST conform to the schema defined in
				<xref target="sec-syntax"/> and described in <xref target="sec-element"/>.
				XML messages appearing in CONTROL messages MUST contain one of the
				elements described in <xref target="sec-requests"/>.

			</t>
		</section>
		<section title="REPORT Message Body" anchor="sec-ctrlpkg-report">
			<t>
				A valid REPORT body MUST conform to the schema defined in
				<xref target="sec-syntax"/> and described in <xref target="sec-element"/>.
				XML messages appearing in REPORT messages MUST contain a <response>
				(<xref target="sec-response"/>), or a (notification)
				<event> element (<xref target="sec-event"/>).
			</t>
		</section>
	</section>
	
	<!-- Element Definitions -->
	<section title="Element Definitions" anchor="sec-element">
		<t>
			This section defines the XML messages for this control package.
		</t>
		<t>
			[Editors Note: since XML Schema may not be able to express all
			constraints expressed in these definitions, in cases where there is a
			difference in constraints, the definitions in the section take
			priority.]
		</t>
		<section title="Requests" anchor="sec-requests">
			<t>
				The following request elements are defined:
			</t>
			<t>
				<list style="hanging">
					<t hangText="<moderateconference>:">
						create and configure a new BFCP conference, associated with
						an existing framework conference instance to moderate - see
						<xref target="sec-moderate"/> for details;
					</t>
					<vspace blankLines='1'/>
					<t hangText="<unmoderateconference>:">
						destroy a BFCP conference, thus stopping the moderation
						of the associated framework conference instance - see
						<xref target="sec-unmoderate"/> for details;
					</t>
					<vspace blankLines='1'/>
					<t hangText="<addfloor>:">
						add and configure a new floor to an existing
						BFCP conference - see
						<xref target="sec-addfloor"/> for details;
					</t>
					<vspace blankLines='1'/>
					<t hangText="<modifyfloor>:">
						modify the configuration of a currently handled floor
						in an existing BFCP conference - see
						<xref target="sec-modifyfloor"/> for details;
					</t>
					<vspace blankLines='1'/>
					<t hangText="<removefloor>:">
						remove a currently handled floor from
						an existing BFCP conference - see
						<xref target="sec-removefloor"/> for details;
					</t>
					<vspace blankLines='1'/>
					<t hangText="<addparticipant>:">
						add a floor participant to a BFCP conference - see
						<xref target="sec-addparticipant"/> for details;
					</t>
					<vspace blankLines='1'/>
					<t hangText="<removeparticipant>:">
						remove a floor participant from a BFCP conference - see
						<xref target="sec-removeparticipant"/> for details.
					</t>
				</list>
			</t>
			<section title="<moderateconference>" anchor="sec-moderate">
				<t>
					<moderateconference> is used in a request by the AS
					to moderate an existing conference instance, by associating
					to it a new, properly configured, BFCP conference.
				</t>
				<t>
					The <moderateconference> element has the following
					attributes:
				</t>
				<t>
					<list style="hanging">
						<t hangText="conf-id:">
							string indicating the name of the conference
							to moderate. 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.
						</t>
						<vspace blankLines='1'/>
						<t hangText="bfcp-conf-id:">
							string (an unsigned integer) indicating a unique name
							for the BFCP conference. If this attribute is not specified,
							the MS creates a unique name for the BFCP conference. The
							value is used in subsequent references to the conference
							(e.g. as bfcp-conf-id in a <response>). When present
							in a <moderateconference> request, the new value of
							this attribute MUST be unique or else a 403 'Conference
							already exists' package level error will be reported.
							The attribute is optional.
						</t>
					</list>
				</t>
				<t>
					Additionally, to configure the new BFCP conference, the <moderateconference>
					element has the following child elements defined:
				</t>
				<t>
					<list style="hanging">
						<t hangText="<floor>:">
							an element to configure a floor in the new BFCP conference
							(see <xref target="sec-floor"/> for more details). This element
							only refers to floors already available at creation time.
							New floors can still be added subsequently by means of
							an <addfloor> request (see <xref target="sec-addfloor"/>).
							This element is optional.
						</t>
						<vspace blankLines='1'/>
						<t hangText="<subscribe>:">
							an element to request subscription to conference
							events. (see <xref target="sec-subscribe"/> for more details).
							This element is optional.
						</t>
					</list>
				</t>
				<t>
					Multiple <floor> elements may be defined, in case several
					floors are needed.
				</t>
				<t>
					When a MS has finished processing a <moderateconference>
					request, it MUST reply with an appropriate <response> element
					(<xref target="sec-response"/>).
				</t>
			</section>
			<section title="<unmoderateconference>" anchor="sec-unmoderate">
				<t>
					<unmoderateconference> is used in a request by the AS
					to destroy a BFCP conference, thus stopping the moderatation
					of the associated existing framework conference instance. A
					successful processing of this request does NOT result in a
					destruction of the associated media conference: it only
					results in the media conference not being moderated by means
					of BFCP anymore. The actual destruction of the media conference
					itself is accomplished through the means provided in
					<xref target="I-D.boulton-conference-control-package"/>.
				</t>
				<t>
					The <unmoderateconference> element has the following
					attributes:
				</t>
				<t>
					<list style="hanging">
						<t hangText="bfcp-conf-id:">
							string indicating the name of the BFCP conference
							to destroy. 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.
						</t>
					</list>
				</t>
				<t>
					The <unmoderateconference> element does not specify
					any child elements.
				</t>
				<t>
					When a MS has finished processing an <unmoderateconference>
					request, it MUST reply with an appropriate <response> element
					(<xref target="sec-response"/>).
				</t>
			</section>
			<section title="<addfloor>" anchor="sec-addfloor">
				<t>
					<addfloor> is used in a request by the AS to add one or
					more floors to an existing BFCP conference instance.
				</t>
				<t>
					The <addfloor> element has the following
					attributes:
				</t>
				<t>
					<list style="hanging">
						<t hangText="bfcp-conf-id:">
							string indicating the name of the BFCP conference
							to add the floor(s) 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.
						</t>
					</list>
				</t>
				<t>
					Additionally, to configure the new floor(s), the <addfloor>
					element has the following child elements defined:
				</t>
				<t>
					<list style="hanging">
						<t hangText="<floor>:">
							an element to configure a new floor in the specified BFCP conference
							(see <xref target="sec-floor"/> for more details).
							This element is mandatory.
						</t>
					</list>
				
					Multiple <floor> elements may be defined, in case several
					floors are to be added at the same time.
				</t>
				<t>
					When a MS has finished processing a <addfloor>
					request, it MUST reply with an appropriate <response> element
					(<xref target="sec-response"/>).
				</t>
			</section>
			<section title="<modifyfloor>" anchor="sec-modifyfloor">
				<t>
					<removefloor> is used in a request by the AS to remove
					an existing floor from the BFCP conference instance it is in.
					A successful 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 not being moderated by means
					of BFCP anymore. The actual destruction of the resource (in
					case it is directly handled and manipulated by the MS itself)
					is accomplished through the means provided in
					<xref target="I-D.boulton-conference-control-package"/>.
				</t>
				<t>
					The <removefloor> element has the following
					attributes:
				</t>
				<t>
					<list style="hanging">
						<t hangText="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.
						</t>
						<vspace blankLines='1'/>
						<t hangText="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 404 'Floor does not
							exist' package level error will be generated.
							This attribute is mandatory.
						</t>
					</list>
				</t>
				<t>
					The <removefloor> element does not specify
					any child elements.
				</t>
				<t>
					When a MS has finished processing a <removefloorfloor>
					request, it MUST reply with an appropriate <response> element
					(<xref target="sec-response"/>).
				</t>
			</section>
			<section title="<removefloor>" anchor="sec-removefloor">
				<t>
					<modifyfloor> is used in a request by the AS to modify
					the configuration of a floor in an existing BFCP conference instance.
				</t>
				<t>
					The <modifyfloor> element has the following
					attributes:
				</t>
				<t>
					<list style="hanging">
						<t hangText="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.
						</t>
						<vspace blankLines='1'/>
						<t hangText="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.
						</t>
					</list>
				</t>
				<t>
					Additionally, to modify the configuration of the floor, the <modifyfloor>
					element has the following child elements defined:
				</t>
				<t>
					<list style="hanging">
						<t hangText="<floor>:">
							an element to configure the specified floor in the specified BFCP conference
							(see <xref target="sec-floor"/> for more details).
							This element is mandatory.
						</t>
					</list>
				</t>
				<t>
					It is an error if the provided <floor> element
					conflicts with the BFCP floor identifier attribute.
				</t>
				<t>
					When a MS has finished processing a <modifyfloor>
					request, it MUST reply with an appropriate <response> element
					(<xref target="sec-response"/>).
				</t>
			</section>
			<section title="<addparticipant>" anchor="sec-addparticipant">
				<t>
					TBD. (is this really needed? there's RFC4583 for that...)
				</t>
			</section>
			<section title="<removeparticipant>" anchor="sec-removeparticipant">
				<t>
					TBD. (is this really needed? there's RFC4583 for that...)
				</t>
			</section>
		</section>
		<section title="Responses" anchor="sec-responses">
			<t>
				All responses to the previously described requests
				are specified in a <response> element. This element
				may be contained in the body either of a REPORT framework message
				or in a 200 framework message.
			</t>
			<section title="<response>" anchor="sec-response">
				<t>
					Reponses to requests are indicated by a <response>
					element.
				</t>
				<t>
					The <response> element has the
					following attributes:
				</t>
				<t>
					<list style="hanging">
						<t hangText="status:">
							numeric code indicating the response status.
							This attribute is mandatory.
						</t>
						<vspace blankLines='1'/>
						<t hangText="reason:">
							string specifying a human readable description
							of the reason for the response status.
							This attribute is optional.
						</t>
						<vspace blankLines='1'/>
						<t hangText="bfcp-conf-id:">
							string identifying the BFCP conference the
							request referred to.
							This attribute is optional.
						</t>
						<vspace blankLines='1'/>
						<t hangText="bfcp-floor-id:">
							string identifying the BFCP floor the
							request referred to.
							This attribute is optional.
						</t>
					</list>
				</t>
				<t>
					The following status codes are defined:
				</t>
				<t>
					<texttable anchor="tab-error-codes" title="<response> Status codes">
						<ttcol align='left'>code</ttcol>
        					<ttcol align='left'>description</ttcol>
						<c>200</c><c>OK</c>
						<c>4xx</c><c>whatever</c>
					</texttable>
				</t>
				<t>
					TBD. Add all error codes and their meanings
				</t>
			</section>
		</section>
		<section title="Notifications" anchor="sec-notifications">
			<t>
				In case the a controlling client is interested in receiving events
				regarding a BFCP conference, a notification mechanism
				is provided in the package. The client requests subscription to
				such events by adding a <subscribe> child
				element to the <moderateconference> request,
				whereas the MS triggers the related events
				in subsequent REPORT messages. Event notifications
				are then delivered using the <event> element.
			</t>
			<section title="<subscribe>" anchor="sec-subscribe">
				<t>
					BFCP event notifications are defined when a
					controlling client subscribes to notifications
					for BFCP-related events using the <subscribe>
					element in a <moderateconference> request.
				</t>
				<t>
					The <subscribe> element has no attributes,
					but has the following child elements defined:
				</t>
				<t>
					<list style="hanging">
						<t hangText="<notify>:">
							contains the following attributes:
							<list style="hanging">
								<t hangText="name">
									a string indicating the name of the event
									to be notified. The attribute is mandatory.
								</t>
							</list>
						</t>
					</list>
				</t>
				<t>
					Multiple <notify> elements may be specified.
				</t>
				<t>
					The MS would then use the <event> element to send
					notifications to the controlling client.
				</t>
			</section>
			<section title="<event>" anchor="sec-event">
				<t>
					Delivery of events the AS subscribed for is accomplished
					by means of an <event> element.
				</t>
				<t>
					The <event> element has the following
					attributes:
				</t>
				<t>
					<list style="hanging">
						<t hangText="name:">
							string indicating the name of the BFCP event.
							This attribute is mandatory.
						</t>
						<vspace blankLines='1'/>
						<t hangText="bfcp-conf-id:">
							string identifying the BFCP conference the
							event happened in.
							This attribute is mandatory.
						</t>
					</list>
				</t>
				<t>
					Additionally, to provide the AS with details upon the event, the <event>
					element has the following child elements defined:
				</t>
				<t>
					<!--
					<list style="hanging">
						<t hangText="<data>:">
							an element to configure the specified floor in the specified BFCP conference
							(see <xref target="sec-floor"/> for more details).
							This element is mandatory.
						</t>
					</list>
					-->
					TBD. Elaborate the notification mechanism.
				</t>
			</section>
		</section>
		<section title="Floors Manipulation" anchor="sec-floors">
			<t>
				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).
			</t>
			<t>
				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:
			</t>
			<t>
				<figure anchor="fig-conf-audio" title="Audio Conference with labels">
					<artwork>
						<![CDATA[
                                 MS
                          +---------------+
            UAC A         |               |         UAC B
              o-----------+--x         x--+-----------o
                 a1b2c3   |               |   d4e5f6
                          |               |
                          |       x       |
                          |       |       |
                          +-------+-------+
                                  |
                                  |   g7h8i9
                                  |
                                  o
                                UAC C
						 ]]>
					</artwork>
				</figure>
			</t>
			<t>
				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
				<xref target="I-D.boulton-conference-control-package"/>,
				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 <xref target="RFC4583"/>.
				<xref target="fig-conf-bfcp"/> depicts such the case
				where all the participants have been attached to the
				mix.
			</t>
			<t>
				<figure anchor="fig-conf-bfcp" title="Audio Conference with labels and floors">
					<artwork>
						<![CDATA[
                                 MS
                          +---------------+
            UAC A         |               |         UAC B
              o-----------+--+~~>[ ]<~~+--+-----------o
                 a1b2c3   |       ^       |   d4e5f6
               (floor 11) |       |       | (floor 11)
                          |       +       |
                          |       |       |
                          +-------+-------+
                                  |
                                  |   g7h8i9
                                  | (floor 11)
                                  o
                                UAC C
						 ]]>
					</artwork>
				</figure>
			</t>
			<t>
				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).
			</t>
			<t>
				To achieve this, each floor, together with its configuration,
				is defined in the package by the <floor> element.
			</t>
			<section title="<floor>" anchor="sec-floor">
				<t>
					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.
				</t>
				<t>
					The <floor> element has the following
					attributes:
				</t>
				<t>
					<list style="hanging">
						<t hangText="bfcp-floor-id:">
							string indicating the name of the BFCP floor.
							This attribute is optional.
						</t>
						<vspace blankLines='1'/>
						<t hangText="<media>:">
							an element indicating the type of media associated with the
							floor, i.e. the resource associated with the floor, as
							defined in <xref target="I-D.boulton-conference-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.
						</t>
						<vspace blankLines='1'/>
						<t hangText="<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.
						</t>
						<vspace blankLines='1'/>
						<t hangText="<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.
						</t>
						<vspace blankLines='1'/>
						<t hangText="<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.
						</t>
					</list>
				</t>
				<t>
					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:
				</t>
				<t>
					<list style="hanging">
						<t hangText="<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.
						</t>
						<vspace blankLines='1'/>
						<t hangText="<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.
						</t>
					</list>
				</t>
				<t>
					TBD. Elaborate the floor mechanism.
				</t>
			</section>
		</section>
	</section>
	
	<!-- Examples -->
	<section title="Examples" anchor="sec-examples">
		<t>
			TBD.
		</t>
	</section>
	
	<!-- Formal Syntax -->
	<section title="Formal Syntax" anchor="sec-syntax">
		<t>
			TBD.
		</t>
	</section>
	
	<!-- Security Considerations -->
	<section title="Security Considerations" anchor="sec-security">
		<t>
			TBD.
		</t>
	</section>
	
	<!-- IANA -->
	<section title="IANA Considerations" anchor="sec-iana">
		<t>
			TBD.
		</t> 
	</section>
	
	<!-- Acknowledgements -->
	<section title="Acknowledgements" anchor="sec-acks">
		<t>
			TBD.
		</t> 
	</section>
	
</middle>

<back>
	<references title="References">
		<!-- BNF -->
		<?rfc include="reference.RFC.2234"?>
		<!-- Terminology -->
		<?rfc include="reference.RFC.2119"?>
		<!-- IANA Guidelines -->
		<?rfc include="reference.RFC.2434"?>
		<!-- SIP -->
		<?rfc include="reference.RFC.3261"?>
		<!-- SIP/SDP -->
		<?rfc include="reference.RFC.3264"?>
		<!-- 3PCC -->
		<?rfc include="reference.RFC.3725"?>
		<!-- RTP -->
		<?rfc include="reference.RFC.3550"?>
		<!-- BFCP -->
		<?rfc include="reference.RFC.4582"?>
		<!-- BFCP/SDP -->
		<?rfc include="reference.RFC.4583"?>
		<!-- Label -->
		<?rfc include="reference.RFC.4574"?>
		<!-- SIP Control Framework -->
		<?rfc include="reference.I-D.ietf-mediactrl-sip-control-framework"?>
		<!-- IVR package -->
		<?rfc include="reference.I-D.boulton-ivr-control-package"?>
		<!-- Conferencing package -->
		<?rfc include="reference.I-D.boulton-conference-control-package"?>
		<!-- VoiceXML package -->
		<?rfc include="reference.I-D.boulton-ivr-vxml-control-package"?>
		
	</references>
</back>

</rfc>

<!-- LocalWords: xref PPR PPA SAA RTA RTR LIR LIA CDATA -->