[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         L. Miniero
Internet-Draft                                               S P. Romano
Expires: January 9, 2009                            University of Napoli
                                                                 R. Even
                                                                 Polycom
                                                            S. McGlashan
                                                         Hewlett-Packard
                                                            July 8, 2008


  A Binary Floor Control Protocol (BFCP) Control Package for the Media
                       Control Channel Framework
                 draft-miniero-bfcp-control-package-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, 2009.

Abstract

   This document defines a Media Control Channel Framework 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
   Media Control Channel Framework.




Miniero, et al.          Expires January 9, 2009                [Page 1]


Internet-Draft            BFCP Control Package                 July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  Control Package Definition . . . . . . . . . . . . . . . . . .  4
     5.1.  Control Package Name . . . . . . . . . . . . . . . . . . .  5
     5.2.  Framework Message Usage  . . . . . . . . . . . . . . . . .  5
     5.3.  Common XML Support . . . . . . . . . . . . . . . . . . . .  6
     5.4.  CONTROL Message Body . . . . . . . . . . . . . . . . . . .  6
     5.5.  REPORT Message Body  . . . . . . . . . . . . . . . . . . .  6
     5.6.  Audit  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Floors Manipulation  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Element Definitions  . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  <mscbfcp>  . . . . . . . . . . . . . . . . . . . . . . . .  9
       7.1.1.  Shared elements  . . . . . . . . . . . . . . . . . . . 10
       7.1.2.  Requests . . . . . . . . . . . . . . . . . . . . . . . 11
       7.1.3.  Responses  . . . . . . . . . . . . . . . . . . . . . . 17
       7.1.4.  Notifications  . . . . . . . . . . . . . . . . . . . . 18
     7.2.  Audit Elements . . . . . . . . . . . . . . . . . . . . . . 19
       7.2.1.  <audit>  . . . . . . . . . . . . . . . . . . . . . . . 19
       7.2.2.  <auditresponse>  . . . . . . . . . . . . . . . . . . . 19
   8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 19
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   12. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 19
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 23



















Miniero, et al.          Expires January 9, 2009                [Page 2]


Internet-Draft            BFCP Control Package                 July 2008


1.  Introduction

   The Media Control Channel Framework
   [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) [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) [RFC4582].


2.  Conventions

   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 [RFC2119] and indicate requirement
   levels for compliant implementations.


3.  Terminology

   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

   The Media Control Channel Framework
   [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) [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



Miniero, et al.          Expires January 9, 2009                [Page 3]


Internet-Draft            BFCP Control Package                 July 2008


   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
   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 [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 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.

   Considering users are added by the AS to the MS by means of a 3PCC
   [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
   properly interact with a floor control server.  To achieve this,
   RFC4583 [RFC4583] provides with a way to negotiate BFCP connections
   within the context of a SDP offer/answer [RFC3264].


5.  Control Package Definition

   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
   [I-D.ietf-mediactrl-sip-control-framework].






Miniero, et al.          Expires January 9, 2009                [Page 4]


Internet-Draft            BFCP Control Package                 July 2008


5.1.  Control Package Name

   The Control Framework requires a Control Package definition to
   specify and register a unique name and version.

   The name and version of this Control Package is "msc-bfcp/1.0" (Media
   Server Control - Binary Floor Control - version 1.0).

5.2.  Framework Message Usage

   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.  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 7 and provides an XML
   Schema in Section 9.  Additionally, some examples are provided in
   Section 8.

   The XML elements in this package are split into requests, responses
   and event notifications, all of which are contained within a root
   <mscbfcp> element.  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 instead carried in CONTROL
   message bodies; the <event> element is defined for package event
   notifications.  Event subscription is accomplished by means of the
   <subscribe> element.

   Note that package responses are different from framework response
   codes.  Framework error response codes (see Section 8 of
   [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 Section 7.1.3.1.

   The schema uses the "connection-id" and "conf-id" attributes which
   are imported from the schema defined in the core Control Framework
   [I-D.ietf-mediactrl-sip-control-framework].






Miniero, et al.          Expires January 9, 2009                [Page 5]


Internet-Draft            BFCP Control Package                 July 2008


5.3.  Common XML Support

   The Control Framework requires a Control Package definition to
   specify if the attributes for media dialog or conference references
   are required.

   This package requires that the XML Schema in Section 17.1 of
   [I-D.ietf-mediactrl-sip-control-framework] MUST be supported for
   media dialogs and conferences.

5.4.  CONTROL Message Body

   The Control Framework requires a Control Package to define the
   control body that can be contained within a CONTROL command request
   and to indicate the location of detailed syntax definitions and
   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

   A valid REPORT body MUST conform to the schema defined in Section 9
   and described in Section 7.  XML messages appearing in REPORT
   messages MUST contain a <response> (Section 7.1.3.1), or a
   (notification) <event> element (Section 7.1.4.2).

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.



Miniero, et al.          Expires January 9, 2009                [Page 6]


Internet-Draft            BFCP Control Package                 July 2008


   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



Miniero, et al.          Expires January 9, 2009                [Page 7]


Internet-Draft            BFCP Control Package                 July 2008


   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.




Miniero, et al.          Expires January 9, 2009                [Page 8]


Internet-Draft            BFCP Control Package                 July 2008


   [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.]

7.1.  <mscbfcp>

   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,
      associated with an existing framework conference instance to
      moderate - see Section 7.1.2.1 for details;

   <unmoderateconference>:  destroy a BFCP conference, thus stopping the
      moderation of the associated framework conference instance - see
      Section 7.1.2.2 for details;

   <addfloor>:  add and configure a new floor to an existing BFCP
      conference - see Section 7.1.2.3 for details;

   <modifyfloor>:  modify the configuration of a currently handled floor
      in an existing BFCP conference - see Section 7.1.2.4 for details;

   <removefloor>:  remove a currently handled floor from an existing
      BFCP conference - see Section 7.1.2.5 for details;

   <addparticipant>:  add a floor participant to a BFCP conference - see
      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
      conference - see Section 7.1.2.8 for details.

   <response>:  response to a floor control request - see Section 7.1.3
      for details.






Miniero, et al.          Expires January 9, 2009                [Page 9]


Internet-Draft            BFCP Control Package                 July 2008


   <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.





Miniero, et al.          Expires January 9, 2009               [Page 10]


Internet-Draft            BFCP Control Package                 July 2008


   <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







Miniero, et al.          Expires January 9, 2009               [Page 11]


Internet-Draft            BFCP Control Package                 July 2008


7.1.2.1.  <moderateconference>

   <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.

   The <moderateconference> element has the following attributes:

   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.

   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>), and in actual BFCP protocol contents as
      well, and as such MUST adhere to the syntax defined in [RFC4582].
      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.

   Additionally, to configure the new BFCP conference, the
   <moderateconference> element has the following child elements
   defined:

   <floor>:  an element (Section 7.1.1.1) to configure a floor in the
      new BFCP conference (see Section 7.1.1.1 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 Section 7.1.2.3).  This element is
      optional.

   <subscribe>:  an element to request subscription to conference
      events. (see Section 7.1.4.1 for more details).  This element is
      optional.

   Multiple <floor> elements may be defined, in case several floors are
   needed.

   When a MS has finished processing a <moderateconference> request, it
   MUST reply with an appropriate <response> element (Section 7.1.3).







Miniero, et al.          Expires January 9, 2009               [Page 12]


Internet-Draft            BFCP Control Package                 July 2008


7.1.2.2.  <unmoderateconference>

   <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
   [I-D.ietf-mediactrl-mixer-control-package].

   The <unmoderateconference> element has the following attributes:

   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.

   The <unmoderateconference> element does not specify any child
   elements.

   When a MS has finished processing an <unmoderateconference> request,
   it MUST reply with an appropriate <response> element
   (Section 7.1.3.1).

7.1.2.3.  <addfloor>

   <addfloor> is used in a request by the AS to add one or more floors
   to an existing BFCP conference instance.

   The <addfloor> element has the following attributes:

   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.

   Additionally, to configure the new floor(s), the <addfloor> element
   has the following child elements defined:

   <floor>:  an element to configure a new floor in the specified BFCP
      conference (see Section 7.1.1.1 for more details).  This element
      is mandatory.

   Multiple <floor> elements may be defined, in case several floors are
   to be added at the same time.

   When a MS has finished processing an <addfloor> request, it MUST



Miniero, et al.          Expires January 9, 2009               [Page 13]


Internet-Draft            BFCP Control Package                 July 2008


   reply with an appropriate <response> element (Section 7.1.3.1).

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
   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 [I-D.ietf-mediactrl-mixer-control-package].

   The <removefloor> element has the following attributes:







Miniero, et al.          Expires January 9, 2009               [Page 14]


Internet-Draft            BFCP Control Package                 July 2008


   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.

   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.

   The <removefloor> element does not specify any child elements.

   When a MS has finished processing a <removefloor> request, it MUST
   reply with an appropriate <response> element (Section 7.1.3.1).

7.1.2.6.  <addparticipant>

   <addparticipant> is used in a request by the AS to add a new BFCP
   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 <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.



Miniero, et al.          Expires January 9, 2009               [Page 15]


Internet-Draft            BFCP Control Package                 July 2008


   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
      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-user-id:  string indicating the name of the BFCP participant
      whose settings must be modified.  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.

   Additionally, to modify the configuration of the participant, the
   <modifyparticipant> element has the following child elements defined:

   <participant>:  an element to configure the specified participant in
      the specified BFCP conference (see Section 7.1.1.2 for more
      details).  This element is mandatory.

   It is an error if the provided <participant> element conflicts with
   the BFCP participant identifier attribute.

   When a MS has finished processing a <modifyparticipant> request, it
   MUST reply with an appropriate <response> element (Section 7.1.3.1).

7.1.2.8.  <removeparticipant>

   <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..

   The <removeparticipant> element has the following attributes:




Miniero, et al.          Expires January 9, 2009               [Page 16]


Internet-Draft            BFCP Control Package                 July 2008


   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.

   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
   <response> element.  This element may be contained in the body either
   of a REPORT framework message or in a 200 framework message.

7.1.3.1.  <response>

   Reponses to requests are indicated by a <response> element.

   The <response> element has the following attributes:

   status:  numeric code indicating the response status.  This attribute
      is mandatory.

   reason:  string specifying a human readable description of the reason
      for the response status.  This attribute is optional.

   bfcp-conf-id:  string identifying the BFCP conference the request
      referred to.  This attribute is optional.

   bfcp-floor-id:  string identifying the BFCP floor the request
      referred to.  This attribute is optional.

   The following status codes are defined:









Miniero, et al.          Expires January 9, 2009               [Page 17]


Internet-Draft            BFCP Control Package                 July 2008


                          +------+-------------+
                          | code | description |
                          +------+-------------+
                          | 200  | OK          |
                          | 4xx  | whatever    |
                          +------+-------------+

                     Table 1: <response> Status codes

   TBD.  Add all error codes and their meanings

7.1.4.  Notifications

   In case the AS is interested in receiving events regarding a BFCP
   conference, a notification mechanism is provided in the package.  The
   AS 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.

7.1.4.1.  <subscribe>

   BFCP event notifications are defined when an AS subscribes to
   notifications for BFCP-related events using the <subscribe> element
   in a <moderateconference> request.

   The <subscribe> element has no attributes, but has the following
   child elements defined:

   <notify>:  contains the following attributes:
      name:  a string indicating the name of the event to be notified.
         This attribute is mandatory.

   Multiple <notify> elements may be specified.

   The MS would then use the <event> element to send notifications to
   the AS.

7.1.4.2.  <event>

   Delivery of events the AS subscribed for is accomplished by means of
   an <event> element.

   The <event> element has the following attributes:







Miniero, et al.          Expires January 9, 2009               [Page 18]


Internet-Draft            BFCP Control Package                 July 2008


   name:  string indicating the name of the BFCP event.  This attribute
      is mandatory.

   bfcp-conf-id:  string identifying the BFCP conference the event
      happened in.  This attribute is mandatory.

   Additionally, to provide the AS with details upon the event, the
   <event> element has the following child elements defined:

   TBD.  Elaborate the notification mechanism.

7.2.  Audit Elements

7.2.1.  <audit>

   TBD.

7.2.2.  <auditresponse>

   TBD.


8.  Examples

   TBD.


9.  Formal Syntax

   TBD.


10.  Security Considerations

   TBD.


11.  IANA Considerations

   TBD.


12.  Change Summary

   The following are the major changes between the -00 and the -01
   versions of the draft:





Miniero, et al.          Expires January 9, 2009               [Page 19]


Internet-Draft            BFCP Control Package                 July 2008


   o  updated references (mixer draft);

   o  updated authors;

   o  aligned syntax to the one used in msc-ivr and msc-mixer
      (<mscbfcp>);

   o  added placeholders for event notifications and auditing;

   o  added participant related methods, and moved floor related
      discussions;


13.  Acknowledgements

   TBD.


14.  References

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.




Miniero, et al.          Expires January 9, 2009               [Page 20]


Internet-Draft            BFCP Control Package                 July 2008


   [RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
              Control Protocol (BFCP)", RFC 4582, November 2006.

   [RFC4583]  Camarillo, G., "Session Description Protocol (SDP) Format
              for Binary Floor Control Protocol (BFCP) Streams",
              RFC 4583, November 2006.

   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
              Protocol (SDP) Label Attribute", RFC 4574, August 2006.

   [I-D.ietf-mediactrl-sip-control-framework]
              Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework",
              draft-ietf-mediactrl-sip-control-framework-02 (work in
              progress), April 2008.

   [I-D.ietf-mediactrl-ivr-control-package]
              McGlashan, S., Melanchuk, T., and C. Boulton, "An
              Interactive Voice Response (IVR) Control Package for the
              Media Control  Channel Framework",
              draft-ietf-mediactrl-ivr-control-package-00 (work in
              progress), June 2008.

   [I-D.ietf-mediactrl-mixer-control-package]
              Melanchuk, T., McGlashan, S., and C. Boulton, "A Mixer
              Control Package for the Media Control Channel Framework",
              draft-ietf-mediactrl-mixer-control-package-00 (work in
              progress), July 2008.

   [I-D.boulton-ivr-vxml-control-package]
              Boulton, C., Melanchuk, T., and S. McGlashan, "A VoiceXML
              Control Package for the Media Control Channel Framework",
              draft-boulton-ivr-vxml-control-package-04 (work in
              progress), February 2008.


Authors' Addresses

   Lorenzo Miniero
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   Email: lorenzo.miniero@unina.it






Miniero, et al.          Expires January 9, 2009               [Page 21]


Internet-Draft            BFCP Control Package                 July 2008


   Simon Pietro Romano
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   Email: spromano@unina.it


   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva  49130
   Israel

   Email: roni.even@polycom.co.il


   Scott McGlashan
   Hewlett-Packard
   Gustav III:s boulevard 36
   Stockholm  SE-16985
   Sweden

   Email: scott.mcglashan@hp.com


























Miniero, et al.          Expires January 9, 2009               [Page 22]


Internet-Draft            BFCP Control Package                 July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Miniero, et al.          Expires January 9, 2009               [Page 23]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/