# # This file uses prep, the cool preprocessor... -lynx # #require html/util #require psyc_draft # #sign #paper_body #paper_on confctrl-00 , next week , July 96 , conferencing.html #paper_name MMP Conference Control Module #paper_status

Abstract

This document describes an extension module to the Modular Message Protocol providing a minimalistic set of conference control instructions sufficient to satisfy a large variety of necessities in synchronous conferencing.

Synchronous conferencing allows for groups of people to communicate in real time over a computer network.

The established protocol in the field of text-based synchronous conferencing is IRC (RFC1459). IRC has a scaling problem with its inherent structure.

PSYC is a totally different and new approach which should be able to overcome the problems of IRC.

The PSYC conference control subprotocol is totally independent from both the contents and the means of communication between the parties.

It is also generalized as to be of use for any kind of group communication.

Syntax

    {group variable} :=
	  "_struct_group"	# {group structure} of members and authorities
	| "_list_props_group"	# {group property} flags

    {group property} :=
	  "_allow_externals"	# ghost messages are permitted
	| "_add_members"	# members may add members
	| "_add_listeners"	# members may add listeners
	| "_add_listeners_too"	# listeners may add listeners
	| "_remove_members"	# members may remove members
	| "_remove_listeners"	# members may remove listeners

    {group structure} :=
	[ {group multicaster}	# multicaster location that will satisfy ..
	  "(" {group member}+ ")" ]*
				# .. members included in parentheses
	[ {group member} ]*	# members which arent multicastable

    {group member} :=
	{identification} ","		# UNI for this member
	[ {network location} ","	# current UNL for this member
	[ {membership options} ","	# default value is "SL"
					# empty also equals default value
	[ {schemes} ]*			# alternative schemes and port numbers
	] ]

    {membership options} :=
	  "S"			# member is allowed to speak
	| "L"			# member listens
	| "A"			# member is a group authority

Semantics

Every network object may define an associated multicast group which is referenced by the same name, although logically, not physically. Once it does so, we call it a group manager.

At first only the group manager is entitled to send its group members group modifiers as defined above. Via means of MMP and appropriate underlying protocols it will inform all group members of the group structure _struct_group which is a structured hierarchical list of involved PSYC objects. It may also send a set of group properties _list_props_group.

Every member will have to extract itself from the _struct_group and look at the membership options the manager has set. If the S-flag isn't set, it MUST NOT send to the group, and should it illegally do so just the same, the receivers or even intermediate agents SHOULD discard the message and NOT bring it to any user's attention unsolicitedly. They MAY generate an error message reply (on a message layer, PSYC) or report the event to an administrator.

Members SHOULD send to all members with the L-flag set. Exception to this rule is when the _allow_externals property has been set by a group authority. In that case any network object may send a message to the group and expect to be received, not discarded.

Group authorities are objects allowed to send variable modifications to the group members. In the beginning the group manager is the only group authority, but via the A-flag in the _struct_group variable it may enable additional authorities. It is however by definition impossible to disable the manager's authority (unless you kill the server process ;°)).

Group authorities are permitted to send privileged messages to the group, but they need to have the L-flag set to be able to monitor channel conversation, which SHOULD not be the normal case.

Group members MUST always be permitted to send a variable modification message to remove themselves from the group.

TODO - skipping some properties.

It is not a requirement that the group manager makes use of all the mechanisms provided by the above variables. A large group may be implemented in a form whereas only the manager multicasts to all receivers and some privileged users communicate directly with the manager and submit their messages. In such a situation receivers need not be informed of any group members at all.

In fact the group manager may choose at any time to let members have differing (and inconsistent) state by sending "personalized" variable modifications to them. Being too experimental with these possibilities will probably lessen the popularity of your group, though. ;-)

One viable optimisation could be not to let listeners have a list of (other) listeners, since they won't need to neither talk to them, nor accept messages from them.

Variable Modifier Syntax Extension

The PSYC/MMP variable modifier syntax is extended to serve the family of _struct type variables, so far only represented by _struct_group.

The family of _augment_struct methods is defined as being capable to merge the contents of the stored struct with the incoming struct.

The family of _diminish_struct methods is defined as being capable to subtract the contents of the incoming struct from the stored struct, where, in the case of _struct_group, multicasters are only removed when nothing is left for them to multicast to.

Style

Group managers SHOULD not include human members unsolicitedly, modifications of the _struct_group variable to add a human to the group SHOULD always be the effect of that user's agent issuing the appropriate entry command as a reply to an invitation. Both operations are beyond the MMP layer, they are likely to take place within PSYC.

On reception of such an unsolicited inclusion into a group the user agents SHOULD silently send a message to the group members removing itself from the group, unless otherwise configured by the user or administrator.

Discussion

There's no doubt this whole scheme gives an impressive amount of power to the implementor of the group manager. I believe this is something we want! But we need to collect experience with this scheme. Anyway, if you want to make sure a popular channel (er.. sorry.. group) won't end up "owned" by a single person you'll have to run an implementation off-the-shelf from a big public server whose admin is trustworthy.

Oh well.. long-term bullying can be dealt with, just open up your own channel. What's awful with IRC is the way a channel isn't safe even short-term, talking about channel op hacking and stuff, and that we definitely get rid of!

I have left out the _add_authority and _remove_authority properties since they appear mostly redundant and useless.

_add_listeners_too is a silly name. suggestions?

_remove_listeners_too sounds like a rather silly thing to add, too.

Having the distinct notion of speakers and listeners isn't really a necessity if the maximum complexity is just moderations. But it appears to make some sense when it comes to doing virtual environments and management of adjacent rooms where you might be hearing voices but they don't hear you and things like that. Remember, this protocol is designed to also serve as VRML 3.0 proposal. ;-)

#paper_off