Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4582

The Binary Floor Control Protocol (BFCP)

Pages: 65
Obsoleted by:  8855
Updated by:  8996
Part 3 of 3 – Pages 37 to 65
First   Prev   None

Top   ToC   RFC4582 - Page 37   prevText

10. Floor Participant Operations

This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Section 11 specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and Section 12 specifies operations that can be performed by any client (i.e., both floor participants and floor chairs).

10.1. Requesting a Floor

A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server.
Top   ToC   RFC4582 - Page 38

10.1.1. Sending a FloorRequest Message

The ABNF in Section 5.3.1 describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor. Note that the name space for both the User ID and the Beneficiary ID is the same. That is, a given participant is identified by a single 16-bit value that can be used in the User ID in the common header and in several attributes: BENEFICIARY-ID, BENEFICIARY- INFORMATION, and REQUESTED-BY-INFORMATION. The floor participant must insert at least one FLOOR-ID attribute in the FloorRequest message. If the client inserts more than one FLOOR-ID attribute, the floor control server will treat all the floor requests as an atomic package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message. The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors are being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption. The floor participant may request that the server handle the floor request with a certain priority using a PRIORITY attribute.

10.1.2. Receiving a Response

A message from the floor control server is considered a response to the FloorRequest message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
Top   ToC   RFC4582 - Page 39
   The successful processing of a FloorRequest message at the floor
   control server involves generating one or several FloorRequestStatus
   messages.  The floor participant obtains a Floor Request ID in the
   Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in
   the first FloorRequestStatus message from the floor control server.
   Subsequent FloorRequestStatus messages from the floor control server
   regarding the same floor request will carry the same Floor Request ID
   in a FLOOR-REQUEST-INFORMATION attribute as the initial
   FloorRequestStatus message.  This way, the floor participant can
   associate subsequent incoming FloorRequestStatus messages with the
   ongoing floor request.

   The floor participant obtains information about the status of the
   floor request in the FLOOR-REQUEST-INFORMATION attribute of each of
   the FloorRequestStatus messages received from the floor control
   server.  This attribute is a grouped attribute, and as such it
   includes a number of attributes that provide information about the
   floor request.

   The OVERALL-REQUEST-STATUS attribute provides information about the
   overall status of the floor request.  If the Request Status value is
   Granted, all the floors that were requested in the FloorRequest
   message have been granted.  If the Request Status value is Denied,
   all the floors that were requested in the FloorRequest message have
   been denied.  A floor request is considered to be ongoing while it is
   in the Pending, Accepted, or Granted states.  If the floor request
   value is unknown, then the response is still processed.  However, no
   meaningful value can be reported to the user.

   The STATUS-INFO attribute, if present, provides extra information
   that the floor participant MAY display to the user.

   The FLOOR-REQUEST-STATUS attributes provide information about the
   status of the floor request as it relates to a particular floor.  The
   STATUS-INFO attribute, if present, provides extra information that
   the floor participant MAY display to the user.

   The BENEFICIARY-INFORMATION attribute identifies the beneficiary of
   the floor request in third-party floor requests.  The
   REQUESTED-BY-INFORMATION attribute need not be present in
   FloorRequestStatus messages received by the floor participant that
   requested the floor, as this floor participant is already identified
   by the User ID in the common header.

   The PRIORITY attribute, when present, contains the priority that was
   requested by the generator of the FloorRequest message.
Top   ToC   RFC4582 - Page 40
   If the response is an Error message, the floor control server could
   not process the FloorRequest message for some reason, which is
   described in the Error message.

10.2. Cancelling a Floor Request and Releasing a Floor

A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it.

10.2.1. Sending a FloorRelease Message

The ABNF in Section 5.3.2 describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. Note that the FloorRelease message is used to release a floor or floors that were granted and to cancel ongoing floor requests (from the protocol perspective, both are ongoing floor requests). Using the same message in both situations helps resolve the race condition that occurs when the FloorRelease message and the FloorGrant message cross each other on the wire. The floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling. Note that if the floor participant requested several floors as an atomic operation (i.e., in a single FloorRequest message), all the floors are released as an atomic operation as well (i.e., all are released at the same time).

10.2.2. Receiving a Response

