tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6501

 
 
 

Conference Information Data Model for Centralized Conferencing (XCON)

Part 2 of 4, p. 18 to 39
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
4.3.  <host-info>

   The <host-info> element and its child elements are described in
   [RFC4575], Section 5.4.

4.4.  <conference-state>

   The <conference-state> is introduced in [RFC4575].  The <conference-
   state> element contains the <allow-conference-event-subscription>,
   <user-count>, <active>, and <locked> child elements.  The <user-
   count>, <active>, and <locked> child elements are defined in
   [RFC4575], Section 5.5.

4.4.1.  <allow-conference-event-subscription>

   The <allow-conference-event-subscription> element represents a
   boolean action.  If set to true, the focus is instructed to allow the
   subscription to conference state events, such as 'SIP event package
   for conference state' [RFC4575].  If set to FALSE, the subscription
   to conference state events MUST be rejected.  If this element is
   undefined, it has a default value of true, causing the subscription
   to conference state events to be accepted.

4.5.  <floor-information>

   The <floor-information> element contains the <conference-ID>, <allow-
   floor-events>, <floor-request-handling>, and <conference-floor-
   policy> child elements.  The absence of this element from an XML
   document indicates that the conference does not have a floor.

Top      Up      ToC       Page 19 
4.5.1.  <conference-ID>

   The <conference-ID> represents a conference instance within floor
   control.  When BFCP serves as the floor control protocol, the
   <conference-ID> is a 32-bit BFCP conference identifier defined in
   [RFC4582], Section 5.1.  Note that when created within the
   conferencing system, there is a 1:1 mapping between this
   <conference-ID> and the unique conference object identifier (XCON-
   URI).

4.5.2.  <allow-floor-events>

   The <allow-floor-events> element represents a boolean action.  If set
   to true, the focus is instructed to accept the subscription to floor
   control events.  If set to FALSE, the focus is instructed to reject
   the subscription.  If this element is undefined, it has a default
   value of FALSE, causing the subscription to floor control events to
   be rejected.

   A conference participant can subscribe himself to a floor control
   event in two different ways: one method is using an offer/answer
   exchange mechanism ([RFC3264]) using SIP INVITE and BFCP parameters
   in the SDP [RFC4583], the other method is a general authorization
   mechanism described in Section 9 of [RFC4582] and in [RFC5018].
   Future documentation may define additional connection mechanisms.

4.5.3.  <floor-request-handling>

   The <floor-request-handling> element defines the actions used by the
   conference focus to control floor requests.  This element defines the
   action that the focus is to take when processing a particular request
   to a floor within a conference.  This element defines values of the
   following:

   o  "block": This action instructs the focus to deny the floor
      request.  This action is the default action taken in the absence
      of any other actions.

   o  "confirm": This action instructs the focus to allow the request.
      The focus then uses the defined floor algorithm to further allow
      or deny the floor.  The algorithms used are outside the scope of
      this document.

   Note that this section discusses floor control information;
   therefore, the value "block" in a <floor-request-handling> element is
   not related with the "block" value in the <join-handling> element
   (see Section 4.6.1).

Top      Up      ToC       Page 20 
4.5.4.  <conference-floor-policy>

   The <conference-floor-policy> element has one or more <floor> child
   elements.  Every <floor> child elements has an attribute 'id', which
   uniquely identifies a floor within a conference.  In the case of BFCP
   [RFC4582], the 'id' attribute corresponds to the floor-id identifier
   defined in [RFC4582], Section 5.2.2.

   o  <media-label>: Every floor is identified for one or more mandatory
      <media-label> elements.  If the <available-media> information is
      included in the conference document, the value of this element
      MUST be equal to the "label" value of the corresponding media
      stream <entry> in the <available-media> container.  The number of
      those elements indicates how many floors the conference can have.
      A floor can be used for one or more media types;

   o  <algorithm>: A floor can be controlled using many algorithms; the
      mandatory <algorithm> element MUST be set to any of the
      "moderator-controlled", "FCFS", or "random" values indicating the
      algorithm.  The "moderator-controlled" value indicates that the
      moderator of the conference controls the floor.  The "FCFS" value
      indicates a 'first-come-first-served' policy.

   o  <max-floor-users>: The <max-floor-users> child element in the
      <floor> element is OPTIONAL and, if present, dictates the maximum
      number of users who can have the floor at one time.

   o  <moderator-id>: The OPTIONAL <moderator-id> indicates the "User
      ID" of the moderator(s).  It MUST be set if the element
      <algorithm> is set to the "moderator-controlled" value.  When the
      floor is created within the conferencing system, the XCON-USERID
      MAY be used as the <moderator-id>.  In the case where the BFCP is
      the floor control protocol, the <moderator-id> is defined in
      [RFC4582], Section 3.  Note that [RFC4582] refers to the moderator
      role as a "floor chair".

