Subject: [clue] Fwd: [dispatch] conference roles

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Apr 2013 22:29:10 +0800

I try to avoid cross posting, but there may be clue people who don't 
follow the dispatch list.

-------- Original Message --------
Subject: [dispatch] conference roles
Date: Wed, 03 Apr 2013 19:56:01 -0600
From: Peter Saint-Andre <[email-masked]>
To: DISPATCH <[email-masked]>

RFC 4575 (Section 5.6.3) defines the concept of a role in a
conference, but does not specify or define any roles.

5.6.3. <roles>

    This element MAY contain a set of human-readable strings describing
    the roles of the user in the conference.  Note that this information
    is applicable for human consumption only.  This specification does
    not define the set of possible conferencing roles or the semantics
    associated with each.  It is expected that future conferencing
    specifications will define these and the corresponding schema
    extensions, as appropriate.

RFC 6501 (Section 4.6.5.2) specifies a few values for the role
element, but does not actually define what those values mean.

4.6.5.2. <roles>

    A <role> provides the context for the set of conference operations
    that a participant can perform.  This element can contain one or more
    of the following values: "administrator", "moderator", "user",
    "participant", "observer", and "none".  A role of "none" indicates
    that any role is assigned.  The <roles> semantic definition is out of
    the scope of this document and is subject to future policy documents.
    This element can be extended with new roles in future documents.

(As far as I know, those "future policy documents" have not been
published.)

More recently, draft-groves-clue-capture-attr specifies several
additional roles: "manager", "chairman", "secretary", "lecturer", and
"audience" (so-called person roles) as well as "speaker" and
"controller" (so-called conference roles). Personally, I happen to
have an interest in defining a few other roles, such as "host",
"presenter", "scribe", and "panelist".

Unfortunately there's quite a bit of overlap and confusion here. For
instance, one could argue that "host", "manager", and "controller"
(perhaps even "chairman") are the same as or very similar to
"administrator" or "moderator" from RFC 6501. There might also be
overlap between "lecturer", "speaker", and "presenter" (and between
"speaker" and "panelist").

Furthermore, I'm concerned that various implementations will define
their own roles, blithely unaware that very similar (or even identical
but differently named roles) are already in use by other implementations.

It strikes me that one solution here would be to establish an IANA
registry for conference roles, with a registration policy (cf. RFC
5226) of at least Expert Review and perhaps Specification Required (I
think RFC Required is a bit heavy). IMHO this would help to prevent
continued confusion and the minting of new roles that overlap with
existing roles.

Thoughts?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 04 Apr 2013 08:42:45 -0600

FYI.

-------- Original Message --------
Subject: [dispatch] conference roles
Date: Wed, 03 Apr 2013 19:56:01 -0600
From: Peter Saint-Andre <[email-masked]>
To: DISPATCH <[email-masked]>

5.6.3. <roles>

4.6.5.2. <roles>

Thoughts?

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 04 Apr 2013 08:44:08 -0600

Sorry, I missed the fact that Paul already forwarded this!

---

From: Simon Pietro Romano <[email-masked]>
Date: Sat, 6 Apr 2013 00:39:19 +0200

Hi Peter,

thank you for raising such an interesting discussion. This reminds me of a specific thread dedicated to policies and roles inside XCON, back in 2007. I expressed my personal view on this subject in a (long) e-mail (http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html) you might want to have a look at. As you mention in your e-mail "future policy documents" have not been published.

Cheers,

Simon

Il giorno 04/apr/2013, alle ore 16:42, Peter Saint-Andre ha scritto:

> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Christian Groves <[email-masked]>
Date: Mon, 08 Apr 2013 15:40:10 +1000

Hello Peter,

I had envisaged that from the CLUE perspective that an IANA registry 
would be establish for Role (and some of the attributes). I'm not sure 
that it is possible to harmonise RFC4575, RFC6501 and CLUE as I think 
they have different semantics.

RFC4575 seems just to have a free text field that's human readable. The 
goal of the CLUE "role" attribute is to have a set of tags which are 
human readable and able to used in an automatic way.

RFC6501 talks about "conference operations that a participant can 
perform" I think this is semantically different to what is being 
proposed in CLUE which is more about the person/s in a capture (i.e. 
those depicted in the RTP stream).

If it helps lessen the confusion we could change the name of the CLUE 
parameter from "role" to "Character", "Captured Persons" or "Person 
represented by media", etc.? With the semantic that the media contains a 
person who is acting in that character/role.

I think part of the challenge will be to define the values. A person can 
have multiple roles/characters, e.g. a chairman who is acting as a 
scribe. Some have a similar function but have a different connotation 
e.g. presenter versus lecturer. I think to move forward we need to 
address these sorts of things. The previous RFCs seem to have largely 
ignored the problem in the final text. I'm not implying that it wasn't 
considered in their development.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Apr 2013 11:39:47 +1000

Hello Mike,

