This document describes portions of version 0.99 of the PSYC Protocol for
SYnchronous Conferencing. You may consider it an Internet-Draft and as such
subject to all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
In all matters of intellectual property rights and procedures, the
intention is to benefit the Internet community and the public at
large, while respecting the design decision to keep the original author
of the protocol in charge. We don't like the bloat effects other efforts
are experiencing.
Only if you have developed an application in accordance to this specification
you may call it PSYC-compliant to the version mentioned above.
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. ;-)