4.6.  <users>

   The <users> element is described in [RFC4575] and contains the <join-
   handling>, <user-admission-policy>, <allowed-users-list>, and <deny-
   users-list> defined in this document and <user> child elements
   defined in [RFC4575].  When the <users> element is used in the
   context of the XCON Conference Information Model, the 'state' and
   'version' attributes defined in [RFC4575] are not used, since they
   apply only to notification mechanisms.  The following sections
   describe these elements in more detail.  Other child elements and
   attributes can be used to extend <users> in the future.

Top      Up      ToC       Page 21 
4.6.1.  <join-handling>

   The <join-handling> element defines the actions used by the
   conference focus to control conference participation.  This element
   defines the action that the focus is to take when processing a
   particular request to join a conference.  This element defines values
   of:

   o  "block": This action instructs the focus to deny access to the
      conference.  This action is the default action taken in the
      absence of any other actions.

   o  "confirm": This action instructs the focus to place the
      participant on a pending list (e.g., by parking the call on a
      music-on-hold server), awaiting moderator input for further
      actions.

   o  "allow": This action instructs the focus to accept the conference
      join request and grant access to the conference within the
      instructions specified in the transformations of this rule.

   o  "authenticate": This action instructs the focus that the user has
      to provide a combination of username/password.

   o  "directed-operator": This action instructs the focus to direct the
      user to an operator.

4.6.2.  <user-admission-policy>

   The <user-admission-policy> is an element that lets an organizer (or
   a participant with appropriate rights) choose a policy for the
   conference that controls how users are authenticated into the
   conference, using a mechanism of the conference's choosing.  Since a
   variety of signaling protocols are possible, a variety of
   authentication mechanisms -- determined by every individual
   conference server -- may need to be mapped from the different
   protocols.  The specific types of authentication mechanisms are
   beyond the scope of this document.  The list of possible values are
   as follows:

   o  "closedAuthenticated": A 'closedAuthenticated' policy MUST have
      each conference participant in the allowed users list (listed
      under the <allowed-users-list> element) with each participant
      being sufficiently (up to local policy) authenticated.  Conference
      join requests for users not in the allowed users list or
      participants not authenticated should be rejected unless a <join-
      handling> action of 'confirm' is selected; in which case, the user
      is placed on a pending list as indicated earlier.  A

Top      Up      ToC       Page 22 
      'closedAuthenticated' policy MUST NOT include a <deny-users-list>.
      If <deny-users-list> appears in the data model, it MUST be
      ignored.

   o  "openAuthenticated": An 'openAuthenticated' policy requires each
      conferencing participant to be sufficiently authenticated.
      Typically, this implies that anyone capable of authenticating with
      the conferencing system may join the conference.  The
      'openAuthenticated' policy permits the specification of "banned"
      conferencing participants.  Such banned users are prevented from
      re-joining the conference until they have been un-banned.  An
      'openAuthenticated' policy SHOULD have a deny users list (listed
      under the <deny-users-list> XML element) to support the banning of
      conferencing participants from a conference.  An
      'openAuthenticated' policy MUST NOT include an <allowed-users-
      list>.  If <allowed-users-list> appears in the data model, it MUST
      be ignored.

   o  "anonymous": An 'anonymous' policy grants any join requests and is
      the least restrictive policy.  An 'anonymous' policy MUST NOT
      include either an <allowed-users-list> or a <deny-users-list>.  If
      any of these lists appear in the data model, they MUST be ignored.

   In all other cases, the appearance of an <allowed-users-list> and
   <deny-users-list> MUST be ignored, except as otherwise described in a
   future specification.  Future specifications describing the use of
   these lists must provide clear guidance on how to process the lists
   when they occur concurrently, especially when both lists contain the
   same user.  For example, such a specification could disallow both
   lists from appearing at the same time similar to <user-admission-
   policy> values defined in this document.