A message from the floor control server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
Top   ToC   RFC4582 - Page 41
   If the response is a FloorRequestStatus message, the Request Status
   value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-
   REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.

   If the response is an Error message, the floor control server could
   not process the FloorRequest message for some reason, which is
   described in the Error message.

   It is possible that the FloorRelease message crosses on the wire with
   a FloorRequestStatus message from the server with a Request Status
   different from Cancelled or Released.  In any case, such a
   FloorRequestStatus message will not be a response to the FloorRelease
   message, as its Transaction ID will not match that of the
   FloorRelease.

11. Chair Operations

This section specifies how floor chairs can instruct the floor control server to grant or revoke a floor using the protocol elements described in earlier sections. Floor chairs that wish to send instructions to a floor control server do so by sending a ChairAction message.

11.1. Sending a ChairAction Message

The ABNF in Section 5.3.9 describes the attributes that a ChairAction message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor chair sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor chair sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message. For example, if a floor request consists of two floors that depend on different floor chairs, each floor chair will grant its floor within the floor request. Once both chairs have granted their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the floor chairs denies its floor, the floor
Top   ToC   RFC4582 - Page 42
   control server will deny the floor request as a whole, regardless of
   the other floor chair's decision.

   The floor chair provides the new status of the floor request as it
   relates to a particular floor using a FLOOR-REQUEST-STATUS attribute.
   If the new status of the floor request is Accepted, the floor chair
   MAY use the Queue Position field to provide a queue position for the
   floor request.  If the floor chair does not wish to provide a queue
   position, all the bits of the Queue Position field SHOULD be set to
   zero.  The floor chair SHOULD use the Status Revoked to revoke a
   floor that was granted (i.e., Granted status) and SHOULD use the
   Status Denied to reject floor requests in any other status (e.g.,
   Pending and Accepted).

   The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the
   ChairAction message to provide a new overall status for the floor
   request.  If the new overall status of the floor request is Accepted,
   the floor chair MAY use the Queue Position field to provide a queue
   position for the floor request.

      Note that a particular floor control server may implement a
      different queue for each floor containing all the floor requests
      that relate to that particular floor, a general queue for all
      floor requests, or both.  Also note that a floor request may
      involve several floors and that a ChairAction message may only
      deal with a subset of these floors (e.g., if a single floor chair
      is not authorized to manage all the floors).  In this case, the
      floor control server will combine the instructions received from
      the different floor chairs in FLOOR-REQUEST-STATUS attributes to
      come up with the overall status of the floor request.

      Note that, while the action of a floor chair may communicate
      information in the OVERALL-REQUEST-STATUS attribute, the floor
      control server may override, modify, or ignore this field's
      content.

   The floor chair may use STATUS-INFO attributes to state the reason
   why the floor or floors are being accepted, granted, or revoked.  The
   Text in the STATUS-INFO attribute is intended for human consumption.

11.2. Receiving a Response

A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1. On receiving such a response, the floor chair follows the rules in Section 9 that relate to floor control server authentication.
Top   ToC   RFC4582 - Page 43
   A ChairActionAck message from the floor control server confirms that
   the floor control server has accepted the ChairAction message.  An
   Error message indicates that the floor control server could not
   process the ChairAction message for some reason, which is described
   in the Error message.

12. General Client Operations

This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both.

12.1. Requesting Information about Floors

A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server.

12.1.1. Sending a FloorQuery Message

The ABNF in Section 5.3.7 describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. The client inserts in the message all the Floor IDs it wants to receive information about. The floor control server will send periodic information about all of these floors. If the client does not want to receive information about a particular floor any longer, it sends a new FloorQuery message removing the FLOOR-ID of this floor. If the client does not want to receive information about any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribute.

12.1.2. Receiving a Response

