Subject: [clue] Text on participant type / participant information / scene information (ex.roles) for framework

From: Christian Groves <[email-masked]>
Date: Mon, 27 Jan 2014 21:44:16 +1100

Hello all,

There's an open ticket for me to provide some text regarding "roles" for 
the framework. Here's an initial attempt.

7.1.1.x Participant Information

The participant information attribute allows a Provider to provide
specific information regarding the conference participants in a Capture.
The Provider may gather the information automatically or manually from a
variety of sources however the xCard [RFC6351] format is used to convey
the information. This allows various information such as Identification
information (section 6.2/[RFC6350]), Communication Information (section
6.4/[RFC6350]) and Organisational information (section 6.6/[RFC6350]) to
be communicated. A Consumer may then automatically (i.e. via a policy)
or manually select Captures based on information about who is in a
Capture. It also allows a Consumer to render information regarding the
participants or to use it for further processing.

The Provider may supply a minimal set of information or a larger set of
information. However it MUST be compliant to [RFC6350] and supply a
"VERSION" and "FN" property. A Provider may supply multiple xCards per
Capture of any KIND (section 6.1.4/[RFC6350]).

In order to keep CLUE messages compact the Provider SHOULD use a URI to
point to any LOGO, PHOTO or SOUND contained in the xCARD rather than
transmitting the LOGO, PHOTO or SOUND data in a CLUE message.

7.1.1.y Participant Type
The participant type attribute indicates the type of participant/s
contained in the capture in the conference with respect to the meeting
agenda. As a capture may include multiple participants the attribute may
contain multiple value. However values shall not be repeated within the
attribute.

An Advertiser associates the participant type with an individual capture 
when it knows that a particular type is in the capture. If an Advertiser 
cannot link a particular type with some certainty to a capture then it 
is not included. A Consumer on reception of a capture with a participant 
type attribute knows with some certainly that the capture contains that 
participant type. The capture may contain other participant types but 
the Advertiser has not been able to determine that this is the case.

The types of Captured participants include:
1. Chairman - the participant responsible for running the conference
according to the agenda.
2. Vice-Chairman - the participant responsible for assisting the
chairman in running the meeting.
3. Minute Taker - the participant responsible for recording the minutes
of the conference
4. Member - the participant has no particular responsibilities with
respect to running the meeting.
5. Presenter - the participant is scheduled on the agenda to make a
presentation in the meeting. Note: This is not related to any "active
speaker" functionality.
6. Translator - the participant is providing some form of translation or
commentary in the meeting.
7. Timekeeper - the participant is responsible for maintaining the
meeting schedule.

Furthermore the participant type attribute may contain one or more
strings allowing the Provider to indicate custom meeting specific roles.

7.3.1.x Scene Information

The Scene information attribute provides information regarding the
Capture Scene rather than individual participants. The Provider may
gather the information automatically or manually from a variety of
sources. The scene information attribute allows a Provider to indicate
information such as: organizational or geographic information allowing a
Consumer to determine which Capture Scenes are of interest in order to
then perform Capture selection. It also allows a Consumer to render
information regarding the Scene or to use it for further processing.

As per 7.1.1.x the xCard format is used to convey this information and
the Provider may supply a minimal set of information or a larger set of
information.

In order to keep CLUE messages compact the Provider SHOULD use a URI to
point to any LOGO, PHOTO or SOUND contained in the xCARD rather than
transmitting the LOGO, PHOTO or SOUND data in a CLUE message.

Comments?

Regards, Christian