4.6.3.  <allowed-users-list>

   The <allowed-users-list> child element contains a list of user URIs
   (e.g., XCON-USERID, as defined in Section 4.6.5), roles (defined in
   Section 4.6.5.2), or domains (e.g., *@example.com) that the focus
   uses to determine who can join the conference, who can be invited to
   join a conference, or who the focus needs to "refer to" the
   conference.  The <allowed-users-list> element includes zero or more
   <target> child elements.  This child element includes the mandatory
   'uri' attribute and the mandatory 'method' attribute.  The same 'uri'
   attribute with different method values can appear in the list more
   than once.

Top      Up      ToC       Page 23 
   The 'method' attribute is a list with the following values:

   o  "dial-in": The value "dial-in" is used by the focus to determine
      who can join the conference.

   o  "dial-out": The value "dial-out" contains a list of resources with
      which the focus will initiate a session.

   o  "refer": The value "refer" is used by the focus to determine the
      resources that the focus needs to "refer to" the conference.  In
      SIP, this is achieved by the focus sending a REFER request to
      those potential participants.  In a different paradigm, this could
      also mean that the focus sends an SMS or an email to the referred
      user.  This list can be updated during the conference lifetime so
      it can be used for mid-conference refers as well.

   The "refer" value differs from "dial-out" in that the resources on
   the "refer" value are expected to initiate the session establishment
   toward the focus themselves.  It is also envisioned that different
   users will have different access rights to those lists and therefore
   a separation between the two is needed.

   The <allowed-users-list> element has a <persistent-list> child
   element as well.  Some chat room systems allow -- and some require --
   registration of detailed information about a user before they are
   allowed to join a chat room.  The <persistent-list> child element
   stores persistent information about users who are not actively part
   of an ongoing chat room session.  The <persistent-list> element
   stores the following information:

   o  user: The <user> element stores the name, nickname, conference
      user identifier (XCON-USERID), and email address of a user.  It
      has three attributes: 'name', 'nickname', and 'id' and an <email>
      element.  Future extensions to this schema may define new elements
      for the <user> element.

   Future extensions to this schema may define new elements for the
   <target> element.

4.6.4.  <deny-users-list>

   The <deny-users-list> child element contains a list of user URIs
   (e.g., SIP URI, XCON-USERID defined in Section 4.6.5), roles (defined
   in Section 4.6.5.2), or domains (e.g.: *@example.com) that the focus
   uses to determine who has been 'banned' from the conference.  Such
   banned users are prevented from re-joining the chat room until the
   ban has been lifted.

Top      Up      ToC       Page 24 
4.6.5.  <user> and Its <user> Sub-Elements

   The element <user> is described in [RFC4575] and describes a single
   participant in the conference.  The <user> element has an attribute
   'entity'.  However, when the <user> element is used in the context of
   the XCON Conference Information Model, the 'state' and 'version'
   attributes defined in [RFC4575] are not used, since they only apply
   to notification mechanisms.

   The attribute 'entity' contains a unique conference user identifier
   (XCON-USERID) within the scope of the conference.  The URI format of
   this identifier is as follows (using ABNF [RFC5234]):


      XCON-USERID = "xcon-userid" ":" conf-user-id

      conf-user-id = 1*unreserved

   Note: unreserved is defined in RFC 3986.

   In order to facilitate the comparison of the XCON-USERID identifiers,
   all the components of the identifiers MUST be converted to lowercase.

   After normalizing the URI strings, the URIs comparison MUST be
   applied codepoint-by-codepoint after conversion to a common character
   encoding, as prescribed by [RFC3986], Section 6.2.1.

   Other user identifiers can be associated with this conference user
   identifier and enable the conferencing system to correlate and map
   these multiple authenticated user identities to a single global user
   identifier.  Figure 2 illustrates an example using the conference
   user identifier in association with the user identity defined for
   BFCP, SIP, and H323 user identity.  It should be noted that a
   conferencing system is free to structure such relationships as
   required, and this information is just included as a guideline.

Top      Up      ToC       Page 25 
                         +----------------+
                         |   Conference   |
                         |      User      |
                         |   Identifier   |
                         +----------------+
                         |XCON-USERID:John|
                         +-------+--------+
                                 |
                                 |
                                 |
          +----------------------+-------------------------+
          |                      |                         |
  +-------+--------+ +-----------+-----------+ +-----------+-----------+
  |  BFCP User ID  | |      SIP User URI     | |     H323 User URI     |
  +----------------+ +-----------------------+ +-----------------------+
  |      543       | |sip:851221@example.com | |h323:taeduk@example.com|
  +----------------+ +-----------------------+ +-----------------------+


                     Figure 2: Conference User Mapping

   The element <user> element contains the <display-text>, <associated-
   aors>, <provide-anonymity>, <roles>, <languages>, <cascaded-focus>,
   <allow-refer-users-dynamically>, <allow-invite-users-dynamically>,
   <allow-remove-users-dynamically>, and <endpoint>.  The following
   sections describe these elements in more detail.  The <display-text>,
   <associated-aors>, <languages>, and <cascaded-focus> are defined in
   [RFC4575], Section 5.6.