A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the
Top   ToC   RFC4582 - Page 44
   FloorRequest message, as described in Section 8.1.  On receiving such
   a response, the client follows the rules in Section 9 that relate to
   floor control server authentication.

   On reception of the FloorQuery message, the floor control server will
   respond with a FloorStatus message or with an Error message.  If the
   response is a FloorStatus message, it will contain information about
   one of the floors the client requested information about.  If the
   client did not include any FLOOR-ID attribute in its FloorQuery
   message (i.e., the client does not want to receive information about
   any floor any longer), the FloorStatus message from the floor control
   server will not include any FLOOR-ID attribute either.

   FloorStatus messages that carry information about a floor contain a
   FLOOR-ID attribute that identifies the floor.  After this attribute,
   FloorStatus messages contain information about existing (one or more)
   floor requests that relate to that floor.  The information about each
   particular floor request is encoded in a FLOOR-REQUEST-INFORMATION
   attribute.  This grouped attribute carries a Floor Request ID that
   identifies the floor request, followed by a set of attributes that
   provide information about the floor request.

   After the first FloorStatus, the floor control server will continue
   sending FloorStatus messages, periodically informing the client about
   changes on the floors the client requested information about.

12.2. Requesting Information about Floor Requests

A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server. Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request.
Top   ToC   RFC4582 - Page 45

12.2.1. Sending a FloorRequestQuery Message

The ABNF in Section 5.3.3 describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. The client must insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server.

12.2.2. Receiving a Response

A message from the floor control server is considered a response to the FloorRequestQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest the client requested information about in a FLOOR-REQUEST-INFORMATION attribute. If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message.

12.3. Requesting Information about a User

A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. This functionality may be useful for floor chairs or floor participants interested in the display name and the URI of a particular floor participant. In addition, a floor participant may find it useful to request information about itself. For example, a
Top   ToC   RFC4582 - Page 46
   floor participant, after experiencing connectivity problems (e.g.,
   its TCP connection with the floor control server was down for a while
   and eventually was re-established), may need to request information
   about all the floor requests associated to itself that still exist.

12.3.1. Sending a UserQuery Message

The ABNF in Section 5.3.5 describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. If the floor participant the client is requesting information about is not the client issuing the UserQuery message (which is identified by the User ID in the common header of the message), the client MUST insert a BENEFICIARY-ID attribute.

12.3.2. Receiving a Response

A message from the floor control server is considered a response to the UserQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the UserQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes. If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message.

12.4. Obtaining the Capabilities of a Floor Control Server

A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server.
Top   ToC   RFC4582 - Page 47

12.4.1. Sending a Hello Message

The ABNF in Section 5.3.11 describes the attributes that a Hello message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.

12.4.2. Receiving Responses

A message from the floor control server is considered a response to the Hello message by the client if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITVIES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server. If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message.

13. Floor Control Server Operations

This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections. On reception of a message from a client, the floor control server MUST check whether the value of the Primitive is supported. If it does not, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 3 (Unknown Primitive). On reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it does not, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 1 (Conference does not Exist).
Top   ToC   RFC4582 - Page 48
   On reception of a message from a client, the floor control server
   follows the rules in Section 9 that relate to the authentication of
   the message.

   On reception of a message from a client, the floor control server
   MUST check whether it understands all the mandatory ('M' bit set)
   attributes in the message.  If the floor control server does not
   understand all of them, the floor control server SHOULD send an Error
   message, as described in Section 13.8, with Error code 2
   (Authentication Failed).  The Error message SHOULD list the
   attributes that were not understood.

13.1. Reception of a FloorRequest Message

On reception of a FloorRequest message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequest message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8. BFCP allows floor participants to have several ongoing floor requests for the same floor (e.g., the same floor participant can occupy more than one position in a queue at the same time). A floor control server that only supports a certain number of ongoing floor requests per floor participant (e.g., one) can use Error Code 8 (You have Already Reached the Maximum Number of Ongoing Floor Requests for this Floor) to inform the floor participant.

13.1.1. Generating the First FloorRequestStatus Message