The intention is that role would be for both automated operation and 
possible human consumption. The idea is that an endpoint may have policy 
to select captures based on this sort of information. For example: I may 
have a 3 screen system but be in conference with three other endpoints. 
One of which may be where the Chief executive is sitting. If I have a 
policy of always seeing the Chief Executive then my endpoint would be 
able to automatically choose the capture with the Chief executive. The 
endpoint may also add an icon etc to the video display indicating it is 
related to the Chief executive this would be for human consumption.

Regards, Christian

On 8/04/2013 11:19 PM, Michael Hammer wrote:
> Could someone clarify whether these "roles" have any technical implication
> (affects automated system operation) or are they just for display for human
> consumption?
>
> If the latter, I would question a need for an IANA registry.
> (Note, you will also have to internationalize them as well and you won't
> please all cultures.)
> If someone wants to declare themselves Chief Executive and Bottle Washer,
> who cares?
>
> Mike
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: Monday, April 08, 2013 1:40 AM
> To: [email-masked]
> Subject: Re: [clue] Fwd: [dispatch] conference roles
>
> Hello Peter,
>
> I had envisaged that from the CLUE perspective that an IANA registry would
> be establish for Role (and some of the attributes). I'm not sure that it is
> possible to harmonise RFC4575, RFC6501 and CLUE as I think they have
> different semantics.
>
> RFC4575 seems just to have a free text field that's human readable. The goal
> of the CLUE "role" attribute is to have a set of tags which are human
> readable and able to used in an automatic way.
>
> RFC6501 talks about "conference operations that a participant can perform" I
> think this is semantically different to what is being proposed in CLUE which
> is more about the person/s in a capture (i.e.
> have multiple roles/characters, e.g. a chairman who is acting as a scribe.
> Some have a similar function but have a different connotation e.g. presenter
> versus lecturer. I think to move forward we need to address these sorts of
> things. The previous RFCs seem to have largely ignored the problem in the
> final text. I'm not implying that it wasn't considered in their development.
>
> Regards, Christian
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 10 Apr 2013 10:03:15 +1000

Hello Mike,

I think we are looking from different perspectives. I think what you are 
suggesting is that the provider is suggesting a priority for the 
display. My thought is that its the consumer who determines who to 
display. The CEO might have an ego that he wants to be displayed, but he 
may also be a terrible bore and I may want to see the scribe to see how 
much they're taking in... There was also a proposal for a priority 
attribute which could handle the guess of the Advertiser suggesting 
importance of captures.

With regards to the display text we could have a "display text" 
attribute for something like a person's name. I guess any offensive text 
can be handled by the conference participants :-). I don't know that 
this lessens the issues associated with a registry.

Regards, Christian

On 9/04/2013 11:01 PM, Michael Hammer wrote:
> Christian,
>
> Thanks for explanation.  I think it is possible that there could be
> situations where even though there is one or more CEOs present, another
> person, say President of US is on, or some other sense of priority, where
> CEO may not want to be in spotlight, but, say let the CFO be leading.  That
> suggests to me that the title and the priority order are really two separate
> things.
>
> It might be better to split this into two indicators, one that is strictly
> for display, the provides whatever title or label you want to have, no
> rules, no registry.  The other is an indicator of precedence that could
> align with who is CEO, or could line up in some other way.  I believe that
> would give you the flexibility to do your auto-ordering, while at the same
> time avoid the headaches of keeping an internationalized registry and
> worrying whether someone wants to call themselves the Prophet or something
> that others might find offensive.
>
> Mike
>
>
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, April 08, 2013 9:40 PM
> To: Michael Hammer
> Cc: [email-masked]
> possible human consumption. The idea is that an endpoint may have policy to
> select captures based on this sort of information. For example: I may have a
> 3 screen system but be in conference with three other endpoints.
> One of which may be where the Chief executive is sitting. If I have a policy
> of always seeing the Chief Executive then my endpoint would be able to
> automatically choose the capture with the Chief executive. The endpoint may
> also add an icon etc to the video display indicating it is related to the
> Chief executive this would be for human consumption.
>
> Regards, Christian
>
>> Could someone clarify whether these "roles" have any technical
>> implication (affects automated system operation) or are they just for
>> display for human consumption?
>>
>> (Note, you will also have to internationalize them as well and you
>> won't please all cultures.) If someone wants to declare themselves
>> Chief Executive and Bottle Washer, who cares?
>>
>> Mike
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Christian Groves
>> RFC4575 seems just to have a free text field that's human readable.
>> The goal of the CLUE "role" attribute is to have a set of tags which
>> are human readable and able to used in an automatic way.
>>
>> represented by media", etc.? With the semantic that the media contains
>> a person who is acting in that character/role.
>>
>>
>> I think part of the challenge will be to define the values. A person
>> can have multiple roles/characters, e.g. a chairman who is acting as a
> scribe.
>> Some have a similar function but have a different connotation e.g.
>> presenter versus lecturer. I think to move forward we need to address
>> these sorts of things. The previous RFCs seem to have largely ignored
>> the problem in the final text. I'm not implying that it wasn't considered
> in their development.
>> Regards, Christian
>>
>>> their own roles, blithely unaware that very similar (or even
>>> identical but differently named roles) are already in use by other
> implementations.