4.6.5.1.  <provide-anonymity>

   The <provide-anonymity> element specifies what level of anonymity the
   server should provide to the user.  In this case, the focus provides
   the rest of the participants with an anonymous identity for that
   user, for example, anonymousX, or it does not provide any information
   for that user such that other users cannot see he is a participant in
   the conference.  This element only affects the way the user
   information is provided to the other participants.  The real user
   information is stored in the data model but SHOULD NOT be provided to
   the other participants of the conference.  This can be achieved by
   using the <provide-anonymity> element.  This element has three
   values: "private", "semi-private", and "hidden".  The "private" value
   specifies that this user is completely anonymous in the conference.
   The "semi-private" value specifies that this user is anonymous to all
   users who have not been granted permission to see him.  The "hidden"
   value specifies that other users cannot see this participant in the
   conference.

Top      Up      ToC       Page 26 
4.6.5.2.  <roles>

   A <role> provides the context for the set of conference operations
   that a participant can perform.  This element can contain one or more
   of the following values: "administrator", "moderator", "user",
   "participant", "observer", and "none".  A role of "none" indicates
   that any role is assigned.  The <roles> semantic definition is out of
   the scope of this document and is subject to future policy documents.
   This element can be extended with new roles in future documents.

4.6.5.3.  <allow-refer-users-dynamically>

   The <allow-refer-users-dynamically> element represents a boolean
   value.  If set to true, a participant is allowed to instruct the
   focus to refer a user to the conference without modifying the
   <allowed-users-list> (in SIP terms, a participant is allowed to send
   a REFER request [RFC3515] to the focus, which results in the focus
   sending a REFER request to the user the referrer wishes to join the
   conference).  If set to FALSE, the REFER request is rejected.  If
   this element is undefined, it has a value of FALSE, causing the REFER
   request to be rejected.

4.6.5.4.  <allow-invite-users-dynamically>

   The <allow-invite-users-dynamically> element represents a boolean
   action.  If set to true, a participant is allowed to instruct the
   focus to invite a user to the conference without modifying the
   <allowed-users-list> list (in SIP terms, a participant is allowed to
   send a REFER request [RFC3515] to the focus, which results in the
   focus sending an INVITE request to the user the referrer wishes to
   join the conference).  If set to FALSE, the REFER request is
   rejected.  If this element is undefined, it has a value of FALSE,
   causing the REFER request to be rejected.

4.6.5.5.  <allow-remove-users-dynamically>

   The <allow-remove-users-dynamically> element represents a boolean
   action.  If set to true, a participant is allowed to instruct the
   focus to remove a user from the conference without modifying the
   ruleset (in SIP terms, a participant is allowed to send a REFER
   request [RFC3515] to the focus, which results in the focus sending a
   BYE request to the user the referrer wishes to leave the conference).
   If set to FALSE, the REFER request is rejected.  If this element is
   undefined, it has a value of FALSE, causing the REFER request to be
   rejected.