The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of which SHOULD be generated as soon as possible. If the floor control server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates. The policy that a floor control server follows to grant or deny floors is outside the scope of this document. A given floor control server may perform these decisions automatically while another may contact a human acting as a chair every time a decision needs to be made. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the
Top   ToC   RFC4582 - Page 49
   FloorRequestStatus, as described in Section 8.2.  Additionally, the
   floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
   attribute to the FloorRequestStatus.  The attributes contained in
   this grouped attribute carry information about the floor request.

   The floor control server MUST assign an identifier that is unique
   within the conference to this floor request, and MUST insert it in
   the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
   attribute.  This identifier will be used by the floor participant (or
   by a chair or chairs) to refer to this specific floor request in the
   future.

   The floor control server MUST copy the Floor IDs in the FLOOR-ID
   attributes of the FloorRequest into the FLOOR-REQUEST-STATUS
   attributes in the FLOOR-REQUEST-INFORMATION grouped attribute.  These
   Floor IDs identify the floors being requested (i.e., the floors
   associated with this particular floor request).

   The floor control server SHOULD copy (if present) the contents of the
   BENEFICIARY-ID attribute from the FloorRequest into a
   BENEFICIARY-INFORMATION attribute inside the
   FLOOR-REQUEST-INFORMATION grouped attribute.  Additionally, the floor
   control server MAY provide the display name and the URI of the
   beneficiary in this BENEFICIARY-INFORMATION attribute.

   The floor control server MAY provide information about the requester
   of the floor in a REQUESTED-BY-INFORMATION attribute inside the
   FLOOR-REQUEST-INFORMATION grouped attribute.

   The floor control server MAY copy (if present) the PARTICIPANT-
   PROVIDED-INFO attribute from the FloorRequest into the FLOOR-
   REQUEST-INFORMATION grouped attribute.

      Note that this attribute carries the priority requested by the
      participant.  The priority that the floor control server assigns
      to the floor request depends on the priority requested by the
      participant and the rights the participant has according to the
      policy of the conference.  For example, a participant that is only
      allowed to use the Normal priority may request Highest priority
      for a floor request.  In that case, the floor control server would
      ignore the priority requested by the participant.

   The floor control server MAY copy (if present) the
   PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the
   FLOOR-REQUEST-INFORMATION grouped attribute.
Top   ToC   RFC4582 - Page 50

13.1.2. Generation of Subsequent FloorRequestStatus Messages

A floor request is considered to be ongoing as long as it is not in the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message generated by the floor control server did not indicate any of these states, the floor control server will need to send subsequent FloorRequestStatus messages. When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.) The floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to 0. The rate at which the floor control server sends FloorRequestStatus messages is a matter of local policy. A floor control server may choose to send a new FloorRequestStatus message every time the floor request moves in the floor request queue, while another may choose only to send a new FloorRequestStatus message when the floor request is Granted or Denied. The floor control server may add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates to provide extra information about its decisions regarding the floor request (e.g., why it was denied). Floor participants and floor chairs may request to be informed about the status of a floor following the procedures in Section 12.1. If the processing of a floor request changes the status of a floor (e.g., the floor request is granted and consequently the floor has a new holder), the floor control server needs to follow the procedures in Section 13.5 to inform the clients that have requested that information. The common header and the rest of the attributes are the same as in the first FloorRequestStatus message. The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked.
Top   ToC   RFC4582 - Page 51

13.2. Reception of a FloorRequestQuery Message

On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8. The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2. Additionally, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request and a STATUS-INFO attribute with extra information about the floor request.
Top   ToC   RFC4582 - Page 52
   The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
   to the FLOOR-REQUEST-INFORMATION grouped attribute with the current
   status of the floor request.  The floor control server MAY provide
   information about the status of the floor request as it relates to
   each of the floors being requested in the FLOOR-REQUEST-STATUS
   attributes.

13.3. Reception of a UserQuery Message

On reception of a UserQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the UserQuery message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8. The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the USerStatus message, as described in Section 8.2. The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the common header of the UserQuery message. The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control server MAY provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute. The floor control server SHOULD add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request related to the participant about which the message provides information (i.e., the floor requests where the participant is either the beneficiary or the requester). For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps. The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
Top   ToC   RFC4582 - Page 53
   The floor control server MUST add FLOOR-REQUEST-STATUS attributes to
   the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
   floors being requested (i.e., the floors associated with the floor
   request identified by the FLOOR-REQUEST-ID attribute).

   The floor control server SHOULD add a BENEFICIARY-ID attribute to the
   FLOOR-REQUEST-INFORMATION grouped attribute identifying the
   beneficiary of the floor request.  Additionally, the floor control
   server MAY provide the display name and the URI of the beneficiary in
   this BENEFICIARY-INFORMATION attribute.

   The floor control server MAY provide information about the requester
   of the floor in a REQUESTED-BY-INFORMATION attribute inside the
   FLOOR-REQUEST-INFORMATION grouped attribute.

   The floor control server MAY provide the reason why the floor
   participant requested the floor in a PARTICIPANT-PROVIDED-INFO.

   The floor control server MAY also add to the FLOOR-REQUEST-
   INFORMATION grouped attribute a PRIORITY attribute with the Priority
   value requested for the floor request.

   The floor control server MUST include the current status of the floor
   request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-
   INFORMATION grouped attribute.  The floor control server MAY add a
   STATUS-INFO attribute with extra information about the floor request.

   The floor control server MAY provide information about the status of
   the floor request as it relates to each of the floors being requested
   in the FLOOR-REQUEST-STATUS attributes.

