| Document: FSC-0086
 | Version:  001
 | Date:     03 September 1995
 |
 | Mirko Mucko, 2:2433/920


               Information / Description of a new standard

                               S  tandard
                               R  equest
                               I  nformation
                               F  ile

          Copyright (c) 1994,95 by Gordian Schuermann & Mirko Mucko

I  Overview
               Introduction                            0
               Description in general                  1
                 Required statements                   1.1
                 Optional statements                   1.2
                 Undefined options                     1.3
               Implementation                          2.0




0. Introduction
In common, more and more mailer are about to implement the ability to
call external request processors. But very soon, we discovered a command
line cannot handle all the information the mailer has and the ERP needs.

To transfer the information in a proper and fast way, we designed and
implemented the S R I F option in the mean it will be a standard soon.

The structure and idea is protected by copyright law, except these
circumstances:

       +  you may distrubute, use and implement this structure for free
       +  you have not to pay any value for usage of these methodes
       +  you should note in your documentation the origin of SRIF

1. Descritption
The SRIF name is the only parameter given from the Mailer to the External
Request Processor. The file is designated as a so called "plain vanilla ASCII"
file, filled with pre-defined, optional and not-yet defined statemets.

We discussed the possibility of binary files, and of EMSI-like files, but
a plain ASCII control file is more flexible and can be read faster by
various program languages (C, Pascal, Basic, Cobol ect).

In the SRIF, one command plus parameter is allowed per line, the file
is unlimited in length, comments are not allowed.

The SRIF is generated by the Mailer and after the ERP finished its work,
the Mailer is responsible for erasing the SRIF.

1.1 Required statements
The following statements are required for the ERP:


      Sysop            <Sysop_Name>
                       This is the name of the remote sysop

      AKA              <Zone:Net/Node[.Point][@Domain]>
                       This is the main aka of the remote system in 4D or
                       5D notation. A zero as point number may be ommited,
                       the domain with "@" is optional

      Baud             <Current LINE rate>
                       This is the effective baud rate, not the fixed DTE rate

      Time             <Time in minutes>
                       This is the time till next event which does not allow
                       file requests. Use -1 if no limits

      RequestList      <File of request list>
                       This is the filename of the list containing requested
                       files.
      ResponseList     <File of response list>
                       This is the filename of the response list.
                       It must not be equal to RequestList. One file per line,
                       including drives/pathes to the file. The first
                       character defines the way the mailer should act after
                       sending that file:

                        =   erase file if sent successfully
                        +   do not erase the file after sent
                        -   erase the file in any case after session

      RemoteStatus     <PROTECTED or UNPROTECTED>
                       Defines whether the session is protected by password
                       or not

      SystemStatus     <LISTED or UNLISTED>
                       Defines whether the remote system is listed in any
                       current nodelist of system.

1.2 Optional statements
These parameters are already known and defined, but a ERP should run also
without them:

      SessionProtocoll <e.g. ZAP,ZMO,XMA

      AKA              <Zone:Net/Node[.Point][@Domain]>
                       Additional AKAs. One AKA is required (see REQUIRED
                       section)

      Site             <Site Info>
                        The site info as given e.g. in EMSI handshake

      Location         <Location and/or ZIP>
                        The location info as given e.g. in EMSI handshake

      Phone            <Phone Number>
                        The  phone number info as given e.g. in EMSI handshake

      Password         <Session password>
                        On protected sessions, the session password. If
                        no protected session, this parameter must be ommited!

      DTE              <Current DTE rate>
                        The PC<->Modem speed (so call DTE rate)

      PORT             <COM Port from 1 to 8>
                        The FOSSIL Communication Port. The Mailer should
                        leave the fossil "hot" for the Request Processor

      Mailer           <Remote's mailer if EMSI>
                         The Mailer name as defined by FTC

      MailerCode       <Remote's FTSC code>
                         The hex code of the remote mailer as defined by FTC

      SerialNumber     <Remote's serial number if passed>
                        The remote mailer's serial number if transfered

      Version          <Remote's version number if EMSI>
                        The remote mailer's version number if transfered

      Revision         <remote's revision number if EMSI>
                        The remote mailer's revision number if transfered

      SessionType      <may be EMSI, FTSC0001, WAZOO, JANUS, HYDRA or OTHER>
                        The session-type, this may be one of the known
                        session types or "OTHER" if not (yet) defined

      OurAKA           <AKA which has been called for proper response>
                        If the mailer does AKA matching, the AKA of the
                        mailer being called

      TRANX            <Tranx Line as 8 digit hex string>
                        The unix-style time stamp (hexadecimal notation
                        of seconds since 1.1.1980)

1.3 Undefined options
There may be the need to add new commands / parameters to the SRI file. If
so, they may be added, but inform us to keep the documentation "up to date"
and to share your good ideas with other autors of software for FIDONet.


2.0 Implementation
SRIF is implemented in these fine products already :

               Mailer                  Request Processor
               ------------------------------------------------------
               McMail                  xOR
                                       EasyERP

Other products will follow soon !