Top      Up      ToC       Page 27 
4.6.5.6.  <endpoint>

   The <endpoint> child element is identical to the element with the
   same name in [RFC4575] except that the 'state' attribute is not
   included.  When the <endpoint> element is used in the context of the
   XCON Conference Information Model, the 'state' and 'version'
   attributes defined in [RFC4575] are not used, since they apply only
   to notification mechanisms.  The <endpoint> element can provide the
   desired level of detail about the user's devices and their signaling
   sessions taking part in the conference.

   The <endpoint> element has the following child elements: <display-
   text>, <referred>, <status>, <joining-method>, <joining-info>,
   <disconnection-method>, <disconnection-info>, <media>, and <call-
   info>.  All the <endpoint> child elements are defined in [RFC4575]
   with the exception of the <to-mixer> element and the <from-mixer>
   element.

   The <endpoint>/<media> element has two other child elements defined
   in this document: the <to-mixer> and the <from-mixer>:

   o  <from-mixer>, <to-mixer>: These are controls that apply to a
      user's media stream being sent from the mixer to the participant's
      endpoint or to the mixer from the participant's endpoint.  The
      <to-mixer> element details properties associated with the incoming
      streams to the mixer (streams sent to the mixer from the
      participant).  The <from-mixer> element details properties
      associated with the outgoing streams from the mixer (sent from the
      mixer to the participant).  Both of these elements have the
      attribute 'name'.  The 'name' attribute has the values "VideoIn",
      "VideoOut", "AudioOut", and "AudioIn".  The "VideoOut" and
      "AudioOut" media streams detail properties associated with the
      outgoing video and audio from the mixer.  The "VideoIn" and
      "AudioIn" media stream details properties associated with the
      incoming video and audio to the mixer.  Both of these elements can
      have the <floor> child element defined:

      *  The <floor> element refers to the floor assigned to a certain
         participant in the conference.  If a participant, for instance,
         needs to talk in the conference, it first needs to get the
         floor from the chair of the conference.  The <floor> element
         has an attribute 'id', which uniquely identifies a floor within
         a conference.  The 'id' attribute corresponds to the floor-id
         identifier defined in [RFC4582], Section 5.2.2.  The <floor>
         element has a boolean value.  A value of FALSE indicates that
         this user does not hold the floor in this moment.  If this
         control is not specified, this user SHOULD NOT specify the
         floor option.

Top      Up      ToC       Page 28 
      The <to-mixer> and <from-mixer> elements can have the <controls>
      child element:

      *  Controls that apply to a specific user would appear under the
         <controls> element.

   o  More values can be defined in the future.

4.7.  <sidebars-by-ref>

   The <sidebars-by-ref> element contains a set of <entry> child
   elements.  This element is described in [RFC4575], Section 5.9.1.
   When the <sidebars-by-ref> element is used in the context of the XCON
   conference information model, the 'state' and 'version' attributes
   defined in [RFC4575] are not used, since they apply only to
   notification mechanisms.

4.8.  <sidebars-by-val>

   The <sidebars-by-val> element contains a set of <entry> child
   elements each containing information about a single sidebar.  This
   element is described in [RFC4575], Section 5.9.2.  When the
   <sidebars-by-val> element is used in the context of the XCON
   conference information model, the 'state' and 'version' attributes
   defined in [RFC4575] are not used, since they apply only to
   notification mechanisms.

5.  RELAX NG Schema

   In accordance with the centralized conferencing framework document
   [RFC5239], the conference object is a logical representation of a
   conference instance.  The conference information schema contains core
   information that is utilized in any conference.  It also contains the
   variable information part of the conference object.

   The normative schema is backwards compatible with [RFC5239], in other
   words, valid [RFC5239] instance documents are also valid according to
   this RELAX NG schema [RELAX].  In addition to approximately similar
   RELAX NG [RELAX] definitions of [RFC5239], this schema contains
   extension elements in the
   "urn:ietf:params:xml:ns:xcon-conference-info" namespace.

Top      Up      ToC       Page 29 
default namespace = "urn:ietf:params:xml:ns:conference-info"
namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info"

start = element conference-info { conference-type }
# CONFERENCE TYPE
conference-type =
  attribute entity { text }
  & anyAttribute
  & conference-description-type?
  & element host-info { host-type }?
  & element conference-state { conference-state-type }?
  & element users { users-type }?
  & element sidebars-by-ref { uris-type }?
  & element sidebars-by-val { sidebars-by-val-type }?
  & element xcon:floor-information { floor-information-type }?
  & anyElement*
# CONFERENCE DESCRIPTION TYPE
conference-description-type =
  element conference-description {
    attribute xml:lang { xsd:language }?
    & anyAttribute
    & element display-text { text }?
    & element subject { text }?
    & element free-text { text }?
    & element keywords {
        list { xsd:string* }
      }?
    & element conf-uris { uris-type }?
    & element service-uris { uris-type }?
    & element maximum-user-count { xsd:int }?
    & element available-media { conference-media-type }?
    & element xcon:language { xsd:language }?
    & element xcon:allow-sidebars { xsd:boolean }?
    & element xcon:cloning-parent { xsd:anyURI }?
    & element xcon:sidebar-parent { xsd:anyURI }?
    & element xcon:conference-time { conferencetime-type }?
    & anyElement*
  }
# HOST TYPE
host-type =
  element display-text { text }?
  & element web-page { xsd:anyURI }?
  & element uris { uris-type }?
  & anyElement*
  & anyAttribute
# CONFERENCE STATE TYPE
conference-state-type =
  anyAttribute

