draft-ietf-xcon-common-data-model-23.txt   draft-ietf-xcon-common-data-model-24.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: August 5, 2011 D. Morgan Expires: October 16, 2011 D. Morgan
Fidelity Investments Fidelity Investments
J. Urpalainen J. Urpalainen
Nokia Nokia
Feb 01, 2011 April 14, 2011
Conference Information Data Model for Centralized Conferencing (XCON) Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-23.txt draft-ietf-xcon-common-data-model-24.txt
Abstract Abstract
This document defines an Extensible Markup Language (XML)-based [RFC5239] defines the idea of a centralized conferencing (XCON) as an
conference information data model for centralized conferencing association of participants with a central focus. The state of a
(XCON). A conference information data model is designed to convey conference is represented by a conference object. This document
information about the conference and about participation in the defines an Extensible Markup Language (XML)-based conference
conference. The conference information data model defined in this information data model to be used for conference objects. A
document constitutes an extension of the data format specified in the conference information data model is designed to convey information
Session Initiation Protocol (SIP) Event Package for Conference State. about the conference and about participation in the conference. The
conference information data model defined in this document
constitutes an extension of the data format specified in the Session
Initiation Protocol (SIP) Event Package for Conference State
[RFC4575].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 5, 2011. This Internet-Draft will expire on October 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 31 skipping to change at page 3, line 31
4.2.3. <subject> . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. <subject> . . . . . . . . . . . . . . . . . . . . . . 16
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> . . . . . . . . . . . . . . . . . . 19
4.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 21 4.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 21 4.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 22
4.4.1. <allow-conference-event-subscription> . . . . . . . . 21 4.4.1. <allow-conference-event-subscription> . . . . . . . . 22
4.4.2. <user-count> . . . . . . . . . . . . . . . . . . . . . 21 4.4.2. <user-count> . . . . . . . . . . . . . . . . . . . . . 22
4.4.3. <active> . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.3. <active> . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.4. <locked> . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.4. <locked> . . . . . . . . . . . . . . . . . . . . . . . 22
4.5. <floor-information> . . . . . . . . . . . . . . . . . . . 22 4.5. <floor-information> . . . . . . . . . . . . . . . . . . . 22
4.5.1. <conference-ID> . . . . . . . . . . . . . . . . . . . 22 4.5.1. <conference-ID> . . . . . . . . . . . . . . . . . . . 22
4.5.2. <allow-floor-events> . . . . . . . . . . . . . . . . . 22 4.5.2. <allow-floor-events> . . . . . . . . . . . . . . . . . 23
4.5.3. <floor-request-handling> . . . . . . . . . . . . . . . 22 4.5.3. <floor-request-handling> . . . . . . . . . . . . . . . 23
4.5.4. <conference-floor-policy> . . . . . . . . . . . . . . 23 4.5.4. <conference-floor-policy> . . . . . . . . . . . . . . 23
4.6. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.6. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6.1. <join-handling> . . . . . . . . . . . . . . . . . . . 24 4.6.1. <join-handling> . . . . . . . . . . . . . . . . . . . 24
4.6.2. <user-admission-policy> . . . . . . . . . . . . . . . 24 4.6.2. <user-admission-policy> . . . . . . . . . . . . . . . 25
4.6.3. <allowed-users-list> . . . . . . . . . . . . . . . . . 25 4.6.3. <allowed-users-list> . . . . . . . . . . . . . . . . . 26
4.6.4. <deny-users-list> . . . . . . . . . . . . . . . . . . 26 4.6.4. <deny-users-list> . . . . . . . . . . . . . . . . . . 27
4.6.5. <user> and Its <user> Sub-elements . . . . . . . . . . 26 4.6.5. <user> and Its <user> Sub-elements . . . . . . . . . . 27
4.6.5.1. <display-text> . . . . . . . . . . . . . . . . . . 28 4.6.5.1. <display-text> . . . . . . . . . . . . . . . . . . 28
4.6.5.2. <associated-aors> . . . . . . . . . . . . . . . . 28 4.6.5.2. <associated-aors> . . . . . . . . . . . . . . . . 29
4.6.5.3. <provide-anonymity> . . . . . . . . . . . . . . . 28 4.6.5.3. <provide-anonymity> . . . . . . . . . . . . . . . 29
4.6.5.4. <roles> . . . . . . . . . . . . . . . . . . . . . 28 4.6.5.4. <roles> . . . . . . . . . . . . . . . . . . . . . 29
4.6.5.5. <languages> . . . . . . . . . . . . . . . . . . . 28 4.6.5.5. <languages> . . . . . . . . . . . . . . . . . . . 29
4.6.5.6. <cascaded-focus> . . . . . . . . . . . . . . . . . 29 4.6.5.6. <cascaded-focus> . . . . . . . . . . . . . . . . . 29
4.6.5.7. <allow-refer-users-dynamically> . . . . . . . . . 29 4.6.5.7. <allow-refer-users-dynamically> . . . . . . . . . 29
4.6.5.8. <allow-invite-users-dynamically> . . . . . . . . . 29 4.6.5.8. <allow-invite-users-dynamically> . . . . . . . . . 30
4.6.5.9. <allow-remove-users-dynamically> . . . . . . . . . 29 4.6.5.9. <allow-remove-users-dynamically> . . . . . . . . . 30
4.6.5.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 29 4.6.5.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 30
4.7. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 30 4.7. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 31
4.8. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 31 4.8. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 32
5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 31 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 32
6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 42 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 43
7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 51 8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 53 9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 54
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 53 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 54
9.3. Conference Object Identifier Registration . . . . . . . . 54 9.3. Conference Object Identifier Registration . . . . . . . . 55
9.4. Conference User Identifier Registration . . . . . . . . . 55 9.4. Conference User Identifier Registration . . . . . . . . . 56
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.1. Normative References . . . . . . . . . . . . . . . . . . . 56 11.1. Normative References . . . . . . . . . . . . . . . . . . . 57
11.2. Informative References . . . . . . . . . . . . . . . . . . 56 11.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 57 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 58
Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 85 Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95
1. Introduction 1. Introduction
There is a core data set of conference information that is utilized There is a core data set of conference information that is utilized
in any conference, independent of the specific conference media. in any conference, independent of the specific conference media.
This core data set called the 'conference information data model' is This core data set called the 'conference information data model' is
defined in this document using an Extensible Markup Language (XML)- defined in this document using an Extensible Markup Language (XML)-
based. The conference information data model defined in this based. The conference information data model defined in this
document is logically represented by the conference object. document is logically represented by the conference object.
Conference objects are a fundamental concept in Centralized Conference objects are a fundamental concept in Centralized
Conferencing, as described in the Centralized Conferencing Framework Conferencing, as described in the Centralized Conferencing Framework
[RFC5239]. A conference object contains data that represents a [RFC5239]. A conference object contains data that represents a
conference during each of its various stages (e.g., created/creation, conference during each of its various stages (e.g., created/creation,
reserved/reservation, active/activation, completed/completion). A reserved/reservation, active/activation, completed/completion). A
conference object can be manipulated using a conference control conference object can be manipulated using a conference control
protocol at a conference server. The conference object represents a protocol at a conference server. The conference object represents a
particular instantiation of a conference information data model. particular instantiation of a conference information data model.
Consequently, conference objects follow the XML format defined in Consequently, conference objects use the XML format defined in this
this document. document.
A conference object contains the core information of a conference A conference object contains the core information of a conference
(i.e., capabilities, membership, call control signaling, media, etc.) (i.e., capabilities, membership, call control signaling, media, etc.)
and specifies by whom, and in which way that information can be and specifies by whom, and in which way that information can be
manipulated. manipulated.
Figure 1 shows the logical functional elements of a conference server Figure 1 shows the logical functional elements of a conference server
as defined by the Centralized Conferencing Framework [RFC5239]. They as defined by the Centralized Conferencing Framework [RFC5239]. They
are a Conference Control Server, a Floor Control Server, a number of are a Conference Control Server, a Floor Control Server, a number of
Foci, and a Notification Service. A conference control protocol Foci, and a Notification Service. A conference control protocol
skipping to change at page 7, line 44 skipping to change at page 7, line 44
extensions to text elements. This data model can be used by extensions to text elements. This data model can be used by
conference servers providing different types of basic conferences. conference servers providing different types of basic conferences.
It is expected that this data model can be further extended with new It is expected that this data model can be further extended with new
elements in the future in order to implement additional advanced elements in the future in order to implement additional advanced
features. features.
3.1. Data Model Format 3.1. Data Model Format
A conference object document is an XML [W3C.REC-xml-20001006] A conference object document is an XML [W3C.REC-xml-20001006]
document that MUST be well formed and SHOULD be valid. Conference document that MUST be well formed and SHOULD be valid. Conference
object documents MUST be based on XML 1.0 and SHOULD be encoded using object documents MUST be based on Extensible Markup Language (XML)
UTF-8. 1.0 and SHOULD be encoded using UTF-8.
3.2. Data Model Namespace 3.2. Data Model Namespace
This specification defines a new namespace specification for This specification defines a new namespace specification for
identifying the elements defined in the data model. This namespace identifying the elements defined in the data model. This namespace
is as follows: is as follows:
urn:ietf:params:xml:ns:xcon-conference-info urn:ietf:params:xml:ns:xcon-conference-info
3.3. The Conference Object Identifier 3.3. The Conference Object Identifier
skipping to change at page 10, line 9 skipping to change at page 10, line 9
noted that a conferencing system is free to structure such noted that a conferencing system is free to structure such
relationships as required and this information is just included as a relationships as required and this information is just included as a
guideline that can be used. guideline that can be used.
Further elements can be added to the tree representation in Figure 2 Further elements can be added to the tree representation in Figure 2
to enable a complete representation of a conference instance within a to enable a complete representation of a conference instance within a
conferencing system. conferencing system.
3.3.1. Conference Object URI Definition 3.3.1. Conference Object URI Definition
XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] XCON-URI = "xcon" ":" [conf-object-id "@"] host
conf-object-id = 1*( unreserved / "+" / "=" / "/" ) conf-object-id = 1*( unreserved / "+" / "=" / "/" )
host, port, and unreserved are defined in RFC3986[RFC3986] host and unreserved are defined in RFC3986[RFC3986]
XCON-URI is a URI conference identifier and even though its XCON-URI is a URI conference identifier and even though its
construction is similar to a URL, in this case, the XCON-URI can not construction is similar to a URL, in this case, the XCON-URI can not
be resolved to addresses and/or ports. be resolved to addresses and/or ports.
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 MUST be converted to lowercase. all the components of the identifiers MUST be converted to lowercase.
After normalizing the URI strings, the URIs comparison MUST applied a After normalizing the URI strings, the URIs comparison MUST applied a
skipping to change at page 15, line 45 skipping to change at page 16, line 4
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.
4.2.1. <language> 4.2.1. <language>
The <language> element indicates the predominant language that is The <language> element indicates the predominant language that is
expected to be employed within a conference. The possible values of expected to be employed within a conference. The possible values of
this element are the values of the 'Subtag' column of the [RFC5646] this element are the values of the 'Subtag' column of the [RFC5646]
defined in IANA [IANA-Lan]. This element is not enforcing the defined in IANA [IANA-Lan]. This element does not enforce the
language of the conference, but only informs the participants about language of the conference, but only informs the participants about
the desirable language that they should use in the conference. the desirable language that they should use in the conference.
Participants are free to switch to other languages if they like. Participants are free to switch to other languages if they like.
4.2.2. <display-text> 4.2.2. <display-text>
The <display-text> element is described in section 5.3 of [RFC4575]. The <display-text> element is described in section 5.3 of [RFC4575].
4.2.3. <subject> 4.2.3. <subject>
skipping to change at page 19, line 35 skipping to change at page 19, line 48
<codec> element can have the attribute 'name' and 'policy'. The <codec> element can have the attribute 'name' and 'policy'. The
'name' attribute is a codec identifier assigned by the 'name' attribute is a codec identifier assigned by the
conferencing server. The 'policy' attribute contains the policy conferencing server. The 'policy' attribute contains the policy
for that codec (allowed, or disallowed). The <codec> element has for that codec (allowed, or disallowed). The <codec> element has
the child element <subtype> which stores the codec's name. The the child element <subtype> which stores the codec's name. The
possible values of this element are the values of the 'subtype' possible values of this element are the values of the 'subtype'
column of the RTP Payload Format media types per [RFC4855] defined column of the RTP Payload Format media types per [RFC4855] defined
in IANA [IANA]. It is expected that future conferencing in IANA [IANA]. It is expected that future conferencing
specifications will define corresponding schema extensions, as specifications will define corresponding schema extensions, as
appropriate. appropriate.
o The <controls> element contains the basic audio and video global o The <controls> element contains the basic audio and video global
control elements for a conference. It is expected that for the control elements for a conference. These controls are sufficient
majority of the basic conferences, these controls are sufficient. for the majority of basic conferences. If the conference server
If the conference server wants to support more advanced controls, wants to support more advanced controls, then it is RECOMMENDED
then it is recommended that an extension to the data model be that an extension to the data model be used. In the <controls>
used. In the <controls> element the schema is extensible, hence element the schema is extensible, hence new control types can be
new control types can be added in the future. So moderator added in the future. So moderator controls that affect all media
controls that affect all media output would go under the output would go under the <available-media> element. The
<available-media> element. The following controls elements are 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 any audio from the associated stream. to cease transmission of any audio from the associated stream.
That means that for the entire duration where mute is That means that for the entire duration where mute is
applicable, all current and future participants of the applicable, all current and future participants of the
conference are muted and will not receive any audio. It has a conference are muted and will not receive any audio. It has a
"boolean" value. If this control is not specified, access to "boolean" value. If this control is not specified, access to
the control is not available to the 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
skipping to change at page 23, line 51 skipping to change at page 24, line 36
[RFC4582] section 3. Note that [RFC4582] refers to the moderator [RFC4582] section 3. Note that [RFC4582] refers to the moderator
role as a 'floor chair'. role as a 'floor chair'.
4.6. <users> 4.6. <users>
The <users> element is described in [RFC4575] and contains the <join- The <users> element is described in [RFC4575] and contains the <join-
handling>, <user-admission-policy>, <allowed-users-list> and <deny- handling>, <user-admission-policy>, <allowed-users-list> and <deny-
users-list> defined in this document and <user> child elements users-list> defined in this document and <user> child elements
defined in [RFC4575]. Note that the <users> element does not have defined in [RFC4575]. Note that the <users> element does not have
the attribute 'state' defined in [RFC4575] for this element because the attribute 'state' defined in [RFC4575] for this element because
this attribute only applies to notifications mechanism. The this attribute only applies to notification mechanisms. The
following sections describe these elements in more detail. Other following sections describe these elements in more detail. Other
child elements and attributes can be used to extend <users> in the child elements and attributes can be used to extend <users> in the
future. future.
4.6.1. <join-handling> 4.6.1. <join-handling>
The <join-handling> element defines the actions used by the The <join-handling> element defines the actions used by the
conference focus to control conference participation. This element conference focus to control conference participation. This element
defines the action that the focus is to take when processing a defines the action that the focus is to take when processing a
particular request to join a conference. This element defines values particular request to join a conference. This element defines values
skipping to change at page 25, line 18 skipping to change at page 26, line 8
the conferencing system may join the conference. The the conferencing system may join the conference. The
'openAuthenticated' policy permits the specification of "banned" 'openAuthenticated' policy permits the specification of "banned"
conferencing participants. Such banned users are prevented from conferencing participants. Such banned users are prevented from
re-joining the conference until they have been un-banned. An re-joining the conference until they have been un-banned. An
'openAuthenticated' policy SHOULD have a deny users list (listed 'openAuthenticated' policy SHOULD have a deny users list (listed
under the <deny-users-list> XML element) to support banning of under the <deny-users-list> XML element) to support banning of
conferencing participants from a conference. An conferencing participants from a conference. An
'openAuthenticated' policy MUST NOT include an <allowed-users- 'openAuthenticated' policy MUST NOT include an <allowed-users-
list>. If <allowed-users-list> appears in the data model, it MUST list>. If <allowed-users-list> appears in the data model, it MUST
be ignored. be ignored.
o "anonymous": An 'anonymous' policy allows any join requests in and o "anonymous": An 'anonymous' policy allows any join requests in and
is the least restrictive policy. An 'anonymous' policy MUST NOT is the least restrictive policy. An 'anonymous' policy MUST NOT
include either an <allowed-users-list> or a <deny-users-list>. If 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. 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 In all other cases, the appearance of an <allowed-users-list> and
<deny-users-list> MUST be ignored. Future specifications describing <deny-users-list> MUST be ignored, except as otherwise described in a
the use of these lists must provide clear guidance on how to process future specification. Future specifications describing the use of
the lists when they occur concurrently, especially when both lists these lists must provide clear guidance on how to process the lists
contain the same user. For example, such specification could when they occur concurrently, especially when both lists contain the
disallow both list from appearing at the same time similar to user- same user. For example, such specification could disallow both list
admission-policy values defined in this document. from appearing at the same time similar to user-admission-policy
values defined in this document.
4.6.3. <allowed-users-list> 4.6.3. <allowed-users-list>
The <allowed-users-list> child element contains a list of user URIs The <allowed-users-list> child element contains a list of user URIs
(e.g. SIP URI, xcon-userid defined in Section 4.6.5), roles (defined (e.g. xcon-userid defined in Section 4.6.5), roles (defined in
in Section 4.6.5.4), or domains (e.g.: *@example.com) that the focus Section 4.6.5.4), or domains (e.g.: *@example.com) that the focus
uses to determine who can join the conference, who can be invited to 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 join a conference, or who the focus needs to "refer to" the
conference. The <allowed-users-list> element includes zero or more conference. The <allowed-users-list> element includes zero or more
<target> child elements. This child element includes the mandatory <target> child elements. This child element includes the mandatory
'uri' attribute and the mandatory 'method' attribute. The same 'uri' 'uri' attribute and the mandatory 'method' attribute. The same 'uri'
attribute with different method values can appear in the list more attribute with different method values can appear in the list more
than once. than once.
The 'method' attribute is a list with the following values: The 'method' attribute is a list with the following values:
skipping to change at page 27, line 11 skipping to change at page 27, line 51
'entity'. Note that the <user> element does not have the attribute 'entity'. Note that the <user> element does not have the attribute
'state' defined in [RFC4575] for this element because this attribute 'state' defined in [RFC4575] for this element because this attribute
only applies to notifications mechanism. only applies to notifications mechanism.
The attribute 'entity' contains a unique conference user identifier The attribute 'entity' contains a unique conference user identifier
(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 MUST be converted to lowercase. all the components of the identifiers MUST be converted to lowercase.
After normalizing the URI strings, the URIs comparison MUST applied a After normalizing the URI strings, the URIs comparison MUST applied a
character-by-character basis as prescribed by RFC3986, Section 6.2.1. character-by-character basis as prescribed by 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
skipping to change at page 28, line 27 skipping to change at page 29, line 18
section 5.6.2. section 5.6.2.
4.6.5.3. <provide-anonymity> 4.6.5.3. <provide-anonymity>
The <provide-anonymity> element specifies what level of anonymity the The <provide-anonymity> element specifies what level of anonymity the
server should provide to the user. In this case, the focus provides server should provide to the user. In this case, the focus provides
to the rest of the participants an anonymous identity for that user, to the rest of the participants an anonymous identity for that user,
for example anonymousX, or it does not provide any information for for example anonymousX, or it does not provide any information for
that user such that other users can not see he is a participant in that user such that other users can not see he is a participant in
the conference. This element only affects the way the user the conference. This element only affects the way the user
information is provided to the other participants. The real information is provided to the other participants. The real user
information about the user is still stored in the data model. This information is stored in the data model but SHOULD NOT be provided to
can be achieved by using the <provide-anonymity> element. This the other participants of the conference. This can be achieved by
element has three values: 'private', 'semi-private' and 'hidden'. using the <provide-anonymity> element. This element has three
The 'private' value specifies that this user is completely anonymous values: 'private', 'semi-private' and 'hidden'. The 'private' value
in the conference. 'semi-private' value specifies that this user is specifies that this user is completely anonymous in the conference.
anonymous to all users with equal or lesser permissions (determined 'semi-private' value specifies that this user is anonymous to all
by local policy) in the conference. 'hidden' value specifies that users who have not been granted permission to see him. 'hidden' value
other users can not see this participant in the conference. specifies that other users can not see 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 or more of a participant can perform. This element can contain one or more of
the following values: "administrator", "moderator", "user", the following values: "administrator", "moderator", "user",
"participant", "observer", and "none". The roles semantic definition "participant", "observer", and "none". A role of "none" indicates
is out of the scope of this document and is subject to future policy that any role is assigned; The roles semantic definition is out of
documents. This element can be extended with new roles in future the scope of this document and is subject to future policy documents.
documents. This element can be extended with new roles in future 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.
4.6.5.6. <cascaded-focus> 4.6.5.6. <cascaded-focus>
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.
skipping to change at page 31, line 23 skipping to change at page 32, line 22
notifications mechanism. notifications mechanism.
5. RELAX NG Schema 5. RELAX NG Schema
In accordance with the Centralized Conferencing Framework document In accordance with the Centralized Conferencing Framework document
[RFC5239], the Conference Object is a logical representation of a [RFC5239], the Conference Object is a logical representation of a
conference instance. The conference information schema contains core conference instance. The conference information schema contains core
information that is utilized in any conference. It also contains the information that is utilized in any conference. It also contains the
variable information part of the Conference Object. variable information part of the Conference Object.
The normative schema is backwards compatible with the [RFC5239], in The normative schema is backwards compatible with [RFC5239], in other
other words, valid [RFC5239] instance documents are also valid words, valid [RFC5239] instance documents are also valid according to
according to this RELAX NG schema [RELAX]. In addition to this RELAX NG schema [RELAX]. In addition to approximately similar
approximately similar RELAX NG [RELAX] definitions of the [RFC5239], RELAX NG [RELAX] definitions of [RFC5239], this schema contains
this schema contains extension elements in the extension elements in the
"urn:ietf:params:xml:ns:xcon-conference-info" namespace. "urn:ietf:params:xml:ns:xcon-conference-info" namespace.
default namespace = "urn:ietf:params:xml:ns:conference-info" default namespace = "urn:ietf:params:xml:ns:conference-info"
namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info" namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info"
start = element conference-info { conference-type } start = element conference-info { conference-type }
# CONFERENCE TYPE # CONFERENCE TYPE
conference-type = conference-type =
attribute entity { text } attribute entity { text }
& anyAttribute & anyAttribute
skipping to change at page 51, line 47 skipping to change at page 52, line 47
</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. lines whose content would exceed 72 characters.
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 discusses them. Overall, the The security considerations for section discusses them. Overall, the security considerations for
authentication (Section 11) described in the centralized conferencing authentication (Section 11) and the Security and Privacy of Identity
framework [RFC5239] applies to this document. (Section 11.2) described in the centralized conferencing framework
[RFC5239] applies to this document.
This specification defines a data model for conference objects. This specification defines a data model for conference objects.
Different conferencing systems may use different protocols to provide Different conferencing systems may use different protocols to provide
access to these conference objects. This section contains general access to these conference objects. This section contains general
security considerations for the conference objects and for the security considerations for the conference objects and for the
protocols. The specification of each particular protocol needs to protocols. The specification of each particular protocol needs to
discuss how the specific protocol meets the security requirements discuss how the specific protocol meets the security requirements
provided in this section. provided in this section.
A given conferencing system usually supports different protocols in A given conferencing system usually supports different protocols in
order to implement different functions (e.g., SIP for session control order to implement different functions (e.g., SIP for session control
and BFCP for floor control). Each of these protocols may use their and BFCP for floor control). Each of these protocols may use their
skipping to change at page 52, line 30 skipping to change at page 53, line 31
Futhermore, users may use different namespaces to access to a Futhermore, users may use different namespaces to access to a
conference as explained in Section 4.6.5. These different namespaces conference as explained in Section 4.6.5. These different namespaces
can be associated with a unique conference user identifier (XCON- can be associated with a unique conference user identifier (XCON-
USERID). A mapping database is used to map all these authenticated USERID). A mapping database is used to map all these authenticated
user namespaces to the XCON-USERID. There are several threats user namespaces to the XCON-USERID. There are several threats
against this database. In order to minimize these threats, the against this database. In order to minimize these threats, the
administrator of the conferencing system MUST ensure that only administrator of the conferencing system MUST ensure that only
authorized users can connect to this database (e.g., by using access authorized users can connect to this database (e.g., by using access
control rules). In particular, the integrity of the database MUST be control rules). In particular, the integrity of the database MUST be
protected against unauthorized modifications. protected against unauthorized modifications. Generic security
considerations for usage of URIs are discussed in [RFC3986]. There
is no other encoding considerations for XCON-USERID or XCON-URI not
discussed in RFC 3986 [RFC3986].
The confidentiality of the database SHOULD be protected from The confidentiality of the database SHOULD be protected from
unauthorized users, given that the data model contains a set of unauthorized users, given that the data model contains a set of
sensitive elements (e.g., passwords). Therefore, in addition to sensitive elements (e.g., passwords). Therefore, in addition to
implementing access control, as discussed above, it is RECOMMENDED implementing access control, as discussed above, it is RECOMMENDED
that administrators of conferencing systems only provide access to that administrators of conferencing systems only provide access to
the database over encrypted channels (e.g., using TLS encryption) in the database over encrypted channels (e.g., using TLS encryption) in
order to avoid eavesdroppers. Administrators of conferencing systems order to avoid eavesdroppers. Administrators of conferencing systems
SHOULD also avoid disclosing information to unauthorized parties when SHOULD also avoid disclosing information to unauthorized parties when
a conference is being cloned or when a sidebar is being created. a conference is being cloned or when a sidebar is being created. For
example, an external sidebar as defined in [RFC5239], section 9.4.2,
may include participants who were not authorized for the parent
conference.
The security considerations for authentication (Section 11.1) The security considerations for authentication (Section 11.1)
described in the centralized conferencing framework [RFC5239] also described in the centralized conferencing framework [RFC5239] also
apply to this document. Similarly, the security considerations for apply to this document. Similarly, the security considerations for
authorization (Section 5.2) described in the Session Initiation authorization (Section 5.2) described in the Session Initiation
Protocol (SIP) REFER Method [RFC3515] apply to this document as well. Protocol (SIP) REFER Method [RFC3515] apply to this document as well.
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:schema: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
default namespace = "urn:ietf:params:xml:ns:conference-info" default namespace = "urn:ietf:params:xml:ns:conference-info"
skipping to change at page 54, line 37 skipping to change at page 55, line 37
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="[URL of published RFC]">RFCXXXX
[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 registry. under the Permanent URI Schemes registry.
XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] [RFC xxxx]
conf-object-id = 1*( unreserved / "+" / "=" / "/" ) XCON-URI = "xcon" ":" [conf-object-id "@"] host
host, port, and unreserved are defined in RFC3986[RFC3986] conf-object-id = 1*( unreserved / "+" / "=" / "/" )
[Note to the RFC Editor: replace xxxx with the number this RFC gets host and unreserved are defined in [RFC3986]
assigned.] URI scheme name: xcon
Subject: Request for XCON-URI Registration Status: permanent
Person & email address to contact for further information: URI scheme syntax: see Section 3.3.1.
Oscar Novo <oscar novo_at_ericsson.com> URI schema semantics: see Section 3.3
Specification: RFC XXXX Encoding considerations: see Section 8
Author/Change Controller: IESG Intended usage: see Section 3.3
Comments: Applications and/or protocols that use this URI scheme name:
Identifies the Conference Centralized Conferencing systems
Interoperability considerations: none
Security considerations: see Section 8
Relevant publications: Conference Information Data Model for
Centralized Conferencing (XCON)
Contact: Oscar Novo<oscar novo_at_ericsson.com>
Author/Change controller: Oscar Novo<oscar novo_at_ericsson.com>
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 registry. under the Permanent URI Schemes registry.
XCON-USERID = "xcon-userid" ":" conf-user-id [ RFC xxxx ] XCON-USERID = "xcon-userid" ":" conf-user-id
conf-user-id = 1*(unreserved)
unreserved is defined in RFC3986[RFC3986] conf-user-id = 1*unreserved
[Note to the RFC Editor: replace xxxx with the number this RFC gets unreserved is defined in [RFC3986]
assigned.]
Subject: Request for XCON-USERID Registration URI scheme name: xcon-userid
Person & email address to contact for further information: Status: permanent
Oscar Novo <oscar novo_at_ericsson.com> URI scheme syntax: see Section 4.6.5
Specification: RFC XXXX URI schema semantics: see Section 4.6.5
Author/Change Controller: IESG Encoding considerations: see Section 8
Comments: Intended usage: see Section 4.6.3 and 4.6.5
Identifies the User in the conference Applications and/or protocols that use this URI scheme name:
Centralized Conferencing systems.
Interoperability considerations: none
Security considerations: see Section 8
Relevant publications: Conference Information Data Model for
Centralized Conferencing (XCON)
Contact: Oscar Novo<oscar novo_at_ericsson.com>
Author/Change controller: Oscar Novo<oscar novo_at_ericsson.com>
10. Acknowledgements 10. Acknowledgements
This document is really a distillation of many ideas discussed over a This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different long period of time. These ideas were contributed by many different
drafts in the XCON working group and the SIPPING working group. We drafts in the XCON working group and the SIPPING working group. We
would like to thank Orit Levin, Roni Even, Adam Roach, Mary Barnes, would like to thank Orit Levin, Roni Even, Adam Roach, Mary Barnes,
Chris Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen, Chris Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen,
Aki Niemi, Rohan Mahy, Jonathan Lennox, Sean Duddy, Richard Barnes, Aki Niemi, Rohan Mahy, Jonathan Lennox, Sean Duddy, Richard Barnes,
and Henning Schulzrinne for their comments. Also, we would like to and Henning Schulzrinne for their comments. Also, we would like to
skipping to change at page 56, line 15 skipping to change at page 57, line 28
Romano, Lorenzo Miniero, Tobia Castaldi, Miguel Garcia, Mary Barnes, Romano, Lorenzo Miniero, Tobia Castaldi, Miguel Garcia, Mary Barnes,
Srivatsa Srinivasan, Avshalom Houri, Pierre Tane, and Ben Campbell. Srivatsa Srinivasan, Avshalom Houri, Pierre Tane, and Ben Campbell.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006. State", RFC 4575, August 2006.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006. Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
for Binary Floor Control Protocol (BFCP) Streams", for Binary Floor Control Protocol (BFCP) Streams",
RFC 4583, November 2006. RFC 4583, November 2006.
skipping to change at page 57, line 8 skipping to change at page 58, line 27
[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 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
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., Bray, T., Paoli, J., and E. Maler, Sperberg-McQueen, C., Maler, E., Paoli, J., and T. Bray,
"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"
 End of changes. 44 change blocks. 
133 lines changed or deleted 156 lines changed or added

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