Internet DRAFT - draft-morgan-xcon-roles
draft-morgan-xcon-roles
XCON D. Morgan
Internet-Draft Fidelity Investments
Expires: April 20, 2006 O. Novo
Ericsson
October 17, 2005
Role Definitions for Centralized Conferencing
draft-morgan-xcon-roles-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines the set of possible conferencing roles that are
used to represent participants withing a Conference Object (as
defined in the XCON Conference Framework [1]). The document also
provides a set of semantics associated with each role. Additional
roles may be defined in the future, as necessary, with their
corresponding schema extensions, as appropriate.
Morgan & Novo Expires April 20, 2006 [Page 1]
Internet-Draft Roles in XCON October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Roles . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Roles in the Conference Template . . . . . . . . . . . . . 4
3.2. Roles in the Common Conference Data Model . . . . . . . . 4
4. Role Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Administrator . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Creator . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Moderator . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Participant . . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Observer . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Roles in a Floor . . . . . . . . . . . . . . . . . . . . . . . 6
6. Changing Roles . . . . . . . . . . . . . . . . . . . . . . . . 7
7. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 7
8. Extensibility of the Schema . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Morgan & Novo Expires April 20, 2006 [Page 2]
Internet-Draft Roles in XCON October 2005
1. Introduction
This document defines the set of possible conferencing roles that are
used to represent participants withing a Conference Object (as
defined in the XCON Conference Framework [1]). The document also
provides a set of semantics associated with each role. Additional
roles may be defined in the future, as necessary, with their
corresponding schema extensions, as appropriate.
A Conference Media template [6] specifies which roles are available
in a Conference Object, including the maximum number of occurrence
permitted for each role. A media template also defines properties
such as default values for each role, the conference controls
available to each role and how they may be manipulated, and which
media streams (with associated properties) are associated with each
role.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Overview of Roles
This document defines five logical roles that a Conference System
should assume are available in a Conference Object. In hierarchical
order they are: "administrator", "creator", "moderator",
"participant", and "observer". These five roles are sufficient to
delineate the various privileges that conference attendees need in a
variety of conference scenarios [3]. The specific media capabilities
of each role are defined in the conference template [6]. It should
be noted that all five roles need not be specified or present in the
conference template but SHOULD be supported by the Conference System.
A Conference System MAY choose not to support a particular role if it
can unequivocally decide that the role will not be required in any of
the templates supported.
These five roles have an intrinsic hierarchical order within a
specific conference. By hierarchical order, it is implied that the
"administrator" by default should have higher privileges than a
"creator", which by default should have higher privileges than a
"moderator" and so on. For example, the "administrator" should have
the ability to make changes to all conference variables during
instantiation and full lifecycle of the Conference Object. The
"creator" is the 'owner' of the conference and has various privileges
Morgan & Novo Expires April 20, 2006 [Page 3]
Internet-Draft Roles in XCON October 2005
which should allow them to modify the conference variables up to the
time the conference is instantiated. The "moderator" is a logical
entity that will manage the conference. The "participant" is a
logical entity with generic privileges that will be attending a
conference. The "observer" is a logical entity which can only
receive media streams from the conference. All conference templates
must have a role defined as "participant".
Each user participating in a conference instace is an entity that can
assume one or more roles. Any entity can be allocated to an
appropiated logical role. A role can also be assumed in conjunction
with the users identity within the Conference System as a result of
an identity assertion transaction on the Conference System. If no
roles are defined for an entity, they should by default be a
"participant" but local policy may define an alternative.
3.1. Roles in the Conference Template
When the <role> element is defined in the "Media Policy Template for
XCON" [6], it will have a set of child elements that will specify the
media capabilities available to a logical entity in that role. These
capabilities are collectively referred to as "privileges" and consist
of a number of controls and parameters. For example, the conference
"moderator" may have privileges that allow them to either mute or
remove a "participant".
The <role> element MUST have an attribute called 'name'. The 'name'
MUST be one of the conference roles defined in this specification or
an appropriate extension, specifically it has to be of type
"administrator", "creator", "moderator", "participant", or
"observer".
The <role> element MAY have <parameter>, <control> and <stream> child
elements (among others) specified in the conference template [6].
The <stream> element defines the media streams available in that
role. The <role> can have one or more media streams available. Each
<stream> element MAY contain a child element called the <floor> that
specifies a conference floor which can be controlled by a floor chair
in the conference [7]. The role can have one or more active floors.
Typically the "moderator" role contains a definition of the active
floors.
3.2. Roles in the Common Conference Data Model
The <roles> element in the "Common Conference Information Data Model
for Centralized Conferencing" [8] is a child element of the <user>
element. It specifies the roles of a user and it MAY contain a child
element called the <description> that is a set of human readable
Morgan & Novo Expires April 20, 2006 [Page 4]
Internet-Draft Roles in XCON October 2005
strings that describes that role in the conference. For example, it
may contain information regarding the conference administrator and
the best way to communicate with them or it may contain instructions
such as conference recording (the addition of an observer) can only
be enabled by contacting the administrator and requesting that a
service-uri be added to the conference.
4. Role Definitions
This section defines the different types of roles in a conference
system.
4.1. Administrator
The administrator role is typically the system administrator of the
Conference System. By default, someone in this role SHOULD have the
ability to read or modify all conference elements. All conferences
SHOULD specify an "administrator".
4.2. Creator
The role of "creator" is used to identify the logical entity that
created the conference. The conference creator is the 'owner' of the
conference and has various privileges which SHOULD allow them to
modify the conference variables up to the time the conference is
instantiated.
In the case of an ad-hoc conference, also known as a reservationless
or on-demand conference, there may be no conference creator, or the
conference creator may be specified as the conference focus.
The conference creator does not necessarily have to attend the
meeting. They could be a secretary that sets up the meeting.
When the conference creator attends the meeting, the hierarchical
nature of the role types will allow the "creator" to have all the
privileges of the "moderator".
4.3. Moderator
The role of "moderator" is used to identify the logical entity that
will manage the conference. The "moderator" is in essence the
'facilitator' of the conference.
The "moderator" is an OPTIONAL role, but if specified in the
conference template, the "moderator" SHOULD attend the meeting.
Morgan & Novo Expires April 20, 2006 [Page 5]
Internet-Draft Roles in XCON October 2005
There may be multiple moderators in a conference. For example, a
conference may have two moderators: one controlling who can talk at a
particular time and another controlling who can write on a shared
whiteboard.
4.4. Participant
The role of "participant" is used to identify a logical entity with
generic privileges that will be participating in a Conference
Instance. The "participant" is in essence an 'attendee' to the
conference.
The "participant" is a mandatory role, and MUST be defined in the
conference template. There SHOULD be basic levels of media streams
and their associated stream-types defined for the role of
"participant".
There MAY be multiple participants in a conference.
4.5. Observer
The role of "observer" is used to identify a logical entity which can
only receive media streams from the conference. The "observer" is in
essence a 'listener' to the conference. An observer could be a
person (supervisor) or a machine (call logger or recording device).
The "observer" is an OPTIONAL role, but there may be multiple
observers in a conference. The "observer" only receives input media
streams and MUST NOT generate output streams.
5. Roles in a Floor
Floor control in centralized conferencing is introduced in the XCON
Framework Document [1] and described in further detail in the Binary
Floor Control Protocol (BFCP) [7]. Floors can be specified in the
conference template [6] or created dynamically. Users can be added
or deleted from a floor when the conference is active.
A floor chair is a logical entity that manages a floor (grants,
denies, or revokes a floor). The floor chair is usually in an
"administrator", "moderator", or "creator" role. A floor participant
is a logical entity that requests floors, and possibly information
about them from a floor control server. They are usually in a
"participant" or even a "moderator" role [7].
In the conference scenarios [3], the 'lecturer' is seen/heard by the
conference participants and often shares a presentation or
Morgan & Novo Expires April 20, 2006 [Page 6]
Internet-Draft Roles in XCON October 2005
application with the other participants. A 'lecturer' is a logical
entity that has been granted the floor within a conference by the
floor chair. It can be the "administrator", "moderator",
"participant", or "moderator" role in the conference. The 'lecturer'
MAY also be referred to as a 'presenter'.
Users in a conference MAY assume different roles in different floors.
They MAY also assume different roles in the same floor, as floor
transactions are processed.
6. Changing Roles
As mentioned previously, users can change roles during a conference.
This can be done in one of two ways. First, the user can join a new
floor in a different role. Second, an "administrator" can
dinamically change that user's role. This can be accomplished before
the conference is instantiated, or during the conference, using an
appropriate conference control protocol [9], [10]. A logical entity
whose role has been changed will typically have access to the media
streams associated with that role.
It should be noted that when a logical entity is granted the floor in
an active conference, their role does not change. A user's role also
does not change when they are either granted conference controls, or
conference controls are enabled by the "administrator" or "moderator"
while the conference is active.
7. XML Schema Definition
This section provides the XML schema definition for type 'role-type'.
This schema will be called role-schema.xsd.
<xs:schema targetNamespace="urn:ietf:params:xml:ns:role-schema";
xmlns=" urn:ietf:params:xml:ns:role-schema";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:simpleType name="role-type">
<xs:restriction base="xs:string">
<xs:enumeration value="Administrator"/>
<xs:enumeration value="Creator"/>
<xs:enumeration value="Moderator"/>
<xs:enumeration value="Participant"/>
<xs:enumeration value="Observer"/>
</xs:restriction>
</xs:simpleType>
Morgan & Novo Expires April 20, 2006 [Page 7]
Internet-Draft Roles in XCON October 2005
</xs:schema>
8. Extensibility of the Schema
As defined in the XML schema definition above, the 'role-type' MUST
have five values. Future extensions to this schema may define new
values and register them with IANA. A hypothetical example for a
schema extension for a new role-type value of "sub-administrator" is
shown below:
<xs:schema targetNamespace="...";
xmlns="...";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:redefine schemaLocation="role-schema.xsd">
<xs:simpleType name="role-type">
<xs:restriction base="xs:string">
<xs:enumeration value="sub-administrator"/>
</xs:restriction>
</xs:simpleType>
</xs:redefine>
</xs:schema>
9. Security Considerations
A good discussion of appropriate security considerations between
clients and the conferencing server can be found in [7].
10. IANA Considerations
This document registers a new XML schema as per the guidelines in RFC
3688[4].
URI: urn:ietf:params:xml:ns:role-schema
Registrant Contact: IETF XCON Working Group <xcon@ietf.org>, as
designated by the IESG <iesg@ietf.org> XML: The XML can be found in
the contents of Section 7
This section registers a new XML namespace, as per the guidelines in
RFC 3688[4].
Morgan & Novo Expires April 20, 2006 [Page 8]
Internet-Draft Roles in XCON October 2005
URI: The URI for this namespace is urn:ietf:params:xml:ns:role-schema
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>, as
designated by the IESG <iesg@ietf.org>
11. Acknowledgements
The authors would like to thank Gonzalo Camarillo, Orit Levin, Umesh
Chandra, and Chris Boulton for their comments and input.
12. References
12.1. Normative References
[1] Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencing", draft-barnes-xcon-framework-02 (work
in progress), February 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Even, R. and N. Ismail, "Conferencing Scenarios",
draft-ietf-xcon-conference-scenarios-05 (work in progress),
September 2005.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[5] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress),
June 2003.
12.2. Informative References
[6] Boulton, C. and U. Chandra, "Media Policy Templates for XCON",
draft-boulton-xcon-media-template-01 (work in progress),
April 2005.
[7] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-camarillo-xcon-bfcp-00 (work in progress), May 2004.
[8] Novo, O., "A Common Conference Information Data Model for
Centralized Conferencing (XCON)",
draft-novo-xcon-common-data-model-00 (work in progress),
September 2005.
Morgan & Novo Expires April 20, 2006 [Page 9]
Internet-Draft Roles in XCON October 2005
[9] Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
draft-ietf-xcon-cpcp-01 (work in progress), October 2004.
[10] Levin, O., "Conference Policy Control Protocol for Centralized
Conferencing", draft-levin-xcon-cpcp-00 (work in progress),
June 2003.
Morgan & Novo Expires April 20, 2006 [Page 10]
Internet-Draft Roles in XCON October 2005
Authors' Addresses
David P. Morgan
Fidelity Investments
82 Devonshire St, MZ V8C
Boston, MA 02109-3614
USA
Email: Dave.Morgan@fmr.com
Oscar Novo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Oscar.Novo@ericsson.com
Morgan & Novo Expires April 20, 2006 [Page 11]
Internet-Draft Roles in XCON October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Morgan & Novo Expires April 20, 2006 [Page 12]
