Document: FSC-0057
Version:  003
Date:     07-Dec-92

               Conference Managers - Specifications for Requests

                               December 7, 1992

                   Fabiano Fabris      Joaquim H. Homrighausen
                2:285/304.100@fidonet      2:270/17@fidonet

    Status of this document:

    This FSC suggests a proposed protocol for the FidoNet(r) community, and
    requests discussion and suggestions for improvements. Revision 3
    presents several additions and enhancements over the previous revision.

    Distribution of this document is unlimited.

    Fido and FidoNet are registered marks of Tom Jennings and Fido

    1  Purpose

       This document will explore the methods implemented by various
       conference managers which process requests (in net mail form)
       for changes to the conference mail links on the system on which
       they are in use.

       Until now, it would appear that no real standard exists, so most
       software authors have either tried to emulate another program, or
       to create a new method of their own, or both.

       Here, an attempt will be made to define a standard, one which tries
       to maintain compatibility with methods already in use, while also
       extending them to provide new functions.

    2  Conventions

       The names of the commands described in the following paragraphs are
       given in upper case, for legibility. However, a conference manager
       should be able to interpret them even if they are given in lower
       or mixed case.

       Similarly, conference names, or tags, are given in upper case, but
       the conference manager should be able to handle them even if typed
       in lower or mixed case.

       Optional information is enclosed with square brackets, while
       variable information is enclosed with angle brackets. For example:

          +CONF [,R=<n>]

       indicates that the section within square brackets is optional, and
       if supplied, requires a parameter after the equals sign.

       Some conference managers may allow commands to be abbreviated to the
       shortest non-ambiguous string. For example, %LIST might be reduced
       to %L.

    3  Format of the request

       A request to a conference manager is generally made in a net mail
       message containing specific information in some of the fields. In
       particular, the addressee is the name of the conference manager
       itself, and the subject of the message is a password assigned by
       the sysop of the system running the program.

       For example:

          From:     John Doe, on 2:123/56
          To:       Program,  on 2:234/0
          Subject:  password

       Here the first problem is encountered. Each of the existing programs
       recognizes a different addressee. For this reason it is proposed
       that all such programs recognize requests made to a single,
       "standard" addressee, besides any other they may wish to implement.
       The term "ConfMgr" has been arbitrarily chosen, and should be used
       by those programs which adhere fully to all the standards proposed
       in this document.

       The text of the message itself contains the request proper, and is
       the subject of the following paragraphs.

    4  Linking and Unlinking of conferences.

       The current methods for requesting that a conference be linked are
       basically two:


       For reasons of uniformity, it is proposed that all conference
       manager programs recognize the first method.

       Requests that a conference be unlinked are given by:


       It might be interesting to implement some form of pattern matching,
       similar to the unix shell. The following basic wildcards should be

          *        matches zero or more characters
          ?        matches any one (not zero) character

       Since the requests are processed top-down, a request of the form


       would be redundant, since the ConfMgr would link CONFNAME from the
       first line, and then immediately unlink it again because of the
       second line, which requests that all linked conferenecs be unlinked.

       It should also be possible to specify more than one conference tag
       on the same line. For example:

          +CONF1 CONF2 CONF3

       would link the three conferences CONF1, CONF2 and CONF3.

    5  Rescanning Conference Mail

       Many conference managers currently allow a system to request that an
       area be "rescanned". In other words, the system receiving the
       request will export all mail in one or more areas to the requesting

       This may be accomplished by specifying the %RESCAN command in the
       body of the request. This will force the ConfMgr to generate a scan
       request for those areas which the remote system requested with the
       message containing the %RESCAN command.

       Rescans of a single area, newly linked, could be requested as

          +CONFNAME, R[=<n>]

       where 'n' is the number of messages in that area to be rescanned.
       (The space following the comma is optional, but allowed.)

       Rescanning has one serious drawback: dupes! It is very possible for
       the requesting system to have already set up the area with several
       downlinks. Thus, when the rescanned mail is received, it could be
       exported to other systems. In a tree-based topology, this is
       harmless, but in circular topologies this would create dupes.

       Thus, it is proposed that system receiving the rescan request add a
       kludge to the messages, so that they can be recognized by the
       requesting system and not re-exported.

       The proposed kludge is:

          ^ARESCANNED <addr>

       where <addr> is the network address, including domain, of the
       system from which the mail was rescanned.

       In alternative to a rescan, a sysop might request a "sample",
       consisting of a series of messages contained in a text file. The
       ConfMgr would export some or all messages from an area to a plain
       ASCII text file, and send it along with the reply, to the requesting
       system. A "sample" request would be made as follows:

          +CONFNAME, S[=<n>]

       where 'n' indicates how many messages should be sampled.

       a) Updating Conferences

          Update requests allow a sysop to rescan or "sample" an area
          without having to first unlink from it, and then relink with the
          rescan or "sample" parameter.

          The format of this command is:

             =CONFNAME, <param>[=<n>]

          Thus a rescan request for the most recent 50 messages would be
          specified as:

             =CONFNAME, R=50

    6  Information Requests

       Requests for information have until now taken two forms. In one
       case, they are given as switches after the password on the subject
       line, while in the second they are given as "commands" within the
       body of the message text. It is proposed that the second method be
       chosen as standard, since it is considerably more flexible.

       Below are listed the proposed commands:

         %HELP                    Sends a (pre-defined) help text to the
                                  requesting system, explaining how the
                                  ConfMgr is to be used.

         %LIST[,B]                Lists the conferences currently available
                                  to the requesting system, on the basis
                                  of a method internal to the conference
                                  manager itself. This list would flag the
                                  areas which are already linked. The 'B'
                                  modifier would generate the list in
                                  binary format (see section 8e).

         %BLIST                   Equivalent to %LIST,B above.

         %QUERY                   Lists the conferences currently linked to
                                  the requesting system.

         %UNLINKED                Lists the conferences which are available
                                  to the requesting system, but not
                                  currently linked. This is the logical
                                  difference between a %LIST and a %QUERY.

    7  Remote Maintenance

       Besides these simple functions, it is becoming more and more
       interesting to make handling of the conference mail flow even more
       automatic. For this reason, for example, it might be useful to
       allow another sysop control over your own system, adding and
       removing conferences as need requires. Thus a hub or coordinator
       could automatically have a new area added to their conference
       lists, or discontinued ones removed.

       Naturally, the ConfMgr must be able to distinguish which system has
       the ability to make such changes, but that is beyond the scope of
       this document.

       It is proposed that a conference manager be able to automatically
       add a new conference to the system's list if/when it is detected.
       Thus no special commands would be required. The manager should be
       able to determine a default list of down-links for the new area,
       and also the "group" of systems which could then request it.

       However, should it be desired to explicitly create a new conference
       via remote, this could be done by including a line such as the
       following in the message text:


       In order to remote delete an area, the requesting sysop should
       include a line like this in the body of the message text:


       Thus, if the system has remote privileges, the conference would be
       deleted (and optionally, all systems linked to the conference could
       be informed of this fact).

       Similarly, it would also be possible to allow a system to change the
       tag of a conference. This would be accomplished by a line such as:

          # OLD_NAME  NEW_NAME

       The ConfMgr should inform all downlinks of the change by sending a
       net mail message.

       It might also be desirable to allow a sysop to make changes on
       behalf of another system. This could be done by inserting a special
       command at the beginning of the request itself. For example:

          From:     John Doe, on 2:123/1
          To:       Program,  on 2:987/65
          Subject:  password
          %FROM: 2:234/56

       The %FROM command would make the ConfMgr carry out the changes as if
       the system 2:234/56 had requested them. The password should
       nonetheless be the one assigned to 2:123/1.

    8  Further Automation

       In order to make the system more powerful, and to reduce the
       necessity for human intervention, several extensions are feasible.

       a) ARCmail Compression Method

          One interesting application is the possibility of allowing a
          remote system to change the compression program used to "pack"
          mail bound for his system. This could be done with the following
          command in the message to a ConfMgr:

             %COMPRESS <method>

          where <method> is one of the compression programs supported by
          the system. Of course, the remote system should also be able to
          determine which compression methods are available; this could be
          done with

             %COMPRESS ?

          Requests for an unsupported compression method should also be
          responded to with a list of those available.

          From the practical point of view, only systems which pick up
          their mail (as opposed to those to whom mail is sent) should be
          allowed to change the compression method used. How this
          distinction is achieved is beyond the scope of this document.

       b) Passwords

          A sysop should be able to change the password used to make
          requests to a ConfMgr without requiring the intervention of the
          other system's sysop. This could easily be done if the
          conference manager implemented the following command:

             %PWD <new_password>

          The new password (case insensitive) would replace the current
          one as of the next request.

       c) Temporary Unlink

          Should a system's sysop be absent for a prolonged period of time,
          he might want to temporarily cut all conferences from his
          uplink.  This could be accomplished with the


          command. This would tell the ConfMgr to temporarily stop sending
          conferences to that system.  On his return, the sysop could
          reactivate them all with the



       d) Forwarding Remote Requests

          If a conference manager receives a remote request to delete an
          area, it could very easily "forward" that request to all its
          downlinks by producing a similar request.  In that way, a single
          request originating from, for example, a Region Coordinator,
          would result in the conference being deleted from all systems
          "below" him.

          Similarly, remote requests for conference name changes could
          also be passed on to downlinks.

       e) Automatic Requests for Conferences

          A conference manager should also be able to automatically request
          an area from an uplink. This would become necessary if, for
          example, it processed a request for an area not currently
          available on the system. In this case, it would scan a series of
          conference lists for the requested area, and if found, would
          send a request for that area.

          In order to be able to do this, the ConfMgr would need to have
          one or more lists of conferences from the uplinks. These lists
          could be produced on request by the ConfMgr itself. In order to
          simplify matters, a binary format is proposed. (Note that these
          are C-style structures, with everything which that implies.)
          This binary file is called a Binary Conference List (BCL).

          The file starts with a header, containing some basic system

             struct bcl_header {
               char    FingerPrint[4];     /* BCL<NUL> */
               char    ConfMgrName[31];    /* Name of "ConfMgr" */
               char    Origin[51];         /* Originating network addr */
               long    CreationTime;       /* UNIX-timestamp when created */
               long    flags;              /* Options, see below */
               char    Reserved[256];      /* Reserved data */

          The currently defined flags for the header are:

            BCLH_ISLIST     0x00000001L
              File is complete list

            BCLH_ISUPDATE   0x00000002L
              File contains update/diff information

          The BCL would then contain a series of entries having the
          following format:

             struct bcl {
               int     EntryLength;      /* Length of entry data */
               long    flags1, flags2;   /* Conference flags */
               char    *AreaTag;         /* Area tag [51] */
               char    *Description;     /* Description [51] */
               char    *Administrator;   /* Administrator or contact [51] */

          The flags currently defined are:

             FLG1_READONLY   0x00000001L
                Read only, software must not allow users to enter mail.

             FLG1_PRIVATE    0x00000002L
                Private attribute of messages is honored.

             FLG1_FILECONF   0x00000004L
                File conference.

             FLG1_MAILCONF   0x00000008L
                Mail conference.

             FLG1_REMOVE     0x00000010L
                Remove specified conference from list (otherwise add/upd).

          Thus, instead of scanning an AREAS.BBS style list, the ConfMgr
          would parse and use lists in the above format. Naturally, each
          list would be in some way "attached" to a node number, and a
          corresponding ConfMgr password.

          Each system may only have one master file, called anything they
          want. But when transmitted to other systems, this file must
          always be named ????????.BCL.

          The list would be generated in response to a

            %LIST, B

          command in the message text.

       f) Receipts

          It might be useful to have the ConfMgr generate a receipt to be
          sent to another system, perhaps a co-sysop or a sysop point
          node. This could be done with the command:

            %RECEIPT <name>,<address>

         embedded in the request message. For example:

            %RECEIPT JoHo,2:270/17

    9  Comments in the request

       It should be possible for a sysop to insert a comment in the request
       made to a conference manager. These comments, naturally, would be
       destined to the sysop of the system, and not to the conference
       manager itself. Such comments should be placed at the end of the
       message, following a %NOTE command.

       In all cases except the above, the request can be deleted by the
       ConfMgr once processed, but messages containing comments should be

       Note: the current method used is to supply comments after a tear-
       line. This practice is somewhat "messy", but it might be wise to
       support it until such time as all conference managers have
       implemented the %NOTE command.

    10 Summary

       +CONFNAME[,R|S]        Request to link to CONFNAME
       -CONFNAME              Request to unlink from CONFNAME
       =CONFNAME,R|S          Rescan or "sample" linked conference
       &CONFNAME              Request to create CONFNAME
       ~CONFNAME              Request to delete CONFNAME
       #OLD NEW               Name change request

       %LIST[,B]              List available areas, flag linked
       %QUERY                 Only list linked areas
       %UNLINKED              List available but unlinked areas
       %HELP                  Send help text
       %FROM <addr>           Simulate request from another system
       %RESCAN                Rescan conferences linked in current request
       %COMPRESS <method>     Change compression method
       %PWD <new_pwd>         Change ConfMgr password
       %PAUSE                 Suspend link
       %RESUME                Resume link
       %RECEIPT <name>,<addr> Send copy of receipt to another system
       %NOTE                  Introduces comment to the sysop

    11 Final Note

       This document is to be considered as a suggestion for software
       developers to make their programs compatible with one another, so as
       to make life easier for the average sysop when dealing with
       conference managers.

       Feedback would be appreciated and can be sent to us at the addresses
       specified on the title page. Please send feedback via netmail only.