= Сообщение: 37988 из 47123 =============================== RU.FIDONET.TODAY = От : Dmitriy Orlov 2:5090/958 09 Oct 23 14:26:24 Кому : Stas Mishchenkov 09 Oct 23 14:26:24 Тема : Фреки по-роутингу FGHI : area://RU.FIDONET.TODAY?msgid=2:5090/958+65240dc6 На : area://RU.FIDONET.TODAY?msgid=2:460/5858+65239d0c = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hello Stas!
09 Oct 23, Stas Mishchenkov wrote to Nil A:
SM> Это по тому, что оно не должно так работать. Фрек - штука директная by SM> design.
Если уж на то пошло, SRIF штука директная, а не флаг frq в письме:
15. FSC-0086 Information / Description of a new standart SRIF: Standart Request Information File Gordian Schuermann & Mirko Mucko, 2:2433/920 Version 001, Septemder 3, 1995
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!
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 :
