Subject: [dispatch] conference roles

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Apr 2013 19:56:01 -0600

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/

---

From: Brian Rosen <[email-masked]>
Date: Fri, 5 Apr 2013 09:20:28 -0400

> continued confusion and the minting of new roles that overlap with
I like this idea.

Brian

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 5 Apr 2013 16:57:16 +0300

> continued confusion and the minting of new roles that overlap with
I do think is a good idea to establish a IANA registry for conference roles
and I concur on the fact that RFC Required is a bit too much (and 
unnecessary)

cheers
Salvatore

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 05 Apr 2013 09:30:49 -0600

> and I concur on the fact that RFC Required is a bit too much (and

OK. I might write a brief I-D about this sometime soon.

Peter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Apr 2013 23:31:42 +0800

This also seems reasonable to me. But I would be conservative about 
policy for new ones. I don't think we know enough to describe criteria 
for an expert, and I expect there to be a lot of bad ideas to come up 
here. So I think I would go for Standards Action for now, to ensure 
strong debate.

Even then, I think we need to think hard about definitions for the first 
batch, that clearly distinguish one role from another.

	Thanks,
	Paul

On 4/5/13 9:20 PM, Brian Rosen wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 05 Apr 2013 09:37:24 -0600

> here. So I think I would go for Standards Action for now, to ensure

You make a good point about being able to provide clear guidelines to an
expert. We either need to figure that out during the process of defining
this IANA registry or use the standards process to become clear on each
registration request as it comes in.

> batch, that clearly distinguish one role from another.

Agreed.

Peter

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 5 Apr 2013 23:46:00 +0300

Hi,
I think that we first need to understand the scope of the role. 
RFC 4575 talks about the role of the user. This is the conference
participant.
There is also RFC4796 that defines the content attribute which talks about
the content of an RTP stream.
In CLUE we are talking about a capture which is a specific stream again and
not about the participant role.
So if we proceed we first need to specify what we mean by role.

Roni Even.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Peter Saint-Andre
Sent: 04 April, 2013 4:56 AM
To: DISPATCH
Subject: [dispatch] conference roles

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>

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>

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/

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 5 Apr 2013 18:23:25 -0400 (EDT)

> From: Peter Saint-Andre <[email-masked]>
> 

My thought is that more work than this is needed.  We may not need an
RFC to review and define a good set of role names, but I think we need
to start with an I-D that discusses all the issues and desiderata of
how to define role names, and establishes an initial set.  Only that
sort of writing, discussion, and analysis will solidify knowledge of
what how such a registry should operate.

Dale

---

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

Perhaps I should have kept this on the dispatch list?

Christian

On 8/04/2013 3:40 PM, Christian Groves wrote:
> 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
>
> On 5/04/2013 1:42 AM, Peter Saint-Andre wrote:
>> FYI.
>>
>>
>> -------- Original Message --------
>> Date: Wed, 03 Apr 2013 19:56:01 -0600
>> To: DISPATCH <[email-masked]>
>>
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Apr 2013 11:50:07 -0600

> Perhaps I should have kept this on the dispatch list?

Perhaps. At the least, it would be good to have one place to talk
about this topic.

>> 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.

Apparently I got confused by the use of the term "role" in
draft-groves-clue-capture-attr because to me it seems like an
extension to the roles defined in RFC 6501, which provided some new
values for the same construct defined in RFC 4575. What you're saying
is that the CLUE roles proposed in draft-groves-clue-capture-attr are
actually a completely different construct. That is, RFC 4575 and RFC
6501 define roles as essentially bundles of permissions to perform
certain operations, whereas the roles / characters in
draft-groves-clue-capture-attr have nothing to do with conference
control. Correct?

>> 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.

Agreed.

Just FYI, in the XMPP community we had thought about the concept of
"hats", which are roles you can play in a conference (and you can play
multiple roles, just as you can wear different hats). We have a very
basic spec for hats here:

http://xmpp.org/extensions/xep-0317.html

Rather than continuing to pursue the hats idea, I've been thinking
that it might be better to settle on using conference-info syntax from
RFC 4575 (since that would improve interoperability across SIP systems
and XMPP systems -- there's nothing SIP-specific about conference-info
itself). Unfortunately, it appears that the conference-info syntax is
clear but the semantics are not. I'm happy to put some cycles into
clarifying the semantics if there's interest.

(Now it seems that is a separate topic from the CLUE work, since CLUE
isn't actually using the RFC 4575 construct. So discussing this on the
DISPATCH list seems correct.)

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Apr 2013 20:03:45 -0600

On 4/8/13 11:50 AM, Peter Saint-Andre wrote:

> Just FYI, in the XMPP community we had thought about the concept
> of "hats", which are roles you can play in a conference (and you
> can play multiple roles, just as you can wear different hats). We
> have a very basic spec for hats here:
> 
> that it might be better to settle on using conference-info syntax
> from RFC 4575 (since that would improve interoperability across SIP
> systems and XMPP systems -- there's nothing SIP-specific about
> conference-info itself). Unfortunately, it appears that the
> conference-info syntax is clear but the semantics are not. I'm
> happy to put some cycles into clarifying the semantics if there's
> interest.

BTW, looking at RFC 4575, I notice that it defines a <roles> element
but doesn't describe the syntax very precisely:

4.6.5.2. <roles>

That seems to imply that the syntax is:

  <roles>
    <role>foo</role>
  </roles>

But the examples have:

  <roles>
    <entry>foo</entry>
  </roles>

And is the syntax a comma-separated or space-separated list of values,
or is it multiple child elements (whether <role/> or <entry/>)?

Anyone up for 4575bis??? ;-)