Top      Up      ToC       Page 30 
  & element user-count { xsd:unsignedInt }?
  & element active { xsd:boolean }?
  & element locked { xsd:boolean }?
  & element xcon:allow-conference-event-subscription { xsd:boolean }?
  & anyElement*
# CONFERENCE MEDIA TYPE
conference-media-type =
  anyAttribute
  & element entry { conference-medium-type }*
  & anyElement*
# CONFERENCE MEDIUM TYPE
conference-medium-type =
  attribute label { text }
  & anyAttribute
  & element display-text { text }?
  & element type { text }?
  & element status { media-status-type }?
  & element xcon:mixing-mode { mixing-mode-type }?
  & element xcon:codecs { codecs-type }?
  & element xcon:controls { control-type }?
  & anyElement*
# URIs TYPE
uris-type =
  anyAttribute
  & element entry { uri-type }*
  & anyElement*
# URI TYPE
uri-type =
  element uri { xsd:anyURI }
  & element display-text { text }?
  & element purpose { text }?
  & element modified { execution-type }?
  & element xcon:conference-password { text }*
  & anyElement*
  & anyAttribute
# USERS TYPE
users-type =
  anyAttribute
  & element user { user-type }*
  & element xcon:join-handling { join-handling-type }?
  & element xcon:user-admission-policy { user-admission-policy-type }?
  & element xcon:allowed-users-list { allowed-users-list-type }?
  & element xcon:deny-users-list { deny-user-list-type }?
  & anyElement*
# USER TYPE
user-type =
  attribute entity { xsd:anyURI }
  & anyAttribute

Top      Up      ToC       Page 31 
  & element display-text { text }?
  & element associated-aors { uris-type }?
  & element roles {
      element entry { single-role-type }+
    }?
  & element languages {
      list { xsd:language }
    }?
  & element cascaded-focus { xsd:anyURI }?
  & element endpoint { endpoint-type }*
  & element xcon:provide-anonymity { provide-anonymity-type }?
  & element xcon:allow-refer-users-dynamically { xsd:boolean }?
  & element xcon:allow-invite-users-dynamically { xsd:boolean }?
  & element xcon:allow-remove-users-dynamically { xsd:boolean }?
  & anyElement*
# ENDPOINT TYPE
endpoint-type =
  attribute entity { text }
  & anyAttribute
  & element display-text { text }?
  & element referred { execution-type }?
  & element status { endpoint-status-type }?
  & element joining-method { joining-type }?
  & element joining-info { execution-type }?
  & element disconnection-method { disconnection-type }?
  & element disconnection-info { execution-type }?
  & element media { media-type }*
  & element call-info { call-type }?
  & anyElement*
# ENDPOINT STATUS TYPE
endpoint-status-type =
  "pending"
  | "dialing-out"
  | "dialing-in"
  | "alerting"
  | "on-hold"
  | "connected"
  | "muted-via-focus"
  | "disconnecting"
  | "disconnected"
  | free-text-extension
# JOINING TYPE
joining-type =
  "dialed-in" | "dialed-out" | "focus-owner" | free-text-extension
# DISCONNECTION TYPE
disconnection-type =
  "departed" | "booted" | "failed" | "busy" | free-text-extension
# EXECUTION TYPE

Top      Up      ToC       Page 32 
execution-type =
  element when { xsd:dateTime }?
  & element reason { text }?
  & element by { xsd:anyURI }?
  & anyAttribute
# CALL TYPE
call-type =
  element sip { sip-dialog-id-type }
  & anyElement*
  & anyAttribute
# SIP DIALOG ID TYPE
sip-dialog-id-type =
  element display-text { text }?
  & element call-id { text }
  & element from-tag { text }
  & element to-tag { text }
  & anyElement*
  & anyAttribute
# MEDIA TYPE
media-type =
  attribute id { xsd:int }
  & anyAttribute
  & element display-text { text }?
  & element type { text }?
  & element label { text }?
  & element src-id { text }?
  & element status { media-status-type }?
  & element xcon:to-mixer { mixer-type }?
  & element xcon:from-mixer { mixer-type }?
  & anyElement*
# MEDIA STATUS TYPE
media-status-type =
  "recvonly"
  | "sendonly"
  | "sendrecv"
  | "inactive"
  | free-text-extension
# SIDEBARS-BY-VAL TYPE
sidebars-by-val-type =
  anyAttribute
  & element entry { conference-type }*
  & anyElement*
