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]