Peter

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Apr 2013 12:27:24 +1000

Hello Peter,

Do you mean RFC6501bis? :-)

Christian

On 9/04/2013 12:03 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRY3cBAAoJEOoGpJErxa2p9IsP/3FOY+Qz5ECnnhUsYnnZP4+y
> VgBggrhh2o0sBtm9h8Sx+afI6eH6TRje6uwDf6nfxMW3RPDdycThWFpC5Swkgetz
> wosAWSlSELU5lm0uHcN+OBaHLb023bVdOqV6BRo+7LoYXY2g+nimJzHeyTxCCisC
> gegdfoUVeffFtncaFcI1i2Fd5uoFk18jqLj0naZvUtgg+v8ETJVPFAQhyAae7qVL
> IME6Hgi853OVulckGvYD6uDU+VR36L0wQAydbJzjah3ntvw4qCjU1nggoYi+r5ED
> Leekvzz7tOn6+INzgKZpccei1OXNBmpibT+6IkNCieMSD2/uimIiMwK9fpFtrhp3
> sAXzEhzX6+FtsghSUgqQgS6YjbammFk9lzkIPCN4iItxG1/vcYbfoWjSnWptQVAB
> ONHOFp+O5sikBrfxHpoIO5Yl1k7WcA8zX/2NDBHAD2fqFmBA6C7MHUBgb5pBmdkM
> WsoY8OW+07O9eN3YShqJqh11nPYYYX0Pdf1r5f3GtVlzGsqXbqSH6kn6P4g4w9UA
> tOfqC2H0CWIyvRdE8xYHvd2pwzimuzu+1qnpblPWFPhtYeqbCgzN8QHgxt2cTaY6
> rcYxc0OS64xa9fQHg8ludnY5KIFKv1JDaVuzgnN+6pjxrqzQgCC+zIu9W50vSL8p
> g+xahByFC+kkkkSOY6C/
> =CIF9
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Apr 2013 20:30:32 -0600

> Do you mean RFC6501bis? :-)

Maybe both, given that RFC 6501 elements refine, extend, or are
interleaved with the root <conference-info/> element from RFC 4575.

(But yes, I was quoting from RFC 6501 there...)

Peter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Apr 2013 21:57:48 +0800

Coming late to the discussion...

I agree that what CLUE is considering is a different usage than what RFC 
4575 is talking about. But in both cases we are talking about attributes 
that are applied to *something*. For CLUE it is Captures that we are 
attaching attributes to while in RFC 4575 it is participants.

If it makes sense, and I'm not yet sure it does in this case, we could 
have a definition of "role" that can be used by CLUE to describe 
captures and is also used in the conference event package to describe 
participants.