# CONFERENCE TIME
conferencetime-type =
  anyAttribute
  & element xcon:entry {
      element xcon:base { text },
      element xcon:mixing-start-offset {

Top      Up      ToC       Page 33 
        time-type,
        attribute required-participant { single-role-type },
        anyAttribute
      }?,
      element xcon:mixing-end-offset {
        time-type,
        attribute required-participant { single-role-type },
        anyAttribute
      }?,
      element xcon:can-join-after-offset { time-type }?,
      element xcon:must-join-before-offset { time-type }?,
      element xcon:request-user { time-type }?,
      element xcon:notify-end-of-conference { xsd:nonNegativeInteger }?,
      element xcon:allowed-extend-mixing-end-offset { xsd:boolean }?,
      anyElement*
    }*
# TIME TYPE
time-type = xsd:dateTime { pattern = ".+T.+Z.*" }
# SINGLE ROLE TYPE
single-role-type =
  xsd:string "none"
  | xsd:string "administrator"
  | xsd:string "moderator"
  | xsd:string "user"
  | xsd:string "observer"
  | xsd:string "participant"
  | free-text-extension
# MIXING MODE TYPE
mixing-mode-type =
  xsd:string "moderator-controlled"
  | xsd:string "FCFS"
  | xsd:string "automatic"
  | free-text-extension
# CODECS TYPE
codecs-type =
  attribute decision { decision-type }
  & anyAttribute
  & element xcon:codec { codec-type }*
  & anyElement*
# CODEC TYPE
codec-type =
  attribute name { text }
  & attribute policy { policy-type }
  & anyAttribute
  & element xcon:subtype { text }?
  & anyElement*
# DECISION TYPE
decision-type =

Top      Up      ToC       Page 34 
  xsd:string "automatic"
  | xsd:string "moderator-controlled"
  | free-text-extension
# POLICY TYPE
policy-type =
  xsd:string "allowed" | xsd:string "disallowed" | free-text-extension
# CONTROL TYPE
control-type =
  anyAttribute
  & element xcon:mute { xsd:boolean }?
  & element xcon:pause-video { xsd:boolean }?
  & element xcon:gain { gain-type }?
  & element xcon:video-layout { video-layout-type }?
  & anyElement*
# GAIN TYPE
gain-type = xsd:int { minInclusive = "-127" maxInclusive = "127" }
# VIDEO LAYOUT TYPE
video-layout-type =
  xsd:string "single-view"
  | xsd:string "dual-view"
  | xsd:string "dual-view-crop"
  | xsd:string "dual-view-2x1"
  | xsd:string "dual-view-2x1-crop"
  | xsd:string "quad-view"
  | xsd:string "multiple-3x3"
  | xsd:string "multiple-4x4"
  | xsd:string "multiple-5x1"
  | xsd:string "automatic"
  | free-text-extension
# FLOOR INFORMATION TYPE
floor-information-type =
  anyAttribute
  & element xcon:conference-ID { xsd:unsignedLong }?
  & element xcon:allow-floor-events { xsd:boolean }?
  & element xcon:floor-request-handling { floor-request-type }?
  & element xcon:conference-floor-policy { conference-floor-policy }?
  & anyElement*
# FLOOR REQUEST TYPE
floor-request-type =
  xsd:string "block" | xsd:string "confirm" | free-text-extension
# CONFERENCE FLOOR POLICY
conference-floor-policy =
  anyAttribute
  & element xcon:floor {
      attribute id { text }
      & anyAttribute
      & element xcon:media-label { xsd:nonNegativeInteger }+
      & element xcon:algorithm { algorithm-type }?

Top      Up      ToC       Page 35 
      & element xcon:max-floor-users { xsd:nonNegativeInteger }?
      & element xcon:moderator-id { xsd:nonNegativeInteger }?
      & anyElement*
    }+
# ALGORITHM POLICY
algorithm-type =
  xsd:string "moderator-controlled"
  | xsd:string "FCFS"
  | xsd:string "random"
  | free-text-extension
# USERS ADMISSION POLICY
user-admission-policy-type =
  xsd:string "closedAuthenticated"
  | xsd:string "openAuthenticated"
  | xsd:string "anonymous"
  | free-text-extension
# JOIN HANDLING TYPE
join-handling-type =
  xsd:string "block"
  | xsd:string "confirm"
  | xsd:string "allow"
  | xsd:string "authenticate"
  | xsd:string "directed-operator"
  | free-text-extension
# DENY USERLIST
deny-user-list-type =
  anyAttribute
  & element xcon:target {
      attribute uri { xsd:anyURI },
      anyAttribute
    }*
  & anyElement*
