Internet DRAFT - draft-groves-clue-role-clarifications
draft-groves-clue-role-clarifications
CLUE C. Groves, Ed.
Internet-Draft W. Yang
Intended status: Informational R. Even
Expires: January 10, 2014 Huawei
July 09, 2013
Use of "Roles" in CLUE
draft-groves-clue-role-clarifications-00
Abstract
There have been recent discussions on the CLUE and DISPATCH mailing
lists about "roles" associated with multimedia conferences. From the
discussions it was apparent that there is some confusion as to what
the current defined roles actually imply and that people had
different understanding of the meaning and scope of the term "role".
This draft seeks to identify the various "roles" that may be
associated with a multimedia conference and to provide a grouping and
nomenclature for further discussions on this topic.
Specific to CLUE this draft proposes a number of attributes to be
able to clearly identify the various roles that may be associated
with a media capture.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 10, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Groves, et al. Expires January 10, 2014 [Page 1]
Internet-Draft Abbreviated Title July 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Role Categories . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Meeting Roles . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Conference System Control Roles . . . . . . . . . . . . . 4
2.3. Institution type . . . . . . . . . . . . . . . . . . . . 4
2.4. Person Name Title . . . . . . . . . . . . . . . . . . . . 5
2.5. Person Occupation (Job Title) . . . . . . . . . . . . . . 6
2.6. Organisation Name . . . . . . . . . . . . . . . . . . . . 7
2.7. Meeting Specific Roles . . . . . . . . . . . . . . . . . 7
2.8. Other Considerations . . . . . . . . . . . . . . . . . . 7
3. Relation to CLUE . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Meeting Roles . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Meeting Specific Roles . . . . . . . . . . . . . . . . . 9
3.3. Conference System Control Roles . . . . . . . . . . . . . 9
3.4. Institution type . . . . . . . . . . . . . . . . . . . . 10
3.5. Personal Information . . . . . . . . . . . . . . . . . . 10
3.5.1. Person Name Title . . . . . . . . . . . . . . . . . . 10
3.5.2. Person Occupation (Job Title) . . . . . . . . . . . . 11
3.5.3. Organisation Name . . . . . . . . . . . . . . . . . . 11
4. Capture scene attributes . . . . . . . . . . . . . . . . . . 13
5. Summary of proposed updates . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The purpose of this document is to collect together different types
of "roles" or attributes of people participating within a multi-media
conference. It is recognised that a person may have multiple roles
in a conference that denote different information regarding their
social and/or organisational status. For example: At a "Internal
Groves, et al. Expires January 10, 2014 [Page 2]
Internet-Draft Abbreviated Title July 2013
organisational level" a person may have the role of "Chief Executive
Officer (CEO)" but from a conference control level may be a
"Participant" who cannot control the conference despite having large
amount of power in a company. The definition of a role may also give
information regarding the type of organisation a person is from. For
example: From "Professor" it could be assumed that the person is from
an educational institution, however this assumption may be false as a
Professor is a title of a person. One's status is an important
aspect in social interactions. Telepresence is designed to increase
the experience of normal social interactions so communication of
status is an important aspect.
From a media perspective a media stream that either depicts a person
or carries their voice could be attributed with the person's role/s.
2. Role Categories
As shown above the term "role" can be associated with a wide range of
characteristics. The sections below attempt to collect roles into
different sub-categories of related roles. When a person talks about
"role" it is important to identify the category of role that is being
talked about as these are likely to have semantic differences.
For example: When using the role "chairman" it could be considered
as:
a) a meeting role - the person who runs the meeting through the
agenda
b) a conference control role - the person who controls the
conference system that allows people to speak
c) the person is the chairman of a company and is participating
in the conference
Each of the above is a different function with potentially the same
label.
2.1. Meeting Roles
These roles relate to typical traditional functions when a meeting is
held. These roles are related to the running of the meeting itself,
i.e. with respect to the agenda. These roles pre-date multimedia
conferencing and are typically needed whenever a meeting is held.
Knowing who has these roles is integral to running a successful
meeting.
Groves, et al. Expires January 10, 2014 [Page 3]
Internet-Draft Abbreviated Title July 2013
1. Chairman ([RFC6501]. moderator?) (Leader - Person who
convenes the meeting) (facilitator - keeps discussion going)
2. Vice-Chairman
3. Secretary/Scribe/Recorder/Minute Taker
4. Member/Participant/Audience
5. Presenter/Lecturer
6. Translator
7. Timekeeper
2.2. Conference System Control Roles
These roles are related to the establishment and maintenance of the
multimedia conference and are related to the scope of conference
system only. It can be beneficial for other people to know who has
these roles. For example: If the controller is responsible for
selecting which people/endpoints can speak it might be beneficial to
observe them for visual CLUEs on how they determine the turn taking
process.
Speaker/Presenter Can share content/media with others.
Controller/Host Indicates the person responsible for controlling
admission to the conference. Sets up the meeting,
adds and shares contents, control who presents and
talks.
Participant Indicates a participant in the conference who does
not have any special control. Receives media and
content from presenter.
2.3. Institution type
This type indicates the type of organisation a person is from. This
could be helpful to scope a person's title.
1. Industry (this could be broken into segments, i.e.
healthcare, telecommunications etc.)
2. Government
3. Non-governmental organisation (NGO)
Groves, et al. Expires January 10, 2014 [Page 4]
Internet-Draft Abbreviated Title July 2013
4. Educational
5. Religious
6. Not for profit
7. Military
8. Private
9. Etc.
2.4. Person Name Title
Common honorific titles relate to a person's gender (Social Title)
i.e. Mr, Mrs, Miss etc. however there are other titles used to show
aristocratic status (Hereditary title) (Honorary title) or one's role
in government, a religious, military or educational institution. For
example: Doctor (Professional Title), Professor (Academic Title) and
Air Marshall (Military title). These are placed into context and
relative authority given by the organisation type.
Wikipedia provides a discussion of the different types of titles:
http://en.wikipedia.org/wiki/Title
It can be seen that there are hundreds of possible titles related to
a person's status.
A further complication is that a title may be repeated i.e. Honorary
Doctor (Hon Dr).
There are some standards that allow for the carriage of titles (these
are discussed below) however there does not appear to be a standard
definition containing all the titles.
Appendix A of Standards Australia AS 4590-2006 "Interchange of client
information" provides a list of some common titles.
[ITU.X520.2001] does contain syntax for Title (the designated
position or function of the object within an organization) and allows
it's usage in Commonname attribute (which vCard uses) however this
does not provide any values.
OASIS have developed standards for naming in the OASIS Identity
Metasystem Interoperability (IMI) Technical Committee: (https://www
.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq).
Groves, et al. Expires January 10, 2014 [Page 5]
Internet-Draft Abbreviated Title July 2013
However they do not define a set of allowed titles. See: Extensible
Name Language (xML) Standard Description Document for W3C DTD/Schema
Beyond the common set of English honorific titles it may be difficult
to implement a policy based on a standard set.
2.5. Person Occupation (Job Title)
Persons can be further classified by their occupation. In some
respects this is a combination of institution type and title. There
is already a standard ISCO-8 "International Standard Classification
of Occupations" that groups jobs into 10 major groups:
1- Managers
2- Professionals
3- Technicians and associate professionals
4- Clerical support workers
5- Service and sales workers
6- Skilled agricultural, forestry and fishery workers
7- Craft and related trades workers
8- Plant and machine operators, and assemblers
9- Elementary occupations
0- Armed forces occupations
These categories are further broken down into to provide more
detailed information regarding the job. For example:
Major Group 1
Managers
11 Chief executives, senior officials and legislators
111 Legislators and senior officials
Groves, et al. Expires January 10, 2014 [Page 6]
Internet-Draft Abbreviated Title July 2013
112 Managing directors and chief executives
It may be advantageous to utilise this specification to indicate the
organisational position of someone. A free text field could provide
extra information if the user determines it is necessary.
2.6. Organisation Name
Rather than providing person information an endpoint could provide
information regarding an organisation name. For example: it may not
matter that media is from a certain person you may want media from a
certain company.
OASIS as mentioned above provides guidelines on organisation name
formats.
vCard [RFC6350] also allows the indication of an organisation name.
2.7. Meeting Specific Roles
Rather than being international and regionally accepted roles, roles
may also be internal to an organisation or group. This group may
define their own roles as integral to the meeting process and it may
be advantageous for other people in the meeting to know these roles.
For example:
Toastmasters (http://www.toastmasters.org/meetingroles.aspx) define
the roles of: Ah-counter, Evaluator, General Evaluater, Grammarian,
Meeting Speaker, Pledge, etc.
So in the scope of a Telepresence conference between toastmasters
participants it should be possible to select captures based on their
agreed set of roles. They could be scoped by organisation. However
for the wider community these roles would largely be meaningless.
Another example would be the Telemedical use case. A capture of "the
patient" would be difficult to express using the normal conference
roles.
2.8. Other Considerations
This draft has only considered this issue from an English language
perspective. Further consideration would be needed on the use of
non-English roles and any potential mapping.
3. Relation to CLUE
Groves, et al. Expires January 10, 2014 [Page 7]
Internet-Draft Abbreviated Title July 2013
[I-D.groves-clue-capture-attr] proposed a number of attributes to
describe media captures. One of those was the "role" attribute. The
intention of the "role" attribute was to allow the consumer to
advertise that a media capture has a person and/or conference role
associated with it. During discussions it was noted that more work
was needed on the allowed values.
As shown above the term "role" relates to a wide range of functions
so the CLUE work on roles should be more specific on what function/s
are supported. If more than one role type is supported it may be
more appropriate to support several attributes, each specific to a
particular function.
An advertiser may populate "role" information either by manual or
automatic provisioning. Manual configuration would be that the
participant enter the information at the time of meeting
establishment. Automatic provisioning is where the conference system
uses previously supplied information to populate the role
information. This could be provided when the system is provisioned
or based on electronic exchange of information. For example the
Popov room at the ITU-T allows the insertion of an identity card at a
seating position which the conference system can use.
The basic premise of CLUE is that the attributes are used by a
consumer to select which of the advertised media captures it wants.
Therefore it is assumed that the "role" type information is only used
in scope of CLUE. For example: the CLUE role information would not
be used by SIP XCON ([RFC6501]) to determine conference policies.
Like the other CLUE attributes the "role" information may also be
used to determine display/playout characteristics by a consumer.
A secondary premise is that by knowing the "role" of the person/media
capture it enhances the social interactions in the conference. What
the relevance of the different "role" functions has to a consumer is
largely a matter of local policy. A person associated with the
consuming endpoint may be more interested in seeing the company CEO
than the person chairing the meeting. This different relevance may
also be based on cultural preferences / norms.
The various "role" categories are discussed below in the context of
relevance to CLUE.
3.1. Meeting Roles
As described in section 2.1 these roles are key to most meetings.
They describe the functions related to the running of the meeting.
They are NOT related to running a conferencing system. These roles
are assigned to people within a meeting. As a media capture may
Groves, et al. Expires January 10, 2014 [Page 8]
Internet-Draft Abbreviated Title July 2013
capture more than one person it means that an attribute describing
meeting roles must allow more than one value per media capture. A
person may also have more than one meeting role, i.e. a secretary and
time keeper. Multiple people within a capture may also have the same
role, i.e. three people in a capture may all be participants. In
such a case a meeting role attribute would only need a single value
"participant".
A media capture may contain people with the following meeting roles:
Chairman A person who convenes the meeting and presides over
discussions. Also known as a moderator or
rapporteur.
Vice-Chairman A person who assist the chairman.
Secretary A person who is responsible for documenting the
meeting. Also known as a scribe, recorder or minute
taker.
Participant A person who is participating in a meeting that has
no other role in a meeting. Also known as a member,
participant or audience.
Presenter A person who has been invited to present a message to
the meeting. Also known as a lecturer.
Translator A person who translates from one language to another
in a meeting.
Timekeeper A person who is responsible who records the time
taken for the meeting.
It is proposed to add a capture attribute "Meeting Role" to CLUE with
the above values.
3.2. Meeting Specific Roles
As discussed in section 2.7 it is possible that certain group may
define their own meeting roles. The ability to carry this
information should be possible in CLUE. To facilitate the carriage
of this information in CLUE it is proposed to add a free text field
to the "Meeting Role" attribute proposed in section 3.1 above.
3.3. Conference System Control Roles
As mentioned in section 2.2 conference system control roles relate to
the control of the electronic conference. For CLUE an attribute with
Groves, et al. Expires January 10, 2014 [Page 9]
Internet-Draft Abbreviated Title July 2013
the Conference Control role would indicate that the person depicted
in the media capture has certain conference control responsibilities.
It does not provide any authorisation in a conference management
system for these conference control roles. The information is
provided as a means for the consumer to select media captures and for
display/playout purposes.
The following conference system control roles are proposed:
Presenter Indicates a person that can share content/media with
others. May also be known as speaker.
Controller Indicates the person responsible for controlling
admission to the conference. Sets up the meeting,
adds and shares contents, control who presents and
talks. Also known as "host".
Participant Indicates a participant in the conference who does
not have any special control. Receives media and
content from presenter.
Unlike meeting role a person can only have one conference system
control role at a time. However as multiple people can be captured
in a media capture the conference system control role may have
multiple values.
It is proposed to add an attribute "Conference System Control Role"
to CLUE with the above attributes.
3.4. Institution type
CLUE media captures are more likely to be selected based on the
person and their position and company rather than the type of
organisation that they are from. This can be omitted from CLUE.
3.5. Personal Information
3.5.1. Person Name Title
As described in section 2.4 above there may be many different
variations of a person name title. There are also non-English
speaking titles that would need to be conveyed. It is unlikely that
all the variations could be enumerated. As discussed above a
person's title gives important information regarding the social
status of that person. It is noted that vCard [RFC6350] section
6.2.2 allows title as part of the "n" attribute. As a means to
provide information regarding the person in a capture it is proposed
to allow vCard [RFC6350] descriptions to be linked with CLUE media
Groves, et al. Expires January 10, 2014 [Page 10]
Internet-Draft Abbreviated Title July 2013
captures. This is a standardised form of providing information
regarding a person's title, name and contact details as well as
additional attributes. This would allow a Consumer to choose
captures based on a rich set of information as well as using this
information for display.
3.5.2. Person Occupation (Job Title)
As has been discussed Consumers may choose to receive a particular
media capture based on the role of a person. For example a consumer
may always want to see a managing director. vCard provides a "title"
parameter in [RFC6350] section 6.6.1 and the "role" parameter in
section 6.6.2. These parameters are based on [ITU.X520.2001] "title"
and "business category" attributes. If CLUE utilises the vCard
format then it could utilise these parameters to carry information
regarding a person's occupation.
The vCard "role" parameter is a single text value. In order to
provide interoperability between advertiser and consumers CLUE could
recommend that the ISO classifications as discussed in section 2.5 be
used whilst allowing an advertiser to use a free text field.
Therefore it is proposed that CLUE allow vCard/s be associated with
media captures for this purpose.
3.5.3. Organisation Name
vCard [RFC6350] defines a data format for representing and exchanging
a variety of information about individuals and other entities. The
information is grouped into the following set of properties:
o Identification Properties
o Delivery addressing properties
o Communications Properties
o Organizational Properties
o Explanatory Properties
o Security Properties
o Calendar Properties
These properties allow a wide range of information to be transmitted
in a manner that interoperable between an advertiser and consumer.
vCard allows the description of persons, groups, organisation and
Groves, et al. Expires January 10, 2014 [Page 11]
Internet-Draft Abbreviated Title July 2013
locations. This would allow an Advertiser to send information
regarding the organisation and location where the endpoint is located
as well as the people participating in the conference. Having this
information available regarding the persons/groups/organisations
allows for service innovation.
As discussed previously metadata regarding captures needs to be sent
before or with the CLUE messages as the data needs to be an input
into capture selection. Leaving such information to be collected
later in the conference establishment process e.g. via XCON or some
other means would not be appropriate.
An advertiser may choose to send a minimal set of information such as
only a name or a more complete set with personal title, job title
etc. The only mandatory vCard field (apart from syntax related ones)
is the "FN" (Formatted name) property (section 6.2.1/[RFC6350]).
This relates to the vCard "object" rather than a "person" which
allows for names other than person names to be used. So an endpoint
could transit the meeting roles even if the names of the people in
the conference are not available.
vCard also allows information to be transmitted in multiple languages
as specified by a language property parameter.
The vCard format is also a widely supported for electronic business
cards and are often associated with e-mail messages. Rather than
defining a new format for personal information in CLUE it would be
beneficial to capitalise on a format that enjoys wide use.
In terms of the CLUE data model it may not be necessary to carry a
vCard format syntax for each capture due to the fact that a person/
group/organisation may appear in multiple capture. For example: An
Advertiser that has 3 cameras (VC1,VC2,VC3) each capturing one
person, one camera (VC4) capturing the room and a microphone
capturing the room would be advertised as:
CSE1(VC1[vCARD1{syntax}],VC2[vCARD2{syntax}],VC3[vCARD3{syntax}])
CSE2(VC4[vCARD1{syntax},vCARD2{syntax},vCARD3{syntax}])
CSE3(AC1[vCARD1{syntax},vCARD2{syntax},vCARD3{syntax}])
If the contents of each of the vCARDs was large this would result in
a large CLUE message size. Therefore it would be more appropriate to
transmit the vCARDs in a separate section of the CLUE message and
provide a pointer to the card in a capture attribute. Additionally
rather than transmitting the entire vCARD in the CLUE message a URI
to location where the vCARD can be downloaded should be possible.
Groves, et al. Expires January 10, 2014 [Page 12]
Internet-Draft Abbreviated Title July 2013
4. Capture scene attributes
The current CLUE framework contains a Capture Scene attribute
"Description" which is a human-readable description of the capture
scene. As can be seen vCard allows a rich description regarding a
person or an organisation. In the case that a scene represents an
endpoint as a whole rather than associating a vCard with each media
capture it may be desirable to associate a vCard with the Capture
Scene.
5. Summary of proposed updates
1. The addition of a capture attribute "Meeting Role" attribute
with values as per section 3.1 and 3.2.
2. The addition of a capture attribute "Conference System
Control Role" attribute with values as per section 3.3.
3. The addition of a capture attribute "vCard" that allows one
or more vCards according to [RFC6350] to be associated with a
capture.
4. The addition of a capture attribute "End point vCard" that
allows a "group", "org" or "location" kind of vCard according
to section 6.1.4/[RFC6350] to be associated with a capture.
6. Acknowledgements
This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.
7. IANA Considerations
The "Meeting Roles" and "Conference Control Roles" attribute may have
an IANA registry associated with them to facilitate the addition of
future new roles.
vCard already has IANA registration procedures for new properties,
parameters and values.
8. Security Considerations
Providing "meeting role", "conference control role" and "vCard"
attributes raises the question of whether the endpoint (or the people
at the endpoint) are authorized to provide the roles and are who they
say they are?
Groves, et al. Expires January 10, 2014 [Page 13]
Internet-Draft Abbreviated Title July 2013
The context of the use of these attributes is for the purposes of
choosing media captures not to provide pre-authorization for the
control of conference control function. It is expected that the
original SIP exchange would provide an "authorisation" between the
Advertiser and Consumer to utilize a CLUE signaling channel.
Therefore there is some level of trust between these two entities.
An Advertiser could send false information regarding a media capture.
For example it may assert in a vCard attribute that a person in a
capture is "King Richard" when the person is not. However this is
not problematic only for "role" related attributes it applies to any
asserted information in CLUE i.e. every attribute.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.groves-clue-capture-attr]
Groves, C., Yang, W., and R. Even, "CLUE media capture
description", draft-groves-clue-capture-attr-01 (work in
progress), February 2013.
[I-D.ietf-clue-framework]
Duckworth, M., Pepperell, A., and S. Wenger, "Framework
for Telepresence Multi-Streams", draft-ietf-clue-
framework-10 (work in progress), May 2013.
[ITU.X520.2001]
International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory:
Selected attribute types", ITU-T Recommendation X.520, ISO
Standard 9594-6, February 2001.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Groves, et al. Expires January 10, 2014 [Page 14]
Internet-Draft Abbreviated Title July 2013
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011.
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized
Conferencing (XCON)", RFC 6501, March 2012.
Authors' Addresses
Christian Groves (editor)
Huawei
Melbourne
Australia
Email: Christian.Groves@nteczone.com
Weiwei Yang
Huawei
P.R.China
Email: tommy@huawei.com
Roni Even
Huawei
Tel Aviv
Isreal
Email: roni.even@mail01.huawei.com
Groves, et al. Expires January 10, 2014 [Page 15]
