My goal in building a new system was to save what was good about BIX, and replace/fix what was not. That is why you will find a lot of stuff on management here, because that's where BIX was broken.
Note: The specific size limits for the structure are not required, they simply reflect my initial implementation concept. What is important is the separation of data and management areas for flexability, and the six levels of RCCS data.
The conference structure has certain definitions that need to be followed to enable sharing across areas and across systems globally. Without these definitions, people will create structures that would require replicating at different levels of the conference for the same discussion.
The purpose of this section is to provide flexible management control over a conferencing system while allowing a lot of freedom to experiment and some capability for the users to exercise choice and control over actions which are offensive to the majority.
These notes were an initial design for very compact structure while allowing for very large systems. The fixed limits are not necessary, they were designed to fit into 16 and 32 bit word structures. This is easily changed.
This sections specifies, albeit briefly, what authority goes with which level of person in the administrative area. Please note the assumption that the administration data is kept separately from the conference data. The problem is one of too tight coupling.
Again, as part of the design for compact structures, the individual components were designed to fit efficiently into 32 bit words and 512 byte blocks. Messages were blocked rather than variable length for faster access and faster rebuilding if needed.