# ALLOWED USERS LIST TYPE
allowed-users-list-type =
  anyAttribute
  & element xcon:target { target-type }*
  & element xcon:persistent-list { persistent-list-type }?
  & anyElement*
# PERSISTENT LIST TYPE
persistent-list-type =
  element xcon:user {
    attribute name { text }
    & attribute nickname { text }
    & attribute id { text }
    & anyAttribute
    & element xcon:e-mail { text }*
    & anyElement*
  }*

Top      Up      ToC       Page 36 
  & anyElement*
# TARGET TYPE
target-type =
  attribute uri { xsd:anyURI },
  attribute method { method-type },
  anyAttribute
# METHOD TYPE
method-type =
  xsd:string "dial-in"
  | xsd:string "dial-out"
  | xsd:string "refer"
  | free-text-extension
# ANONYMITY TYPE
provide-anonymity-type =
  "private" | "semi-private" | "hidden" | free-text-extension
# MIXER TYPE
mixer-type =
  attribute name { mixer-name-type }
  & anyAttribute
  & element xcon:controls { control-type }*
  & element xcon:floor {
      attribute id { text },
      anyAttribute,
      xsd:boolean
    }*
  & anyElement*
# MIXER NAME TYPE
mixer-name-type =
  "VideoIn" | "VideoOut" | "AudioOut" | "AudioIn" | free-text-extension

# FREE TEXT EXTENSION
#

free-text-extension = text

# *********************************
# EXTENSIBILITY OF THE SCHEMA
# *********************************

# EXTENSIBILITY ELEMENTS
#

anyElement =
  element * - (conference-description
               | host-info
               | conference-state
               | users
               | sidebars-by-ref

Top      Up      ToC       Page 37 
               | sidebars-by-val
               | display-text
               | subject
               | free-text
               | keywords
               | conf-uris
               | service-uris
               | maximum-user-count
               | available-media
               | web-page
               | uris
               | uri
               | user-count
               | active
               | locked
               | entry
               | type

               | status
               | purpose
               | modified
               | user
               | associated-aors
               | roles
               | languages
               | cascaded-focus
               | endpoint
               | referred
               | joining-method
               | joining-info
               | disconnection-method
               | disconnection-info
               | media
               | call-info
               | when
               | reason
               | by
               | sip
               | call-id
               | from-tag
               | to-tag
               | label

Top      Up      ToC       Page 38 
               | src-id
               | xcon:conference-password
               | xcon:mixing-mode
               | xcon:codecs
               | xcon:controls
               | xcon:language
               | xcon:allow-sidebars
               | xcon:cloning-parent
               | xcon:sidebar-parent
               | xcon:allow-conference-event-subscription
               | xcon:to-mixer
               | xcon:provide-anonymity
               | xcon:allow-refer-users-dynamically
               | xcon:allow-invite-users-dynamically
               | xcon:allow-remove-users-dynamically
               | xcon:from-mixer
               | xcon:join-handling
               | xcon:user-admission-policy
               | xcon:allowed-users-list
               | xcon:deny-users-list
               | xcon:floor-information
               | xcon:conference-time
               | xcon:provide-anonymity
               | xcon:floor
               | xcon:entry
               | xcon:mixing-start-offset
               | xcon:mixing-end-offset
               | xcon:can-join-after-offset
               | xcon:must-join-before-offset
               | xcon:request-user
               | xcon:notify-end-of-conference
               | xcon:allowed-extend-mixing-end-offset
               | xcon:codec
               | xcon:subtype
               | xcon:mute
               | xcon:pause-video
               | xcon:gain
               | xcon:video-layout
               | xcon:conference-ID
               | xcon:allow-floor-events
               | xcon:floor-request-handling
               | xcon:conference-floor-policy
               | xcon:media-label
               | xcon:algorithm
               | xcon:max-floor-users
               | xcon:moderator-id
               | xcon:target
               | xcon:persistent-list

Top      Up      ToC       Page 39 
               | xcon:e-mail
               | xcon:user) { anyExtension }
anyExtension =
  (attribute * { text }
   | any)*
any =
  element * {
    (attribute * { text }
     | text
     | any)*
  }

# EXTENSIBILITY ATTRIBUTES
#

anyAttribute =
  attribute * - (xml:lang
                 | entity
                 | required-participant
                 | label
                 | decision
                 | name
                 | policy
                 | uri
                 | method
                 | id
                 | nickname) { text }*



(page 39 continued on part 3)

Next RFC Part