RFC 6501
Conference Information Data Model for Centralized Conferencing (XCON)
Pages: 94
Proposed Standard
Proposed Standard
Part 3 of 4 – Pages 39 to 55
6. XML Schema Extensibility
The conference information data model defined in this document is meant to be extensible. Extensions are accomplished by defining elements or attributes qualified by namespaces other than "urn:ietf:params:xml:ns:conference-info" and "urn:ietf:params:xml:ns:xcon-conference-info" for use wherever the schema allows such extensions (i.e., where the RELAX NG definition specifies "anyAttribute" or "anyElement"). Elements or attributes from unknown namespaces MUST be ignored.7. XML Example
The following is an example of a conference information document. The conference starts on October 17, 2007, at 10:30 a.m. in New York City and finishes the same day at 12:30 p.m. every week and repeats every week. In this example, there are currently three participants in the conference: one administrator, one moderator, and one participant. Sidebars are allowed in this conference and,
consequently, there is one sidebar in the conference. In addition,
Alice and Carol are using a floor in the main conference to manage
the audio and video resources. At the moment, Alice is assigned to
use the floor.
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="conference123@example.com">
<!--
CONFERENCE DESCRIPTION
-->
<conference-description xml:lang="en-us">
<display-text>Discussion of Formula-1 racing</display-text>
<subject>Sports:Formula-1</subject>
<free-text>This is a conference example</free-text>
<keywords>Formula-1 cars</keywords>
<!--
CONFERENCE UNIQUE IDENTIFIERS
-->
<conf-uris>
<entry>
<uri>tel:+3585671234</uri>
<display-text>Conference Bridge</display-text>
<purpose>participation</purpose>
<xcon:conference-password
>5678</xcon:conference-password>
</entry>
<entry>
<uri>http://www.example.com/live.ram</uri>
<purpose>streaming</purpose>
</entry>
</conf-uris>
<!--
SERVICE URIS
-->
<service-uris>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</service-uris>
<!--
MAXIMUM USER COUNT
-->
<maximum-user-count>50</maximum-user-count>
<!--
AVAILABLE MEDIA
-->
<available-media>
<entry label="10234">
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
<xcon:mixing-mode>automatic</xcon:mixing-mode>
<xcon:codecs decision="automatic">
<xcon:codec name="122" policy="allowed">
<xcon:subtype>PCMU</xcon:subtype>
</xcon:codec>
</xcon:codecs>
<xcon:controls>
<xcon:mute>true</xcon:mute>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</entry>
<entry label="10235">
<display-text>main video</display-text>
<type>video</type>
<status>sendrecv</status>
<xcon:mixing-mode>automatic</xcon:mixing-mode>
<xcon:codecs decision="automatic">
<xcon:codec name="123" policy="allowed">
<xcon:subtype>H.263</xcon:subtype>
</xcon:codec>
</xcon:codecs>
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</entry>
</available-media>
<xcon:language>En-us</xcon:language>
<xcon:allow-sidebars>true</xcon:allow-sidebars>
<!--
CONFERENCE TIME
-->
<xcon:conference-time>
<xcon:entry>
<xcon:base>BEGIN:VCALENDAR
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20071003T140728Z
UID:20071003T140728Z-345FDA-carol@example.com
ORGANIZER:MAILTO:carol@example.com
DTSTART:20071017T143000Z
RRULE:FREQ=WEEKLY
DTEND:20071217T163000Z
END:VEVENT
END:VCALENDAR</xcon:base>
<xcon:mixing-start-offset
required-participant="moderator"
>2007-10-17T14:29:00Z</xcon:mixing-start-offset>
<xcon:mixing-end-offset
required-participant="participant"
>2007-10-17T16:31:00Z</xcon:mixing-end-offset>
<xcon:must-join-before-offset
>2007-10-17T15:30:00Z
</xcon:must-join-before-offset>
</xcon:entry>
</xcon:conference-time>
</conference-description>
<!--
HOST INFO
-->
<host-info>
<display-text>Formula1</display-text>
<web-page>http://www.example.com/formula1/</web-page>
<uris>
<entry>
<uri>sip:alice@example.com</uri>
</entry>
<entry>
<uri>sip:carol@example.com</uri>
</entry>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>3</user-count>
<active>true</active>
<locked>false</locked>
<xcon:allow-conference-event-subscription
>true</xcon:allow-conference-event-subscription>
</conference-state>
<!--
USERS
-->
<users>
<!--
USER BOB
-->
<user entity="xcon-userid:bob534">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>participant</entry>
</roles>
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@example.com">
<display-text>Bob's Laptop</display-text>
<referred>
<when>2007-10-17T14:00:00Z</when>
<reason>expert required</reason>
<by>sip:alice@example.com</by>
</referred>
<status>connected</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2007-10-17T14:00:00Z</when>
<reason>invitation</reason>
<by>sip:alice@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
<xcon:provide-anonymity
>semi-private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>false</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>false</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>false</xcon:allow-remove-users-dynamically>
</user>
<!--
USER ALICE
-->
<user entity="xcon-userid:alice334">
<display-text>Alice Kay</display-text>
<associated-aors>
<entry>
<uri>mailto:alice@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>moderator</entry>
</roles>
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:alice@example.com">
<display-text>Alice's Desktop</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2007-10-17T13:35:08Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<media id="2">
<type>audio</type>
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="AudioIn">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:to-mixer>
<xcon:from-mixer name="AudioOut">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:from-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>truy45469123478</call-id>
<from-tag>asd456cbgt</from-tag>
<to-tag>3456jgjg1234</to-tag>
</sip>
</call-info>
<xcon:floor id="345">true</xcon:floor>
</endpoint>
<xcon:provide-anonymity>private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>true</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>true</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>true</xcon:allow-remove-users-dynamically>
</user>
<!--
USER CAROL
-->
<user entity="xcon-userid:carol233">
<display-text>Carol More</display-text>
<associated-aors>
<entry>
<uri>mailto:carol@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>administrator</entry>
</roles>
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:carol@example.com">
<display-text>Carol's Computer</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2007-10-17T13:30:05Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<media id="2">
<type>audio</type>
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="AudioIn">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:to-mixer>
<xcon:from-mixer name="AudioOut">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:from-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>wevb12562321894</call-id>
<from-tag>asw456wedf</from-tag>
<to-tag>2365dfrt3497</to-tag>
</sip>
</call-info>
<xcon:floor id="345">false</xcon:floor>
</endpoint>
<xcon:provide-anonymity>private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>true</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>true</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>true</xcon:allow-remove-users-dynamically>
</user>
<xcon:join-handling>allow</xcon:join-handling>
<xcon:user-admission-policy
>openAuthenticated</xcon:user-admission-policy>
<!--
ALLOWED USERS LIST
-->
<xcon:allowed-users-list>
<xcon:target uri="sip:bob@example.com"
method="dial-out"/>
<xcon:target uri="sip:alice@example.com"
method="dial-out"/>
<xcon:target uri="sip:carol@example.com"
method="dial-out"/>
<xcon:target uri="sip:john@example.com"
method="refer"/>
</xcon:allowed-users-list>
<!--
DENY USERS LIST
-->
<xcon:deny-users-list>
<xcon:target uri="sip:charlie@example.com"/>
</xcon:deny-users-list>
</users>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref>
<entry>
<uri>xcon:conf223</uri>
<display-text>private with Bob</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val>
<entry entity="conf223">
<users>
<user entity="xcon-userid:bob534"/>
<user entity="xcon-userid:carol233"/>
</users>
</entry>
</sidebars-by-val>
<!--
FLOOR INFORMATION
-->
<xcon:floor-information>
<xcon:conference-ID>567</xcon:conference-ID>
<xcon:allow-floor-events>true</xcon:allow-floor-events>
<xcon:floor-request-handling
>confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="345">
<xcon:media-label>10234</xcon:media-label>
<xcon:media-label>10235</xcon:media-label>
<xcon:algorithm
>moderator-controlled</xcon:algorithm>
<xcon:max-floor-users>1</xcon:max-floor-users>
<xcon:moderator-id>234</xcon:moderator-id>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</conference-info>
Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters.
8. Security Considerations
There are numerous security considerations for this document.
Overall, the security considerations for authentication and the
Security and Privacy of Identity described in Sections 11 and 11.2,
respectively, of the centralized conferencing framework document
[RFC5239] apply to this document.
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.
A given conferencing system usually supports different protocols in
order to implement different functions (e.g., SIP for session control
and BFCP for floor control). Each of these protocols may use its own
authentication mechanism. In cases where a user is authenticated
using multiple authentication mechanisms, it is up to the
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.
Furthermore, users may use different identifiers to access a conference, as explained in Section 4.6.5. These different namespaces can be associated with a unique conference user identifier (XCON-USERID). A mapping database is used to map all these authenticated user namespaces to the XCON-USERID. There are several threats against this database. In order to minimize these threats, the administrator of the conferencing system MUST ensure that only authorized users can connect to this database (e.g., by using access control rules). In particular, the integrity of the database MUST be protected against unauthorized modifications. In addition, the XCON- USERID or XCON-URI SHOULD be hard to guess. It is critical that the URI remain difficult to "guess" via brute force methods. Generic security considerations for usage of URIs are discussed in [RFC3986]. It is RECOMMENDED that the database uses encryption mechanisms if the information is stored in long-term storage (e.g., disk). If the database contains sensitive elements (e.g., passwords), the confidentiality of the database MUST be protected from unauthorized users. If no sensitive elements are present, then confidentiality is not needed. 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. 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 described in Section 11.1 of the centralized conferencing framework document [RFC5239] also apply to this document. Similarly, the security considerations for authorization described in Section 5.2 of the Session Initiation Protocol (SIP) REFER Method [RFC3515] apply to this document as well. Note that the specification of the privacy policy is outside the scope of this document. Saying that, a privacy policy will be needed in the real implementation of the data model and, therefore, is subject to future policy documents.
9. IANA Considerations
9.1. RELAX NG Schema Registration
This specification registers a schema. The schema can be found as the sole content of Section 5. URI: urn:ietf:params:xml:schema:xcon-conference-info Registrant Contact: IETF XCON working group <xcon@ietf.org>, Oscar Novo <Oscar.Novo@ericsson.com> RELAX NG Schema: The RELAX NG schema to be registered is contained in Section 5. Its first line is as follows: default namespace = "urn:ietf:params:xml:ns:conference-info" and its last line is as follows: anyAttribute = attribute * - (xml:lang | entity | required-participant | label | decision | name | policy | uri | method | id | nickname) { text }*
9.2. XML Namespace Registration
This section registers a new XML namespace. URI: urn:ietf:params:xml:ns:xcon-conference-info Registrant Contact: IETF XCON working group <xcon@ietf.org>, Oscar Novo <Oscar.Novo@ericsson.com> XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title> Centralized Conferencing Namespace</title> </head> <body> <h1>Namespace for Centralized Conferencing</h1> <h2>urn:ietf:params:xml:ns:xcon-conference-info</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc6501.txt"> RFC 6501</a>.</p> </body> </html> END9.3. Conference Object Identifier Registration
URI scheme name: xcon Status: permanent URI scheme syntax: see Section 3.3.1. URI schema semantics: see Section 3.3 Encoding considerations: see Section 8 Intended usage: see Section 3.3 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@ericsson.com> Author/Change controller: Oscar Novo <oscar.novo@ericsson.com>
9.4. Conference User Identifier Registration
URI scheme name: XCON-USERID Status: permanent URI scheme syntax: see Section 4.6.5 URI schema semantics: see Section 4.6.5 Encoding considerations: see Section 8 Intended usage: see Section 4.6.3 and 4.6.5 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@ericsson.com> Author/Change controller: Oscar Novo <oscar.novo@ericsson.com>10. Acknowledgements
This document is really a distillation of many ideas discussed over a long period of time. These ideas were contributed by many different documents in the XCON working group and the SIPPING working group. We would like to thank Orit Levin, Roni Even, Adam Roach, Mary Barnes, Chris Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen, Aki Niemi, Rohan Mahy, Jonathan Lennox, Sean Duddy, Richard Barnes, and Henning Schulzrinne for their comments. Also, we would like to thank Mary Barnes and Chris Boulton for letting us use the conference and user identifier information of their XCON documents. Last but not least, we would like to express our gratitude to all those reviewers for their invaluable contributions: Simon Pietro Romano, Lorenzo Miniero, Tobia Castaldi, Miguel Garcia, Mary Barnes, Srivatsa Srinivasan, Avshalom Houri, Pierre Tane, and Ben Campbell.11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 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 Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.11.2. Informative References
[IANA] IANA, "RTP Payload Types", <http://www.iana.org/assignments/rtp-parameters>. [IANA-Lan] IANA, "Language Subtag Registry", <http://www.iana.org/assignments/ language-subtag-registry>. [RELAX] "RELAX NG Home Page", ISO/IEC 19757-2:2008. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC5018] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, September 2007. [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
(next page on part 4)