13.4. Reception of a FloorRelease Message

On reception of a FloorRelease message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRelease message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8. The successful processing of a FloorRelease message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2.
Top   ToC   RFC4582 - Page 54
   The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
   attribute to the FloorRequestStatus.  The attributes contained in
   this grouped attribute carry information about the floor request.

   The FloorRelease message identifies the floor request it applies to
   using a FLOOR-REQUEST-ID.  The floor control server MUST copy the
   contents of the FLOOR-REQUEST-ID attribute from the FloorRelease
   message into the Floor Request ID field of the
   FLOOR-REQUEST-INFORMATION attribute.

   The floor control server MUST identify the floors being requested
   (i.e., the floors associated with the floor request identified by the
   FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the
   FLOOR-REQUEST-INFORMATION grouped attribute.

   The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
   to the FLOOR-REQUEST-INFORMATION grouped attribute.  The Request
   Status value SHOULD be Released, if the floor (or floors) had been
   previously granted, or Cancelled, if the floor (or floors) had not
   been previously granted.  The floor control server MAY add a STATUS-
   INFO attribute with extra information about the floor request.

13.5. Reception of a FloorQuery Message

On reception of a FloorQuery message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the FloorRelease message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8. A floor control server receiving a FloorQuery message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. Floor Control Servers keep clients informed by using FloorStatus messages. An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors. The information FloorQuery messages carry may depend on the user requesting the information. For example, a chair may be able to receive information about pending requests, while a regular user may not be authorized to do so.
Top   ToC   RFC4582 - Page 55

13.5.1. Generation of the First FloorStatus Message

The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2. If the FloorQuery message did not contain any FLOOR-ID attribute, the floor control server sends the FloorStatus message without adding any additional attribute and does not send any subsequent FloorStatus message to the floor participant. If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST-INFORMATION grouped attribute contains a number of attributes that provide information about the floor request. For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps. The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
Top   ToC   RFC4582 - Page 56
   The floor control server MAY provide the reason why the floor
   participant requested the floor in a PARTICIPANT-PROVIDED-INFO.

   The floor control server MAY also add to the FLOOR-REQUEST-
   INFORMATION grouped attribute a PRIORITY attribute with the Priority
   value requested for the floor request.

   The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
   to the FLOOR-REQUEST-INFORMATION grouped attribute with the current
   status of the floor request.  The floor control server MAY add a
   STATUS-INFO attribute with extra information about the floor request.

   The floor control server MAY provide information about the status of
   the floor request as it relates to each of the floors being requested
   in the FLOOR-REQUEST-STATUS attributes.

13.5.2. Generation of Subsequent FloorStatus Messages

If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control server SHOULD generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as those for the first FloorStatus message (see Section 13.5.1), but their Transaction ID is 0. After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messages MUST be 0. The rate at which the floor control server sends FloorStatus messages is a matter of local policy. A floor control server may choose to send a new FloorStatus message every time a new floor request arrives, while another may choose to only send a new FloorStatus message when a new floor request is Granted.

13.6. Reception of a ChairAction Message

On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8. The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, which SHOULD be generated as soon as possible.
Top   ToC   RFC4582 - Page 57
   The floor control server MUST copy the Conference ID, the Transaction
   ID, and the User ID from the ChairAction message into the
   ChairActionAck message, as described in Section 8.2.

   The floor control server needs to take into consideration the
   operation requested in the ChairAction message (e.g., granting a
   floor) but does not necessarily need to perform it as requested by
   the floor chair.  The operation that the floor control server
   performs depends on the ChairAction message and on the internal state
   of the floor control server.

   For example, a floor chair may send a ChairAction message granting a
   floor that was requested as part of an atomic floor request operation
   that involved several floors.  Even if the chair responsible for one
   of the floors instructs the floor control server to grant the floor,
   the floor control server will not grant it until the chairs
   responsible for the other floors agree to grant them as well.

   So, the floor control server is ultimately responsible for keeping a
   coherent floor state using instructions from floor chairs as input to
   this state.

   If the new Status in the ChairAction message is Accepted and all the
   bits of the Queue Position field are zero, the floor chair is
   requesting that the floor control server assign a queue position
   (e.g., the last in the queue) to the floor request based on the local
   policy of the floor control server.  (Of course, such a request only
   applies if the floor control server implements a queue.)

13.7. Reception of a Hello Message

On reception of a Hello message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the Hello message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8. The successful processing of a Hello message by a floor control server involves generating a HelloAck message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2. The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all the primitives (i.e., BFCP messages) supported by the floor control server.
Top   ToC   RFC4582 - Page 58
   The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to
   the HelloAck message listing all the attributes supported by the
   floor control server.

13.8. Error Message Generation

Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The ABNF in Section 5.3.13 describes the attributes that an Error message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory and which ones are optional. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in Section 8.2. The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an Error Code from Table 5. Additionally, the floor control server may add an ERROR-INFO attribute with extra information about the error.

14. Security Considerations

BFCP uses TLS to provide mutual authentication between clients and servers. TLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS with non-null encryption always be used. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. The remainder of this section analyzes some of the threats against BFCP and how they are addressed. An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests or to grant or deny existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS connections. The floor control server assumes that attackers cannot highjack the TLS connection and, therefore, that messages over the TLS connection come from the client that was initially authenticated. An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS connections.
Top   ToC   RFC4582 - Page 59
   Attackers may attempt to modify messages exchanged by a client and a
   floor control server.  The integrity protection provided by TLS
   connections prevents this attack.

   An attacker may attempt to fetch a valid message sent by a client to
   a floor control server and replay it over a connection between the
   attacker and the floor control server.  This attack is prevented by
   having floor control servers check that messages arriving over a
   given authenticated TLS connection use an authorized user ID (i.e., a
   user ID that the user that established the authenticated TLS
   connection is allowed to use).

   Attackers may attempt to pick messages from the network to get access
   to confidential information between the floor control server and a
   client (e.g., why a floor request was denied).  TLS confidentiality
   prevents this attack.  Therefore, it is RECOMMENDED that TLS be used
   with a non-null encryption algorithm.

15. IANA Considerations

The IANA has created a new registry for BFCP parameters called "Binary Floor Control Protocol (BFCP) Parameters". This new registry has a number of subregistries, which are described in the following sections.

15.1. Attribute Subregistry

This section establishes the Attribute subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP attributes shall be "Specification Required". For the purposes of this subregistry, the BFCP attributes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the attribute's type, name, format, and semantics. For each BFCP attribute, the IANA registers its type, its name, and the reference to the RFC where the attribute is defined. The following table contains the initial values of this subregistry.
Top   ToC   RFC4582 - Page 60
           +------+---------------------------+------------+
           | Type | Attribute                 | Reference  |
           +------+---------------------------+------------+
           |   1  | BENEFICIARY-ID            | [RFC 4582] |
           |   2  | FLOOR-ID                  | [RFC 4582] |
           |   3  | FLOOR-REQUEST-ID          | [RFC 4582] |
           |   4  | PRIORITY                  | [RFC 4582] |
           |   5  | REQUEST-STATUS            | [RFC 4582] |
           |   6  | ERROR-CODE                | [RFC 4582] |
           |   7  | ERROR-INFO                | [RFC 4582] |
           |   8  | PARTICIPANT-PROVIDED-INFO | [RFC 4582] |
           |   9  | STATUS-INFO               | [RFC 4582] |
           |  10  | SUPPORTED-ATTRIBUTES      | [RFC 4582] |
           |  11  | SUPPORTED-PRIMITIVES      | [RFC 4582] |
           |  12  | USER-DISPLAY-NAME         | [RFC 4582] |
           |  13  | USER-URI                  | [RFC 4582] |
           |  14  | BENEFICIARY-INFORMATION   | [RFC 4582] |
           |  15  | FLOOR-REQUEST-INFORMATION | [RFC 4582] |
           |  16  | REQUESTED-BY-INFORMATION  | [RFC 4582] |
           |  17  | FLOOR-REQUEST-STATUS      | [RFC 4582] |
           |  18  | OVERALL-REQUEST-STATUS    | [RFC 4582] |
           +------+---------------------------+------------+

         Table 6: Initial values of the BFCP Attribute subregistry

15.2. Primitive Subregistry

This section establishes the Primitive subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP primitives shall be "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics. For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.
Top   ToC   RFC4582 - Page 61
                +-------+--------------------+------------+
                | Value | Primitive          | Reference  |
                +-------+--------------------+------------+
                |   1   | FloorRequest       | [RFC 4582] |
                |   2   | FloorRelease       | [RFC 4582] |
                |   3   | FloorRequestQuery  | [RFC 4582] |
                |   4   | FloorRequestStatus | [RFC 4582] |
                |   5   | UserQuery          | [RFC 4582] |
                |   6   | UserStatus         | [RFC 4582] |
                |   7   | FloorQuery         | [RFC 4582] |
                |   8   | FloorStatus        | [RFC 4582] |
                |   9   | ChairAction        | [RFC 4582] |
                |   10  | ChairActionAck     | [RFC 4582] |
                |   11  | Hello              | [RFC 4582] |
                |   12  | HelloAck           | [RFC 4582] |
                |   13  | Error              | [RFC 4582] |
                +-------+--------------------+------------+

         Table 7: Initial values of the BFCP primitive subregistry

15.3. Request Status Subregistry

This section establishes the Request Status subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP request status shall be "Specification Required". For the purposes of this subregistry, the BFCP request status for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the request status. For each BFCP request status, the IANA registers its value, its meaning, and the reference to the RFC where the request status is defined. The following table contains the initial values of this subregistry. +-------+-----------+------------+ | Value | Status | Reference | +-------+-----------+------------+ | 1 | Pending | [RFC 4582] | | 2 | Accepted | [RFC 4582] | | 3 | Granted | [RFC 4582] | | 4 | Denied | [RFC 4582] | | 5 | Cancelled | [RFC 4582] | | 6 | Released | [RFC 4582] | | 7 | Revoked | [RFC 4582] | +-------+-----------+------------+ Table 8: Initial values of the Request Status subregistry
Top   ToC   RFC4582 - Page 62

15.4. Error Code Subregistry

This section establishes the Error Code subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP error codes shall be "Specification Required". For the purposes of this subregistry, the BFCP error codes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the error code, and any Error Specific Details that apply to it. For each BFCP primitive, the IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry. +-------+-----------------------------------------------+------------+ | Value | Meaning | Reference | +-------+-----------------------------------------------+------------+ | 1 | Conference does not Exist | [RFC 4582] | | 2 | User does not Exist | [RFC 4582] | | 3 | Unknown Primitive | [RFC 4582] | | 4 | Unknown Mandatory Attribute | [RFC 4582] | | 5 | Unauthorized Operation | [RFC 4582] | | 6 | Invalid Floor ID | [RFC 4582] | | 7 | Floor Request ID Does Not Exist | [RFC 4582] | | 8 | You have Already Reached the Maximum Number | [RFC 4582] | | | of Ongoing Floor Requests for this Floor | | | 9 | Use TLS | [RFC 4582] | +-------+-----------------------------------------------+-----------+ Table 9: Initial Values of the Error Code subregistry

16. Acknowledgements

The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments.
Top   ToC   RFC4582 - Page 63

17. References

17.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [7] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.

17.2. Informational References

[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006. [10] Barnes, M. and C. Boulton, "A Framework and Data Model for Centralized Conferencing", Work in Progress, February 2005.
Top   ToC   RFC4582 - Page 64

Authors' Addresses

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Joerg Ott Helsinki University of Technology Department for Electrical and Communications Engineering Networking Laboratory PO Box 3000 02015 TKK Finland EMail: jo@netlab.hut.fi Keith Drage Lucent Technologies Windmill Hill Business Park Swindon Wiltshire SN5 6PP UK EMail: drage@lucent.com
Top   ToC   RFC4582 - Page 65
Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.