My point is that the "name" of this attribute need not fully define what 
we mean. Rather it is the name together with the thing it is applied to. 
So I don't have a problem calling this "role". (But I also have no 
problem calling it something else.)

In CLUE we tried this once - with "content" based on reusing the values 
from a=content. But then we decided that definition was too narrow and 
extending it enough would have undesirable consequences. It may turn out 
that sharing/reusing a definition for "role" is also problematic. But we 
can at least investigate it.

     Thanks,
     Paul

On 4/9/13 1:50 AM, Peter Saint-Andre wrote:
> iQIcBAEBAgAGBQJRYwNPAAoJEOoGpJErxa2p7b4P/1mWKSutcNRB7Zocwj4bFj43
> uYol1z/HSFBCPxLtqgVUL8EVifEImmf0aanMsX1+kgz/YMnpPNef5vISSL2GpQXW
> zWEUdZQ5CJInPXkkKY4kxmFLtqs4HBHBjjJiUjb99qFv++qgmNA0gTx5qEKfV5d4
> O1CR/ua6iZRj2W78srt4zln3GQbdbkOUqVkAkf/SoNvggSdMwEkI/ZDx34x7hCdP
> S2bn4tAcsRMFhLKiPPY0+oV4FRQ6/R4LE278dwmt2eqFQREJOMLiNOn2f3G5Bcr2
> P+f0nH22b2Nyd3KKQfvX34BiQebxRZ3VS+WrUJqofwz37/WL3CyoLOh9r+GSGrBJ
> y1ch18d28G/DbMOJQhYn41U0447A+mb0Q4VnuwB/YAeRn/DoXI0Y478slrJIkyXs
> pruktAusj4uhdCnTD5noBI3+4aGj7PNJIAWBCCb/EEGPOrQNnUDWoup345nxHZoK
> /SzXSaz+guiQsb/heOGCQYH+q9E25n0UWMgKBAiVGQ1O6/Bc/FLemnryRr6WDfVV
> qCofoU1wRbe2CS73LTnrH6+MeWY63Cjkv3jyTzzhuVdJIt1nopRwQMJvHWV48rii
> DHrBNZA1aweJhPLtjtSzNb1bxg1g0swRMpCnyfDNML4Je5h9mp3+M2+S8mZc8ssm
> qnM8GsRfyErV2pI505Fc
> =n3og

---

From: Mary Barnes <[email-masked]>
Date: Tue, 9 Apr 2013 09:15:11 -0500

Well, I had to join in the thread since it seems appropriate for Mary
to respond to a thread with Peter & Paul ;)   I do not think that the
CLUE usage is any different really than XCON conference package
defined role -  in terms of the "roles" being both human readable and
the semantics being unique to an application  and can be based on
policies.  The latter was the XCON/conference intent as clearly stated
in  section 4.6.5.2 of 6501. It's the right thing for SIP based
conferencing to be using this information and since CLUE is based on
SIP, we need to have these things consistent.

Regards,
Mary.

On Tue, Apr 9, 2013 at 8:57 AM, Paul Kyzivat <[email-masked]> wrote:
> If it makes sense, and I'm not yet sure it does in this case, we could have
> a definition of "role" that can be used by CLUE to describe captures and is
> also used in the conference event package to describe participants.
>
> My point is that the "name" of this attribute need not fully define what we
> mean. Rather it is the name together with the thing it is applied to. So I
> don't have a problem calling this "role". (But I also have no problem
> calling it something else.)
>
> In CLUE we tried this once - with "content" based on reusing the values from
> a=content. But then we decided that definition was too narrow and extending
> it enough would have undesirable consequences. It may turn out that
> sharing/reusing a definition for "role" is also problematic. But we can at
> least investigate it.
>
>     Thanks,
>     Paul
>
>
>

---

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

4.6.5.2 RFC6501 also says "A <role> provides the context for the set of 
conference operations that a participant can perform." To me this is a 
semantic. I think the issue is that it presents a set of values that 
have no definition and says that policy is defined in the future. The 
description so sparse its hard to see what its actually used for. Policy 
could be set by the endpoint manufacturer, user, service provider, a 
standards body etc.

Regards, Christian