Document: FSC-0057
Version:  002
Date:     30-Nov-1991




               Echo Area Managers - Specifications for Requests


                                Fabiano Fabris
                              2:230/41.22@FidoNet


                                  Revision: 2




    Status of this document:

    This FSC suggests a proposed protocol for the FidoNet(r) community,
    and requests discussion and suggestions for improvements.
    Distribution of this document is unlimited.




    Fido and FidoNet are registered marks of Tom Jennings and Fido
    Software.
    TosScan is copyright Joaquim H. Homrighausen.
    IMAIL is copyright Fabiano Fabris.





    1  Purpose

       This document will explore the methods implemented by various
       echo area managers which process requests (in net mail form) for
       changes to the echo 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 create a standard, one which tries
       to maintain compatibility with methods already in use, while also
       extending them to provide new functions.



    2  Format of the request

       A request to an echo area 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 echo area 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 1:234/56
          To:       Program,  on 1:987/65
          Subject:  password

       Here the first problem is encountered. Each of the existing
       programs recognizes a different addresee. 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 "AreaMgr" has been arbitrarily chosen.

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



    3  Linking and Unlinking of echo areas.

       The current methods for requesting that an echo area be linked are
       basically two:

          +ECHONAME
          ECHONAME

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




                                     - 1 -




       Requests that an echo area be unlinked are given by:

          -ECHONAME

       As an extension to this, it should be possible for a system to
       request that all available echo areas be linked or unlinked. This
       could be accomplished as follows:

          %+ALL
          %-ALL

       The first would link all the areas available to the system, while
       the second would unlink all those areas which were linked to it.

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

          +ECHONAME
          %-ALL

       would be redundant, since the echo area manager would link ECHONAME
       from the first line, and then immediately unlink it again because
       of the second line.



    4  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, in that 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
                                  area manager is to be used.

         %LIST                    Lists the echo areas currently available
                                  to the requesting system, on the basis
                                  of a method internal to the echo area
                                  manager itself. This list included the
                                  areas which are already linked.

         %QUERY                   Lists the echo areas currently linked to
                                  the requesting system.

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




                                     - 2 -




    5 Rescanning Echo Mail

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

      This may be accomplished by specifying the %REQUEST command in the 
      body of the request.

      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

      This kludge has already been implemented in IMAIL.



    6  Remote Maintainance

       Besides these simple functions, it is becoming more and more
       interesting to make handling of the echo 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 echos as need requires. Thus a hub or coordinator could
       automatically have a new area added to their echo lists, or
       discontinued ones removed.

       Naturally, the echo area manager 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 an echo area manager be able to automatically
       add a new echo area 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 echo area
       via remote, this could be done by including a line such as the
       following in the message text:

          &ECHONAME



                                     - 3 -




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

          ~ECHONAME

       Thus, if the system has remote privileges, the echo would be
       deleted.

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

          # OLD_NAME : NEW_NAME

       (where the spaces are optional, but allowed).

       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 1:234/1
          To:       Program,  on 1:987/65
          Subject:  password
          Text:
          %FROM: 1:234/56
          +ECHONAME

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



    6  Further Automation

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

       For example, if an echo area 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 echo being deleted from all systems "below" him.

       Similarly, remote requests for echo tag changes could also be
       passed on to downlinks.

       An echo area 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 echo lists
       for the requested area, and if found, would send a request for that
       area.




                                     - 4 -




    7  Comments in the request

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

       In all cases except the above, the request can be deleted by the
       area manager once processed, but messages containing comments
       should be retained.

       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 echo area managers have
       implemented the %COMMENT command.



    8  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 echo
       area managers.

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



























                                     - 5 -

