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

From: Christian Groves <[email-masked]>
Date: Thu, 06 Feb 2014 12:23:38 +1100

Any comments regarding the participation information attribute text?

Christian

On 27/01/2014 9:44 PM, Christian Groves wrote:
> 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
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 12:03:25 -0500

This seems reasonable to me. (as an individual)

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 6 Feb 2014 09:19:04 -0800

I agree.  Thanks Christian, for writing it as specific text for the framework document.
Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, February 06, 2014 12:03 PM
> To: [email-masked]
> Subject: Re: [clue] Text on participant type / participant information / scene
> information (ex.roles) for framework
> 
> >> 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
> >> 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.
> >>
> >> 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.
> >> 6. Translator - the participant is providing some form of translation
> >> or commentary in the meeting.
> >> 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