draft-ietf-xcon-common-data-model-19.txt   draft-ietf-xcon-common-data-model-20.txt 
XCON O. Novo XCON O. Novo
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: November 20, 2010 D. Morgan Expires: April 18, 2011 D. Morgan
Fidelity Investments Fidelity Investments
J. Urpalainen J. Urpalainen
Nokia Nokia
May 19, 2010 Oct 15, 2010
Conference Information Data Model for Centralized Conferencing (XCON) Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-19.txt draft-ietf-xcon-common-data-model-20.txt
Abstract Abstract
This document defines an Extensible Markup Language (XML)-based This document defines an Extensible Markup Language (XML)-based
conference information data model for centralized conferencing conference information data model for centralized conferencing
(XCON). A conference information data model is designed to convey (XCON). A conference information data model is designed to convey
information about the conference and about participation in the information about the conference and about participation in the
conference. The conference information data model defined in this conference. The conference information data model defined in this
document constitutes an extension of the data format specified in the document constitutes an extension of the data format specified in the
Session Initiation Protocol (SIP) Event Package for Conference State. Session Initiation Protocol (SIP) Event Package for Conference State.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 20, 2010. This Internet-Draft will expire on April 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 32 skipping to change at page 3, line 32
4.2.4. <free-text> . . . . . . . . . . . . . . . . . . . . . 16 4.2.4. <free-text> . . . . . . . . . . . . . . . . . . . . . 16
4.2.5. <keywords> . . . . . . . . . . . . . . . . . . . . . . 16 4.2.5. <keywords> . . . . . . . . . . . . . . . . . . . . . . 16
4.2.6. <allow-sidebars> . . . . . . . . . . . . . . . . . . . 16 4.2.6. <allow-sidebars> . . . . . . . . . . . . . . . . . . . 16
4.2.7. <cloning-parent> . . . . . . . . . . . . . . . . . . . 16 4.2.7. <cloning-parent> . . . . . . . . . . . . . . . . . . . 16
4.2.8. <sidebar-parent> . . . . . . . . . . . . . . . . . . . 16 4.2.8. <sidebar-parent> . . . . . . . . . . . . . . . . . . . 16
4.2.9. <conference-time> . . . . . . . . . . . . . . . . . . 16 4.2.9. <conference-time> . . . . . . . . . . . . . . . . . . 16
4.2.10. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 18 4.2.10. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 18
4.2.11. <service-uris> . . . . . . . . . . . . . . . . . . . . 18 4.2.11. <service-uris> . . . . . . . . . . . . . . . . . . . . 18
4.2.12. <maximum-user-count> . . . . . . . . . . . . . . . . . 18 4.2.12. <maximum-user-count> . . . . . . . . . . . . . . . . . 18
4.2.13. <available-media> . . . . . . . . . . . . . . . . . . 18 4.2.13. <available-media> . . . . . . . . . . . . . . . . . . 18
4.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 21 4.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 21 4.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 21
4.4.1. <allow-conference-event-subscription> . . . . . . . . 21 4.4.1. <allow-conference-event-subscription> . . . . . . . . 21
4.4.2. <user-count> . . . . . . . . . . . . . . . . . . . . . 21 4.4.2. <user-count> . . . . . . . . . . . . . . . . . . . . . 21
4.4.3. <active> . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.3. <active> . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.4. <locked> . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.4. <locked> . . . . . . . . . . . . . . . . . . . . . . . 21
4.5. <floor-information> . . . . . . . . . . . . . . . . . . . 21 4.5. <floor-information> . . . . . . . . . . . . . . . . . . . 21
4.5.1. <conference-ID> . . . . . . . . . . . . . . . . . . . 22 4.5.1. <conference-ID> . . . . . . . . . . . . . . . . . . . 21
4.5.2. <allow-floor-events> . . . . . . . . . . . . . . . . . 22 4.5.2. <allow-floor-events> . . . . . . . . . . . . . . . . . 22
4.5.3. <floor-request-handling> . . . . . . . . . . . . . . . 22 4.5.3. <floor-request-handling> . . . . . . . . . . . . . . . 22
4.5.4. <conference-floor-policy> . . . . . . . . . . . . . . 23 4.5.4. <conference-floor-policy> . . . . . . . . . . . . . . 22
4.6. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.6. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6.1. <join-handling> . . . . . . . . . . . . . . . . . . . 24 4.6.1. <join-handling> . . . . . . . . . . . . . . . . . . . 23
4.6.2. <user-admission-policy> . . . . . . . . . . . . . . . 24 4.6.2. <user-admission-policy> . . . . . . . . . . . . . . . 24
4.6.3. <allowed-users-list> . . . . . . . . . . . . . . . . . 25 4.6.3. <allowed-users-list> . . . . . . . . . . . . . . . . . 24
4.6.4. <deny-users-list> . . . . . . . . . . . . . . . . . . 26 4.6.4. <deny-users-list> . . . . . . . . . . . . . . . . . . 25
4.6.5. <user> and Its <user> Sub-elements . . . . . . . . . . 26 4.6.5. <user> and Its <user> Sub-elements . . . . . . . . . . 26
4.6.5.1. <display-text> . . . . . . . . . . . . . . . . . . 27 4.6.5.1. <display-text> . . . . . . . . . . . . . . . . . . 27
4.6.5.2. <associated-aors> . . . . . . . . . . . . . . . . 27 4.6.5.2. <associated-aors> . . . . . . . . . . . . . . . . 27
4.6.5.3. <provide-anonymity> . . . . . . . . . . . . . . . 27 4.6.5.3. <provide-anonymity> . . . . . . . . . . . . . . . 27
4.6.5.4. <roles> . . . . . . . . . . . . . . . . . . . . . 28 4.6.5.4. <roles> . . . . . . . . . . . . . . . . . . . . . 28
4.6.5.5. <languages> . . . . . . . . . . . . . . . . . . . 28 4.6.5.5. <languages> . . . . . . . . . . . . . . . . . . . 28
4.6.5.6. <cascaded-focus> . . . . . . . . . . . . . . . . . 28 4.6.5.6. <cascaded-focus> . . . . . . . . . . . . . . . . . 28
4.6.5.7. <allow-refer-users-dynamically> . . . . . . . . . 28 4.6.5.7. <allow-refer-users-dynamically> . . . . . . . . . 28
4.6.5.8. <allow-invite-users-dynamically> . . . . . . . . . 28 4.6.5.8. <allow-invite-users-dynamically> . . . . . . . . . 28
4.6.5.9. <allow-remove-users-dynamically> . . . . . . . . . 29 4.6.5.9. <allow-remove-users-dynamically> . . . . . . . . . 29
4.6.5.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 29 4.6.5.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 29
4.7. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 30 4.7. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 30
4.8. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 30 4.8. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 30
5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30
6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 41 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 41
7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 51 8. Security Considerations . . . . . . . . . . . . . . . . . . . 51
8.1. Authentication, Access Control, and Integrity . . . . . . 51
8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 52
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 52 9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 52
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 52 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 53
9.3. Conference Object Identifier Registration . . . . . . . . 53 9.3. Conference Object Identifier Registration . . . . . . . . 53
9.4. Conference User Identifier Registration . . . . . . . . . 54 9.4. Conference User Identifier Registration . . . . . . . . . 54
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.1. Normative References . . . . . . . . . . . . . . . . . . . 55 11.1. Normative References . . . . . . . . . . . . . . . . . . . 55
11.2. Informative References . . . . . . . . . . . . . . . . . . 55 11.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56
Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 84 Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
skipping to change at page 10, line 18 skipping to change at page 10, line 18
XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ]
conf-object-id = 1*( unreserved / "+" / "=" / "/" ) conf-object-id = 1*( unreserved / "+" / "=" / "/" )
host, port, and unreserved are defined in RFC3986[RFC3986] host, port, and unreserved are defined in RFC3986[RFC3986]
3.3.2. Normalization and Conference Object URI Comparison 3.3.2. Normalization and Conference Object URI Comparison
In order to facilitate the comparison of the XCON-URI identifiers, In order to facilitate the comparison of the XCON-URI identifiers,
all the components of the identifiers SHOULD be converted to all the components of the identifiers MUST be converted to lowercase.
lowercase. After normalizing the URI strings, the URIs comparison After normalizing the URI strings, the URIs comparison MUST applied a
SHOULD applied a character-by-character basis as prescribed by character-by-character basis as prescribed by RFC3986, Section 6.2.1.
RFC3986, Section 6.2.1.
3.4. Data Model Structure 3.4. Data Model Structure
The information in this data model is structured in the following The information in this data model is structured in the following
manner. All the information related to a conference is contained in manner. All the information related to a conference is contained in
a <conference-info> element. The <conference-info> element contains a <conference-info> element. The <conference-info> element contains
the following child elements: the following child elements:
o The <conference-description> element describes the conference as a o The <conference-description> element describes the conference as a
whole. It has, for instance, information about the URI of the whole. It has, for instance, information about the URI of the
skipping to change at page 15, line 28 skipping to change at page 15, line 28
The <conference-info> element contains the <conference-description>, The <conference-info> element contains the <conference-description>,
<host-info>, <conference-state>, <floor-information>, <users>, <host-info>, <conference-state>, <floor-information>, <users>,
<sidebars-by-ref>, and <sidebars-by-val> child elements. All these <sidebars-by-ref>, and <sidebars-by-val> child elements. All these
elements, except <floor-information>, are defined in [RFC4575]. A elements, except <floor-information>, are defined in [RFC4575]. A
conference document MUST at least include the <conference- conference document MUST at least include the <conference-
description> and <users> child elements. description> and <users> child elements.
4.2. <conference-description> 4.2. <conference-description>
The <conference-description> element, which is defined in [RFC4575], The <conference-description> element, which is defined in [RFC4575],
describes the conference as a whole. It should have an extra describes the conference as a whole. It SHOULD have an extra
attribute 'lang' to specify the language used in the contents of this attribute 'lang' to specify the language used in the contents of this
element. It is comprised of <language>, <display-text>, <subject>, element. It is comprised of <language>, <display-text>, <subject>,
<free-text>, <keywords>, <allow-sidebars>, <cloning-parent>, <free-text>, <keywords>, <allow-sidebars>, <cloning-parent>,
<sidebar-parent>, <conference-time>, <conf-uris>, <service-uris>, <sidebar-parent>, <conference-time>, <conf-uris>, <service-uris>,
<maximum-user-count>, and <available-media>. <maximum-user-count>, and <available-media>.
The following sections describe these elements in more detail. Other The following sections describe these elements in more detail. Other
child elements MAY be defined in the future to extend the child elements MAY be defined in the future to extend the
<conference-description> element. <conference-description> element.
skipping to change at page 16, line 45 skipping to change at page 16, line 45
<sidebar-parent> element contains the conference object Identifier <sidebar-parent> element contains the conference object Identifier
(XCON-URI) (different from the main XCON-URI) of the parent. (XCON-URI) (different from the main XCON-URI) of the parent.
4.2.9. <conference-time> 4.2.9. <conference-time>
The <conference-time> element contains the information related to The <conference-time> element contains the information related to
conference time, policy, and duration of a conference. The conference time, policy, and duration of a conference. The
<conference-time> element contains one or more <entry> elements each <conference-time> element contains one or more <entry> elements each
defining the time and policy information specifying a single defining the time and policy information specifying a single
conference occurrence. The <conference-time> element differs from conference occurrence. The <conference-time> element differs from
the iCalendar objects [RFC5545] in the possibility to defined the iCalendar objects [RFC5545] in the possibility to define
different policies (<can-join-after-offset>, <must-join-before- different policies (<can-join-after-offset>, <must-join-before-
offset>) for the same conference at different times. offset>) for the same conference at different times.
Every <entry> element contains the following child elements: Every <entry> element contains the following child elements:
o <base>: The <base> child element specifies the iCalendar object of o <base>: The <base> child element specifies the iCalendar object of
the conference. The iCalendar object components are defined in the conference. The iCalendar object components are defined in
[RFC5545]. [RFC5545].
o <mixing-start-offset>: The <mixing-start-offset> child element o <mixing-start-offset>: The <mixing-start-offset> child element
specifies when the conference media mixing starts before the specifies when the conference media mixing starts before the
skipping to change at page 17, line 23 skipping to change at page 17, line 23
'required-participant' attribute. This attribute contains one of 'required-participant' attribute. This attribute contains one of
the following values: "none", "administrator", "moderator", the following values: "none", "administrator", "moderator",
"user", "observer", and "participant". The roles semantic "user", "observer", and "participant". The roles semantic
definition is out of the scope of this document and is subject to definition is out of the scope of this document and is subject to
future policy documents. More values can be specified in the future policy documents. More values can be specified in the
future. The 'required-participant' attribute allows a privileged future. The 'required-participant' attribute allows a privileged
user to define when media mixing starts based on the latter of the user to define when media mixing starts based on the latter of the
mixing start time, and the time the first participant arrives. If mixing start time, and the time the first participant arrives. If
the value is set to "none'", mixing starts according to the mixing the value is set to "none'", mixing starts according to the mixing
start time. start time.
o <mixing-end-offset>: The <mixing-end-offset> child element that o <mixing-end-offset>: The <mixing-end-offset> child element
specifies the time a conference media mixing stops after the specifies the time a conference media mixing stops after the
conference stops. If the <mixing-end-offset> element is not conference stops. If the <mixing-end-offset> element is not
present, it indicates that the conference occurrence is not present, it indicates that the conference occurrence is not
bounded. The <mixing-end-offset> element has the mandatory bounded. The <mixing-end-offset> element has the mandatory
'required-participant' attribute. This attribute contains one of 'required-participant' attribute. This attribute contains one of
the following values: "none", "administrator", "moderator", the following values: "none", "administrator", "moderator",
"observer", "user", and "participant". More values can be "observer", "user", and "participant". More values can be
specified in the future. The 'required-participant' attribute specified in the future. The 'required-participant' attribute
allows a privileged user to define when media mixing ends based on allows a privileged user to define when media mixing ends based on
the earlier of the <mixing-end-offset>, and the time the last the earlier of the <mixing-end-offset>, and the time the last
skipping to change at page 17, line 45 skipping to change at page 17, line 45
according to the <mixing-end-offset>. If the conference policy according to the <mixing-end-offset>. If the conference policy
was modified so that last privileged user is now a normal was modified so that last privileged user is now a normal
conference participant, and the conference requires a privileged conference participant, and the conference requires a privileged
user to continue; that conference MUST terminate. user to continue; that conference MUST terminate.
o <can-join-after-offset>: An administrator can indicate the time o <can-join-after-offset>: An administrator can indicate the time
when users can join a conference by populating the <can-join- when users can join a conference by populating the <can-join-
after-offset> element. after-offset> element.
o <must-join-before-offset>: An administrator can define the time o <must-join-before-offset>: An administrator can define the time
after which new users are not allowed to join the conference after which new users are not allowed to join the conference
anymore. anymore.
o <request-user>: It is possible to define the time when users or o <request-user>: It defines the time when users or resources on the
resources on the <allowed-users-list> are requested to join the <allowed-users-list> are requested to join the conference by using
conference by using the <request-users> element. the <request-users> element.
o <notify-end-of-conference>: The <notify-end-of-conference> element o <notify-end-of-conference>: The <notify-end-of-conference> element
defines in seconds when the system has to send a notification when defines in seconds when the system MUST send a notification when
the end of the conference is approaching. If the <notify-end-of- the end of the conference is approaching. If the <notify-end-of-
conference> element is not present, it indicates that the system conference> element is not present, it indicates that the system
does not notify the users when the end of the conference is does not notify the users when the end of the conference is
approaching. approaching.
o <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing- o <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
end-offset> refers to the possibility to extend the conference. end-offset> refers to the possibility to extend the conference.
It has a boolean value. It has a boolean value.
4.2.10. <conf-uris> 4.2.10. <conf-uris>
The <conf-uris> contains the identifiers to be used in order to The <conf-uris> element contains the identifiers to be used in order
access the conference by different signaling means. This document to access the conference by different signaling means. This document
describes a new element, <conference-password>. This element describes a new element, <conference-password>. This element
contains the password(s) of the conference, for instance, PSTN contains the password(s) of the conference, for instance, PSTN
conference will store the 'PIN code' in this element. All the other conference will store the 'PIN code' in this element. All the other
<conf-uris> child element are described in section 5.3.1 of <conf-uris> child element are described in section 5.3.1 of
[RFC4575]. Future extensions to this schema may define new values [RFC4575].
and register them with IANA.
4.2.11. <service-uris> 4.2.11. <service-uris>
The <service-uris> describes auxiliary services available for the The <service-uris> describes auxiliary services available for the
conference. The <service-uris> element is described in section 5.3.2 conference. The <service-uris> element is described in section 5.3.2
of [RFC4575]. Future extensions to this schema may define new values of [RFC4575].
and register them with IANA.
4.2.12. <maximum-user-count> 4.2.12. <maximum-user-count>
The <maximum-user-count> contains the overall number of users allowed The <maximum-user-count> contains the overall number of users allowed
to join the conference. Note that this value is set by an to join the conference. Note that this value is set by an
administrator and can reflect any local policies such as network administrator and can reflect any local policies such as network
consumption, CPU processing power, and licensing rules. consumption, CPU processing power, and licensing rules.
4.2.13. <available-media> 4.2.13. <available-media>
skipping to change at page 19, line 35 skipping to change at page 19, line 33
control elements for a conference. It is expected that for the control elements for a conference. It is expected that for the
majority of the basic conferences, these controls are sufficient. majority of the basic conferences, these controls are sufficient.
If the conference server wants to support more advanced controls, If the conference server wants to support more advanced controls,
then it is recommended that an extension to the data model be then it is recommended that an extension to the data model be
used. In the <controls> element the schema is extensible, hence used. In the <controls> element the schema is extensible, hence
new control types can be added in the future. So moderator new control types can be added in the future. So moderator
controls that affect all media output would go under the controls that affect all media output would go under the
<available-media> element. The following controls elements are <available-media> element. The following controls elements are
defined for <controls>: defined for <controls>:
* The <mute> element is used in conjunction with an audio stream * The <mute> element is used in conjunction with an audio stream
to cease transmission of associated media. That means that for to cease transmission of any audio from the associated stream.
the entire duration where mute is applicable, all current and That means that for the entire duration where mute is
future participants of the conference are muted and will not applicable, all current and future participants of the
receive any audio. It has a "boolean" value. If this control conference are muted and will not receive any audio. It has a
is not specified, access to the control is not available to the "boolean" value. If this control is not specified, access to
client. the control is not available to the client.
* The <pause-video> element is used in conjunction with a video * The <pause-video> element is used in conjunction with a video
stream to cease transmission of associated media. It has a stream to cease transmission of associated media. It has a
"boolean" value. If this control is not specified, the access "boolean" value. If this control is not specified, the access
to the control is not available to the client. to the control is not available to the client.
* The <gain> element is used in conjunction with a media output * The <gain> element is used in conjunction with a media output
stream to indicate the amount of amplification of an audio stream to indicate the amount of amplification of an audio
stream. The value is an integer number that ranges from -127 stream. The value is an integer number that ranges from -127
to 127. If this control is not specified, access to the to 127. If this control is not specified, access to the
control is not available to the client. control is not available to the client.
* The <video-layout> element is used in conjunction with a video * The <video-layout> element is used in conjunction with a video
stream to specify how the video streams (of participants) are stream to specify how the video streams (of participants) are
viewed by each participant. Only one layout type can be viewed by each participant. Only one layout type can be
specified for each output stream. If there are fewer specified for each output stream. If there are fewer
participants than panels in the specified layout, then blanking participants than panels in the specified layout, then blanking
(black screen) MAY be mixed into the stream on the behalf of (black screen) MAY be mixed into the stream on the behalf of
the missing input streams. If unspecified, the <video-layout> the missing input streams. If unspecified, the <video-layout>
default type SHOULD be "single-view". The <video-layout> types default type SHOULD be "single-view". The <video-layout> types
are as follows, although any number of custom layouts may be are as follows, although any number of custom layouts may be
specified in future extensions: specified in future extensions:
skipping to change at page 21, line 8 skipping to change at page 20, line 49
+ multiple-5x1: This option refers to a 5x1 layout where one + multiple-5x1: This option refers to a 5x1 layout where one
panel will occupy 4/9 of the mixed video stream while the panel will occupy 4/9 of the mixed video stream while the
others will each occupy 1/9 of the stream. Typically the others will each occupy 1/9 of the stream. Typically the
aspect ratio of the streams is preserved. aspect ratio of the streams is preserved.
+ automatic: This option allows the focus to add panels as + automatic: This option allows the focus to add panels as
streams are added. streams are added.
4.3. <host-info> 4.3. <host-info>
The <host-info> element contains information about the entity hosting The <host-info> element contains information about the entity hosting
the conference. This information is set before conference the conference. This information is usually set before conference
activation, and is rarely changed during the conference lifetime. activation, and is rarely changed during the conference lifetime.
The <host-info> element and its child elements are described in The <host-info> element and its child elements are described in
[RFC4575], section 5.4. Future extensions to the <host-info> element [RFC4575], section 5.4. Future extensions to the <host-info> element
may define new values. may define new values.
4.4. <conference-state> 4.4. <conference-state>
The <conference-state> is introduced in [RFC4575]. The <conference- The <conference-state> is introduced in [RFC4575]. The <conference-
state> element contains the <allow-conference-event-subscription>, state> element contains the <allow-conference-event-subscription>,
<user-count>, <active>, and <locked> child elements. <user-count>, <active>, and <locked> child elements.
4.4.1. <allow-conference-event-subscription> 4.4.1. <allow-conference-event-subscription>
skipping to change at page 21, line 26 skipping to change at page 21, line 20
The <conference-state> is introduced in [RFC4575]. The <conference- The <conference-state> is introduced in [RFC4575]. The <conference-
state> element contains the <allow-conference-event-subscription>, state> element contains the <allow-conference-event-subscription>,
<user-count>, <active>, and <locked> child elements. <user-count>, <active>, and <locked> child elements.
4.4.1. <allow-conference-event-subscription> 4.4.1. <allow-conference-event-subscription>
The <allow-conference-event-subscription> element represents a The <allow-conference-event-subscription> element represents a
boolean action. If set to TRUE, the focus is instructed to allow the boolean action. If set to TRUE, the focus is instructed to allow the
subscription to conference state events, such as 'SIP Event Package subscription to conference state events, such as 'SIP Event Package
for Conference State' [RFC4575]. If set to FALSE, the subscription for Conference State' [RFC4575]. If set to FALSE, the subscription
to conference state events would be rejected. If this element is to conference state events MUST be rejected. If this element is
undefined it has a default value of TRUE, causing the subscription to undefined it has a default value of TRUE, causing the subscription to
conference state events to be accepted. conference state events to be accepted.
4.4.2. <user-count> 4.4.2. <user-count>
The <user-count> child element is explained in [RFC4575], section The <user-count> child element is explained in [RFC4575], section
5.5.1. 5.5.1.
4.4.3. <active> 4.4.3. <active>
skipping to change at page 22, line 24 skipping to change at page 22, line 16
4.5.2. <allow-floor-events> 4.5.2. <allow-floor-events>
The <allow-floor-events> element represents a boolean action. If set The <allow-floor-events> element represents a boolean action. If set
to TRUE, the focus is instructed to accept the subscription to floor to TRUE, the focus is instructed to accept the subscription to floor
control events. If set to FALSE, the focus is instructed to reject control events. If set to FALSE, the focus is instructed to reject
the subscription. If this element is undefined, it has a default the subscription. If this element is undefined, it has a default
value of FALSE, causing the subscription to floor control events to value of FALSE, causing the subscription to floor control events to
be rejected. be rejected.
There are two methods which a conference participant subscribes A conference participant can subscribe himself to a floor control
himself to a floor control event. One method is using an offer/ event in two different ways: one method is using an offer/answer
answer exchange mechanism ([RFC3264]) using SIP INVITE and BFCP exchange mechanism ([RFC3264]) using SIP INVITE and BFCP parameters
parameters in the SDP ([RFC4583]). The other method is a general in the SDP ([RFC4583]), the other method is a general authorization
authorization mechanism described in section 9 of [RFC4582] and in mechanism described in section 9 of [RFC4582] and in [RFC5018].
[RFC5018]. Future documentation may define additional connection Future documentation may define additional connection mechanisms.
mechanisms.
4.5.3. <floor-request-handling> 4.5.3. <floor-request-handling>
The <floor-request-handling> element defines the actions used by the The <floor-request-handling> element defines the actions used by the
conference focus to control floor requests. This element defines the conference focus to control floor requests. This element defines the
action that the focus is to take when processing a particular request action that the focus is to take when processing a particular request
to a floor within a conference. This element defines values of: to a floor within a conference. This element defines values of:
o "block": This action instructs the focus to deny the floor o "block": This action instructs the focus to deny the floor
request. This action is the default action taken in the absence request. This action is the default action taken in the absence
skipping to change at page 23, line 9 skipping to change at page 22, line 47
Note that this section discusses floor control information, Note that this section discusses floor control information,
therefore, the value "block" in a <floor-request-handling> element is therefore, the value "block" in a <floor-request-handling> element is
not related with the "block" value in the <join-handling> element not related with the "block" value in the <join-handling> element
(see Section 4.6). (see Section 4.6).
4.5.4. <conference-floor-policy> 4.5.4. <conference-floor-policy>
The <conference-floor-policy> element has one or more <floor> child The <conference-floor-policy> element has one or more <floor> child
elements. Every <floor> child elements has an attribute 'id' which elements. Every <floor> child elements has an attribute 'id' which
uniquely identifies a floor or floors within a conference. In the uniquely identifies a floor within a conference. In the case of BFCP
case of BFCP [RFC4582], the 'id' attribute corresponds to the [RFC4582], the 'id' attribute corresponds to the floor-id identifier
floor-id identifier defined in [RFC4582] section 5.2.2. defined in [RFC4582] section 5.2.2.
o <media-label>: Every floor is identified for one or more mandatory o <media-label>: Every floor is identified for one or more mandatory
<media-label> element. If the <available-media> information is <media-label> element. If the <available-media> information is
included in the conference document, the value of this element included in the conference document, the value of this element
MUST be equal to the 'label' value of the corresponding media MUST be equal to the 'label' value of the corresponding media
stream <entry> in the <available-media> container. The number of stream <entry> in the <available-media> container. The number of
those elements indicates how many floors the conference can have. those elements indicates how many floors the conference can have.
A floor can be used for one or more media types; A floor can be used for one or more media types;
o <algorithm>: A floor can be controlled using many algorithms; the o <algorithm>: A floor can be controlled using many algorithms; the
mandatory <algorithm> element MUST be set to any of the mandatory <algorithm> element MUST be set to any of the
skipping to change at page 26, line 37 skipping to change at page 26, line 27
(XCON-USERID) within the scope of the conference. The URI format of (XCON-USERID) within the scope of the conference. The URI format of
this identifier is as follow: this identifier is as follow:
XCON-USERID = "xcon-userid" ":" conf-user-id XCON-USERID = "xcon-userid" ":" conf-user-id
conf-user-id = 1*(unreserved) conf-user-id = 1*(unreserved)
[unreserved is defined in RFC3986] [unreserved is defined in RFC3986]
In order to facilitate the comparison of the XCON-USERID identifiers, In order to facilitate the comparison of the XCON-USERID identifiers,
all the components of the identifiers SHOULD be converted to all the components of the identifiers MUST be converted to lowercase.
lowercase. After normalizing the URI strings, the URIs comparison After normalizing the URI strings, the URIs comparison MUST applied a
SHOULD applied a character-by-character basis as prescribed by character-by-character basis as prescribed by RFC3986, Section 6.2.1.
RFC3986, Section 6.2.1.
Other user identifiers can be associated with this conference user Other user identifiers can be associated with this conference user
identifier and enable the conferencing system to correlate and map identifier and enable the conferencing system to correlate and map
these multiple authenticated user identities to a single global user these multiple authenticated user identities to a single global user
identifier. Figure 4 illustrates an example using the conference identifier. Figure 4 illustrates an example using the conference
user identifier in association with the user identity defined for user identifier in association with the user identity defined for
BFCP, SIP, and H323 user identity. It should be noted that a BFCP, SIP, and H323 user identity. It should be noted that a
conferencing system is free to structure such relationships as conferencing system is free to structure such relationships as
required and this information is just included as a guideline that required and this information is just included as a guideline.
can be used.
+----------------+ +----------------+
| Conference | | Conference |
| User | | User |
| Identifier | | Identifier |
+----------------+ +----------------+
|xcon-userid:John| |xcon-userid:John|
+-------+--------+ +-------+--------+
| |
| |
skipping to change at page 28, line 14 skipping to change at page 28, line 14
element has three values: 'private', 'semi-private' and 'hidden'. element has three values: 'private', 'semi-private' and 'hidden'.
The 'private' value specifies that this user is completely anonymous The 'private' value specifies that this user is completely anonymous
in the conference. 'semi-private' value specifies that this user is in the conference. 'semi-private' value specifies that this user is
anonymous to all users with equal or lesser permissions in the anonymous to all users with equal or lesser permissions in the
conference. 'hidden' value specifies that other users can not see conference. 'hidden' value specifies that other users can not see
this participant in the conference. this participant in the conference.
4.6.5.4. <roles> 4.6.5.4. <roles>
A role provides the context for the set of conference operations that A role provides the context for the set of conference operations that
a participant can perform. This element can contain one of the a participant can perform. This element can contain one or more of
following values: "administrator", "moderator", "user", the following values: "administrator", "moderator", "user",
"participant", "observer", and "none". The roles semantic definition "participant", "observer", and "none". The roles semantic definition
is out of the scope of this document and is subject to future policy 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. This element can be extended with new roles in future
documents. documents.
4.6.5.5. <languages> 4.6.5.5. <languages>
The <languages> child element is explained in [RFC4575], section The <languages> child element is explained in [RFC4575], section
5.6.4. 5.6.4.
skipping to change at page 28, line 37 skipping to change at page 28, line 37
The <cascaded-focus> child element is explained in [RFC4575], section The <cascaded-focus> child element is explained in [RFC4575], section
5.6.5. 5.6.5.
4.6.5.7. <allow-refer-users-dynamically> 4.6.5.7. <allow-refer-users-dynamically>
The <allow-refer-users-dynamically> element represents a boolean The <allow-refer-users-dynamically> element represents a boolean
value. If set to TRUE, a participant is allowed to instruct the value. If set to TRUE, a participant is allowed to instruct the
focus to refer a user to the conference without modifying the focus to refer a user to the conference without modifying the
<allowed-users-list> (in SIP terms, a participant is allowed to send <allowed-users-list> (in SIP terms, a participant is allowed to send
a REFER request to the focus which results in the focus sending a a REFER request [RFC3515] to the focus which results in the focus
REFER request to the user the referrer wishes to join the sending a REFER request to the user the referrer wishes to join the
conference). If set to FALSE, the refer request is rejected. If conference). If set to FALSE, the refer request is rejected. If
this element is undefined it has a value of FALSE, causing the refer this element is undefined it has a value of FALSE, causing the refer
to be rejected. to be rejected.
4.6.5.8. <allow-invite-users-dynamically> 4.6.5.8. <allow-invite-users-dynamically>
The <allow-invite-users-dynamically> element represents a boolean The <allow-invite-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the action. If set to TRUE, a participant is allowed to instruct the
focus to invite a user to the conference without modifying the focus to invite a user to the conference without modifying the
<allowed-users-list> list (in SIP terms, a participant is allowed to <allowed-users-list> list (in SIP terms, a participant is allowed to
send a REFER request to the focus which results in the focus sending send a REFER request [RFC3515] to the focus which results in the
an INVITE request to the user the referrer wishes to join the focus sending an INVITE request to the user the referrer wishes to
conference). If set to FALSE, the refer request is rejected. If join the conference). If set to FALSE, the refer request is
this element is undefined it has a value of FALSE, causing the refer rejected. If this element is undefined it has a value of FALSE,
to be rejected. causing the refer to be rejected.
4.6.5.9. <allow-remove-users-dynamically> 4.6.5.9. <allow-remove-users-dynamically>
The <allow-remove-users-dynamically> element represents a boolean The <allow-remove-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the action. If set to TRUE, a participant is allowed to instruct the
focus to remove a user from the conference without modifying the focus to remove a user from the conference without modifying the
ruleset (in SIP terms, a participant is allowed to send a REFER ruleset (in SIP terms, a participant is allowed to send a REFER
request to the focus which results in the focus sending an BYE request [RFC3515] to the focus which results in the focus sending an
request to the user the referrer wishes to leave the conference). If BYE request to the user the referrer wishes to leave the conference).
set to FALSE, the refer request is rejected. If this element is If set to FALSE, the refer request is rejected. If this element is
undefined it has a value of FALSE, causing the refer to be rejected. undefined it has a value of FALSE, causing the refer to be rejected.
4.6.5.10. <endpoint> 4.6.5.10. <endpoint>
The <endpoint> child element is defined in [RFC4575]. It can provide The <endpoint> child element is identical to the element with the
the desired level of detail about the user's devices and their same name in [RFC4575] except that the 'state' attribute is not
signaling sessions taking part in the conference. The <endpoint> included. The 'state' attribute only applies to notification
element in this document does not defined the 'state' attribute mechanisms. The <endpoint> element can provide the desired level of
defined in [RFC4575] for the same element since the 'state' attribute detail about the user's devices and their signaling sessions taking
only applies to notification mechanisms. part in the conference.
The <endpoint> element has the following child elements: <display- The <endpoint> element has the following child elements: <display-
text>, <referred>, <status>, <joining-method>, <joining-info>, text>, <referred>, <status>, <joining-method>, <joining-info>,
<disconnection-method>, <disconnection-info>, <media>, <floor>,and <disconnection-method>, <disconnection-info>, <media>, <floor>,and
<call-info>. All the <endpoint> child elements are defined in <call-info>. All the <endpoint> child elements are defined in
[RFC4575] with the exception of the <floor> element. [RFC4575] with the exception of the <floor> element, <to-mixer>, and
the <from-mixer> element.
The <floor> element refers to the floor assigned to a certain The <floor> element refers to the floor assigned to a certain
participant in the conference. If a participant, for instance, needs participant in the conference. If a participant, for instance, needs
to talk in the conference, it first needs to get the floor from the 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' chair of the conference. The <floor> element has an attribute 'id'
which uniquely identifies a floor or floors within a conference. The which uniquely identifies a floor within a conference. The 'id'
'id' attribute corresponds to the floor-id identifier defined in attribute corresponds to the floor-id identifier defined in [RFC4582]
[RFC4582] section 5.2.2. The <floor> element has a "Boolean" value. section 5.2.2. The <floor> element has a "Boolean" value. A value
A value of FALSE indicates that this user does not hold the floor in of FALSE indicates that this user does not hold the floor in this
this moment. If this control is not specified, this user SHOULD NOT moment. If this control is not specified, this user SHOULD NOT
specify the floor option. specify the floor option.
Besides the <floor> element, the <endpoint>/<media> element has two Besides the <floor> element, the <endpoint>/<media> element has two
other child elements defined in this document, the <to-mixer>, and other child elements defined in this document, the <to-mixer>, and
the <from-mixer>: the <from-mixer>:
o <from-mixer>, <to-mixer>: These are controls that apply to a o <from-mixer>, <to-mixer>: These are controls that apply to a
user's media stream being sent from the mixer to the participants user's media stream being sent from the mixer to the participants
endpoint or to the mixer from the participants endpoint. The <to- endpoint or to the mixer from the participants endpoint. The <to-
mixer> element details properties associated with the incoming mixer> element details properties associated with the incoming
skipping to change at page 38, line 35 skipping to change at page 38, line 35
mixer-type = mixer-type =
attribute name { mixer-name-type } attribute name { mixer-name-type }
& anyAttribute & anyAttribute
& element xcon:controls { control-type }* & element xcon:controls { control-type }*
& anyElement* & anyElement*
# MIXER NAME TYPE # MIXER NAME TYPE
mixer-name-type = mixer-name-type =
"VideoIn" | "VideoOut" | "AudioOut" | "AudioIn" | free-text-extension "VideoIn" | "VideoOut" | "AudioOut" | "AudioIn" | free-text-extension
# FREE TEXT EXTENSION # FREE TEXT EXTENSION
# (re-define this as <notAllowed>, # (re-define this as <notAllowed/>,
# if extensions beyond this spec are not used) # if extensions beyond this spec are not used)
free-text-extension = text free-text-extension = text
# ********************************* # *********************************
# EXTENSIBILITY OF THE SCHEMA # EXTENSIBILITY OF THE SCHEMA
# ********************************* # *********************************
# EXTENSIBILITY ELEMENTS # EXTENSIBILITY ELEMENTS
# (re-define this as <empty/>, # (re-define this as <empty/>,
skipping to change at page 45, line 8 skipping to change at page 45, line 8
>true</xcon:allow-conference-event-subscription> >true</xcon:allow-conference-event-subscription>
</conference-state> </conference-state>
<!-- <!--
USERS USERS
--> -->
<users> <users>
<!-- <!--
USER BOB USER BOB
--> -->
<user entity="bob534"> <user entity="xcon-userid:bob534">
<display-text>Bob Hoskins</display-text> <display-text>Bob Hoskins</display-text>
<associated-aors> <associated-aors>
<entry> <entry>
<uri>mailto:bob@example.com</uri> <uri>mailto:bob@example.com</uri>
<display-text>email</display-text> <display-text>email</display-text>
</entry> </entry>
</associated-aors> </associated-aors>
<roles> <roles>
<entry>participant</entry> <entry>participant</entry>
</roles> </roles>
skipping to change at page 46, line 31 skipping to change at page 46, line 31
>false</xcon:allow-refer-users-dynamically> >false</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically <xcon:allow-invite-users-dynamically
>false</xcon:allow-invite-users-dynamically> >false</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically <xcon:allow-remove-users-dynamically
>false</xcon:allow-remove-users-dynamically> >false</xcon:allow-remove-users-dynamically>
</user> </user>
<!-- <!--
USER ALICE USER ALICE
--> -->
<user entity="alice334"> <user entity="xcon-userid:alice334">
<display-text>Alice Kay</display-text> <display-text>Alice Kay</display-text>
<associated-aors> <associated-aors>
<entry> <entry>
<uri>mailto:alice@example.com</uri> <uri>mailto:alice@example.com</uri>
<display-text>email</display-text> <display-text>email</display-text>
</entry> </entry>
</associated-aors> </associated-aors>
<roles> <roles>
<entry>moderator</entry> <entry>moderator</entry>
</roles> </roles>
skipping to change at page 48, line 14 skipping to change at page 48, line 14
>true</xcon:allow-refer-users-dynamically> >true</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically <xcon:allow-invite-users-dynamically
>true</xcon:allow-invite-users-dynamically> >true</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically <xcon:allow-remove-users-dynamically
>true</xcon:allow-remove-users-dynamically> >true</xcon:allow-remove-users-dynamically>
</user> </user>
<!-- <!--
USER CAROL USER CAROL
--> -->
<user entity="carol233"> <user entity="xcon-userid:carol233">
<display-text>Carol More</display-text> <display-text>Carol More</display-text>
<associated-aors> <associated-aors>
<entry> <entry>
<uri>mailto:carol@example.com</uri> <uri>mailto:carol@example.com</uri>
<display-text>email</display-text> <display-text>email</display-text>
</entry> </entry>
</associated-aors> </associated-aors>
<roles> <roles>
<entry>administrator</entry> <entry>administrator</entry>
</roles> </roles>
skipping to change at page 50, line 26 skipping to change at page 50, line 26
--> -->
<xcon:deny-users-list> <xcon:deny-users-list>
<xcon:target uri="sip:charlie@example.com"/> <xcon:target uri="sip:charlie@example.com"/>
</xcon:deny-users-list> </xcon:deny-users-list>
</users> </users>
<!-- <!--
SIDEBARS BY REFERENCE SIDEBARS BY REFERENCE
--> -->
<sidebars-by-ref> <sidebars-by-ref>
<entry> <entry>
<uri>conf223</uri> <uri>xcon:conf223</uri>
<display-text>private with Bob</display-text> <display-text>private with Bob</display-text>
</entry> </entry>
</sidebars-by-ref> </sidebars-by-ref>
<!-- <!--
SIDEBARS BY VALUE SIDEBARS BY VALUE
--> -->
<sidebars-by-val> <sidebars-by-val>
<entry entity="conf223"> <entry entity="conf223">
<users> <users>
<user entity="bob534"/> <user entity="xcon-userid:bob534"/>
<user entity="carol233"/> <user entity="xcon-userid:carol233"/>
</users> </users>
</entry> </entry>
</sidebars-by-val> </sidebars-by-val>
<!-- <!--
FLOOR INFORMATION FLOOR INFORMATION
--> -->
<xcon:floor-information> <xcon:floor-information>
<xcon:conference-ID>567</xcon:conference-ID> <xcon:conference-ID>567</xcon:conference-ID>
<xcon:allow-floor-events>true</xcon:allow-floor-events> <xcon:allow-floor-events>true</xcon:allow-floor-events>
<xcon:floor-request-handling <xcon:floor-request-handling
skipping to change at page 51, line 17 skipping to change at page 51, line 17
>moderator-controlled</xcon:algorithm> >moderator-controlled</xcon:algorithm>
<xcon:max-floor-users>1</xcon:max-floor-users> <xcon:max-floor-users>1</xcon:max-floor-users>
<xcon:moderator-id>234</xcon:moderator-id> <xcon:moderator-id>234</xcon:moderator-id>
</xcon:floor> </xcon:floor>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</conference-info> </conference-info>
Note that due to RFC formatting conventions, this documents splits Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters. Two backslash lines whose content would exceed 72 characters.
characters mark where line folding has taken place. These
backslashes would not appear in the actual XML data model.
8. Security Considerations 8. Security Considerations
There are numerous security considerations for this document. This There are numerous security considerations for this document. This
section considers them. section discusses them.
8.1. Authentication, Access Control, and Integrity This specification defines a data model for conference objects.
Different conferencing systems may use different protocols to provide
access to these conference objects. This section contains general
security considerations for the conference objects and for the
protocols. The specification of each particular protocol needs to
discuss how the specific protocol meets the security requirements
provided in this section.
Different conferencing protocols will support different types of A given conferencing system usually supports different protocols in
authentication mechanisms. Since a variety of signaling protocols order to implement different functions (e.g., SIP for session control
are possible, a variety of authentication mechanism - determined by and BFCP for floor control). Each of these protocols may use their
every individual conference servers - may need to be mapped from the own authentication mechanism. In cases where a user is authenticated
different protocols. The specific types of authentication mechanism using multiple authentication mechanisms, it is up to the
are beyond the scope of this document. conferencing system to map all the different authentications to the
same user. Discussing the specifics of different authentication
mechanism is beyond the scope of this document.
Futhermore, users may use different namespaces to access to a Futhermore, users may use different namespaces to access to a
conference. So a mapping database has to specify the acceptable conference as explained in Section 4.6.5. These different namespaces
range of namespace for a user. It is RECOMMENDED that the mapping can be associated with a unique conference user identifier (XCON-
database has integrity when it is established, the integrity has to USERID). A mapping database is used to map all these authenticated
be protected, and the database has to be maintained to ensure changes user namespaces to the XCON-USERID. There are several threats
in namespaces are accurately reflected. Doing so, users will not against this database. In order to minimize these threats, the
access the same conference twice using a different namespace. administrator of the conferencing system MUST ensure that only
authorized users can connect to this database (e.g., by using access
The security considerations for authentication (section 10.1) control rules). In particular, the integrity of the database MUST be
described in the centralized conferencing framework [RFC4575] applies protected against unauthorized modifications.
to this document. The focus must ensure that only authorized
entities are able to manipulate the data to access the information.
8.2. Confidentiality The confidentiality of the database SHOULD be protected from
unauthorized users, given that the data model contains a set of
sensitive elements (e.g., passwords). Therefore, in addition to
implementing access control, as discussed above, it is RECOMMENDED
that administrators of conferencing systems only provide access to
the database over encrypted channels (e.g., using TLS encryption) in
order to avoid eavesdroppers. Administrators of conferencing systems
SHOULD also avoid disclosing information to unauthorized parties when
a conference is being cloned or when a sidebar is being created.
Participants of a conference may not want to reveal some private The security considerations for authentication (Section 11.1)
information to other users. The Conference Information Data Model described in the centralized conferencing framework [RFC5239] also
contains sensitive data which should not be analyzed or given to apply to this document. Similarly, the security considerations for
anyone. Examples of potential attacks include eavesdropping or authorization (Section 5.2) described in the Session Initiation
illegal copying of sensitive information. The protocols used for Protocol (SIP) REFER Method [RFC3515] apply to this document as well.
manipulation and retrieval of sensitive conference information MUST
be able to provide confidentiality and integrity mechanism.
Confidentiality is provided through encryption. Strong end-to-end
authentication and encryption can be done using public keys, and end-
to-end encryption can be done using private keys. It is RECOMMENDED
that all the protocols that manipulated the conference information
data model implement TLS.
9. IANA Considerations 9. IANA Considerations
9.1. Relax NG Schema Registration 9.1. Relax NG Schema Registration
This specification registers a schema. The schema can be found This specification registers a schema. The schema can be found
as the sole content of Section 5. as the sole content of Section 5.
URI: urn:ietf:params:xml:ns:xcon-conference-info URI: urn:ietf:params:xml:ns:xcon-conference-info
Registrant Contact: IETF XCON working group, Registrant Contact: IETF XCON working group,
<xcon@ietf.org>, Oscar Novo <xcon@ietf.org>, Oscar Novo
<Oscar.Novo@ericsson.com> <Oscar.Novo@ericsson.com>
Relax NG Schema: The Relax NG schema to be registered is contained Relax NG Schema: The Relax NG schema to be registered is contained
in Section 5. Its first line is in Section 5. Its first line is
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" default namespace = "urn:ietf:params:xml:ns:conference-info"
and its last line is and its last line is
disconnection-type = "departed" | "booted" | "failed" | "busy" anyAttribute = attribute * - (xml:lang | entity
| required-participant | label | decision | name
| policy | uri | method | id | nickname) { text }*
9.2. XML Namespace Registration 9.2. XML Namespace Registration
This section registers a new XML namespace. This section registers a new XML namespace.
URI: urn:ietf:params:xml:ns:xcon-conference-info URI: urn:ietf:params:xml:ns:xcon-conference-info
Registrant Contact: IETF XCON working group, Registrant Contact: IETF XCON working group,
<xcon@ietf.org>, Oscar Novo <xcon@ietf.org>, Oscar Novo
<Oscar.Novo@ericsson.com> <Oscar.Novo@ericsson.com>
XML: XML:
skipping to change at page 53, line 38 skipping to change at page 53, line 41
[NOTE TO IANA/RFC-EDITOR: [NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this Please replace XXXX with the RFC number of this
specification.]</a>.</p> specification.]</a>.</p>
</body> </body>
</html> </html>
END END
9.3. Conference Object Identifier Registration 9.3. Conference Object Identifier Registration
The IANA is requested to register the following URI scheme The IANA is requested to register the following URI scheme
under the Permanent URI Schemes register. under the Permanent URI Schemes registry.
XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] [RFC xxxx] XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] [RFC xxxx]
conf-object-id = 1*( unreserved / "+" / "=" / "/" ) conf-object-id = 1*( unreserved / "+" / "=" / "/" )
host, port, and unreserved are defined in RFC3986[RFC3986] host, port, and unreserved are defined in RFC3986[RFC3986]
[Note to the RFC Editor: replace xxxx with the number this RFC gets [Note to the RFC Editor: replace xxxx with the number this RFC gets
assigned.] assigned.]
Subject: Request for XCON-URI Registration Subject: Request for XCON-URI Registration
Person & email address to contact for further information: Person & email address to contact for further information:
Oscar Novo <oscar novo_at_ericsson.com> Oscar Novo <oscar novo_at_ericsson.com>
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
Comments: Comments:
Identifies the Conference Identifies the Conference
9.4. Conference User Identifier Registration 9.4. Conference User Identifier Registration
skipping to change at page 54, line 15 skipping to change at page 54, line 19
Person & email address to contact for further information: Person & email address to contact for further information:
Oscar Novo <oscar novo_at_ericsson.com> Oscar Novo <oscar novo_at_ericsson.com>
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
Comments: Comments:
Identifies the Conference Identifies the Conference
9.4. Conference User Identifier Registration 9.4. Conference User Identifier Registration
The IANA is requested to register the following URI scheme The IANA is requested to register the following URI scheme
under the Permanent URI Schemes register. under the Permanent URI Schemes registry.
XCON-USERID = "xcon-userid" ":" conf-user-id [ RFC xxxx ] XCON-USERID = "xcon-userid" ":" conf-user-id [ RFC xxxx ]
conf-user-id = 1*(unreserved) conf-user-id = 1*(unreserved)
unreserved is defined in RFC3986[RFC3986] unreserved is defined in RFC3986[RFC3986]
[Note to the RFC Editor: replace xxxx with the number this RFC gets [Note to the RFC Editor: replace xxxx with the number this RFC gets
assigned.] assigned.]
skipping to change at page 56, line 5 skipping to change at page 56, line 10
[RELAX] "RELAX NG Home Page" "http://relaxng.org/". [RELAX] "RELAX NG Home Page" "http://relaxng.org/".
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, Session Initiation Protocol (SIP)", RFC 4353,
February 2006. February 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC5018] Camarillo, G., "Connection Establishment in the Binary [RFC5018] Camarillo, G., "Connection Establishment in the Binary
Floor Control Protocol (BFCP)", RFC 5018, September 2007. Floor Control Protocol (BFCP)", RFC 5018, September 2007.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[W3C.REC-xml-20001006] [W3C.REC-xml-20001006]
Sperberg-McQueen, C., Maler, E., Paoli, J., and T. Bray, Sperberg-McQueen, C., Bray, T., Paoli, J., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", "Extensible Markup Language (XML) 1.0 (Second Edition)",
World Wide Web Consortium FirstEdition REC-xml-20001006, World Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>. <http://www.w3.org/TR/2000/REC-xml-20001006>.
Appendix A. Non-Normative RELAX NG Schema in XML Syntax Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<grammar <grammar
ns="urn:ietf:params:xml:ns:conference-info" ns="urn:ietf:params:xml:ns:conference-info"
skipping to change at page 80, line 17 skipping to change at page 80, line 26
<choice> <choice>
<value>VideoIn</value> <value>VideoIn</value>
<value>VideoOut</value> <value>VideoOut</value>
<value>AudioOut</value> <value>AudioOut</value>
<value>AudioIn</value> <value>AudioIn</value>
<ref name="free-text-extension"/> <ref name="free-text-extension"/>
</choice> </choice>
</define> </define>
<!-- <!--
FREE TEXT EXTENSION FREE TEXT EXTENSION
(re-define this as <notAllowed>, (re-define this as <notAllowed/>,
if extensions beyond this spec are not used) if extensions beyond this spec are not used)
--> -->
<define name="free-text-extension"> <define name="free-text-extension">
<text/> <text/>
</define> </define>
<!-- <!--
********************************* *********************************
EXTENSIBILITY OF THE SCHEMA EXTENSIBILITY OF THE SCHEMA
********************************* *********************************
 End of changes. 58 change blocks. 
127 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/