= Сообщение: 3590 из 7125 ====================================== FTSC_PUBLIC = От : Markus Reschke 2:240/1661 15 Feb 18 20:08:38 Кому : All 15 Feb 18 20:08:38 Тема : review of FSP-1040 FGHI : area://FTSC_PUBLIC?msgid=2:240/1661+5a7726b1 = Кодировка сообщения определена как: LATIN1 ================================= Ответ: area://FTSC_PUBLIC?msgid=2:280/464+5a85f37c ============================================================================== Hi!
This is meant to be an experiment about public feedback for a new FSP. The idea is to ask you for help on reviewing the FSP regarding grammar/spelling errors and technical details we might have missed or got wrong. It's not about discussing why something is defined this way and not that way, and other similar things. I don't know if you have experience with collaborating on documents. If you have you know it becomes more complex as more people are involved. So please focus on the main task.
Publication: FSP-1040 Revision: 1 Title: SRIF file request interface Authors: Markus Reschke, FTSC members Date: 2017-12-13 ----------------------------------------------------------------------
Contents -------- 1. Definitions 2. SRIF 2.1 Introduction 2.2 Description 2.3 SRIF Format 2.4 Required Keywords 2.5 Optional Keywords A. References B. History ----------------------------------------------------------------------
Status of this document -----------------------
This document is a Fidonet Standard Proposal (FSP) - it specifies the current technical requirements and recommendations for FTN software developers, coordinators and sysops of the Fidonet network and other networks using FTN technology.
This document is released to the public domain, and may be used, copied or modified for any purpose whatever.
1. Definitions --------------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [FTA-1006].
Filepath: The complete filepath of a file, i.e. path and file name.
Text file: A file containing text characters. Since all keywords are based on the ASCII character encoding the format is assumed to be compatible with most other character encodings.
2. SRIF -------
2.1 Introduction ----------------
SRIF (Standard Request Information File) was developed to be a standard interface to run external file request processors by mailers. A standard interface provides more operational flexibility for sysops. For example, a system can run different mailers for Internet and POTS lines while using the same file request processor.
Originally SRIF was defined in FSC-0086. But that document is protected by copyright and can't be simply amended by the FTSC. Also it lacks some technical details, and new keywords were introduced meanwhile. This new document intends to fix the shortcomings.
2.2 Description ---------------
The SRIF is a simple text file created by the mailer after receiving an file request, and contains information for the file request processor. It includes the filepath of the file request (.REQ file) and the filepath of a response file besides other information. The file request processor reads the SRIF, processes the file request, and writes a list of files found to the response file. After the file request processor has finished the mailer reads the response file and sends the files listed.
The SRIF process in more detail:
When the mailer receives a .REQ file request from a calling system it performs following tasks: - creates a unique response file - creates a unique SRIF - writes all required data to the SRIF, also optional data - executes the file request processor with the SRIF's filepath as command line parameter, and waits until the file request processor has finished - processes the response file and sends the files found - deletes the SRIF and the response file
The file request processor performs following tasks when executed: - gets the SRIF's filepath from the command line - reads its own configuration - reads the SRIF - reads and processes the file request file, and writes files found to the response file - may create user feedback, e.g. a netmail packet, and add that to the the response file too hint: feedback has be a unique file also
The files created need to be unique to support a multi line or multitasking system. It's up to the software developer to implement a method ensuring unique files. Some operating systems offer library functions for that purpose. If you use one of those, select a safe function which minimizes the risk of race conditions.
2.3 SRIF Format ---------------
As already mentioned, the SRIF is a simple text file containing information for the file request processor. Each line consists of a keyword-value pair. The line termination isn't specified, so it could be CR (Carriage Return, ASCII 0x0D), LF (Line Feed, ASCII 0x0A) or CR-LF. The file request processor should support all three variations. Empty lines should be avoided by the mailer, but tolerated by the file request processor. The syntax for each line is:
<keyword><space><value or string>
Space is ASCII 0x20. A string can include spaces, for example 'sysop name'.
Keywords are divided into two groups, i.e. required and optional keywords. Required keywords must be given by the mailer, and optional keywords may be given. Each keyword must not be used more than one time, unless stated otherwise in the keyword's description. Keywords must not contain any whitespace characters.
The order of the keywords in the SRIF isn't defined. Therefore the file request processor must be able to accept any order. It should also ignore unknown and unsupported keywords.
2.4 Required Keywords ---------------------
The SRIF must include the following keywords:
Sysop
Name of the calling sysop.
Syntax: Sysop <sysop name> Example: Sysop Jane Doe
AKA
FTS address of calling system. This keyword can be repeated multiple times to list all AKAs given by the remote system (one per keyword).
Data transfer rate of connection in bps. For IP based connections the transfer rate is usually stated as 115200.
Syntax: Baud <line rate> Example: Baud 14400
Time
Time limit for file request. This can be also used to indicate the time left until some scheduled task would block file request processing. If there aren't any time constraints the time limit is stated as -1.
Syntax: Time <minutes> Example: Time -1
RequestList
Filepath of the list containing the requested files. This is the .REQ file sent by the calling system. The mailer should make sure that the filepath is unique to prevent any problems in a multi line environment.
The syntax of the list should follow FTS-0006. A brief refresher: Each line lists one filename or search pattern, and can include an optional password. Lines end with a CR (Carriage Return, ASCII 0x0D).
Line syntax: <filename or pattern>[<space>!<password>]
There is no specification of search pattern and wildcard characters, which must be supported. Most file request processors support simple wildcard characters like '*' for search pattern, e.g. <name>.*. Some also process more sophisticated search expressions.
For interoperability reasons the file request processor should also accept lines ending with LF (Line Feed, ASCII 0x0A) or CR-LF.
ResponseList
Filepath of the list containing the files to be sent as response to the file request. The mailer should make sure that the filepath is unique to prevent any problems in a multi line environment.
The response list states all the files to be sent using following syntax:
Line syntax: <mode><filepath>
Each line lists exactly one filepath preceded by a mode identifier. The line end is not specified, and could be CR Carriage Return, ASCII 0x0D), LF (Line Feed, ASCII 0x0A) or CR-LF. Therefore the file request processor should use the OS specific line termination. For interoperability reasons the mailer should support all line end variations.
The mode identifier is a single character defining how a file has to be processed by the mailer:
= send file, and erase it after successful transmission + send file - send file, and erase it afterwards in any case
Typically, files are marked with '+', since they shouldn't be deleted in the system's file base. If the file request processor creates a netmail packet or simple text message for feedback additionally, those files could be marked with a "=" to have them deleted automatically after transmission.
RemoteStatus
The remote status indicates if the session with the calling system is protected or unprotected, i.e. secured by a session password.
The session protocol used in the current session with the calling system. Protocols are EMSI, FTSC0001, WAZOO, JANUS, HYDRA or the special case OTHER, if none of the protocols listed before is used.
The transfer protocol used in the current session with the calling system, e.g. ZAP, ZMO or XMA.
This keyword includes a spelling error and is defined this way in FSC-0086 unfortunately. We recommend that the file request processor should support the bad and the correct spelling.
Product code of the calling system's mailer. The code is in hexadecimal format (lower or upper case) and can be an 8 bit (old code format) or a 16 bit (new code format) value.
Syntax: MailerCode <id> Example: MailerCode 66
SerialNumber
Serial number of calling system's mailer. The common format is:
Tranx, i.e. local time of calling system. The time is encoded as Unix time stamp (32 bit, seconds since 1970-01-01 00:00:00 UTC) and formatted as hexadecimal string with 8 digits. The hexadecimal digits can be in lower or upper case.
The 32 bit time stamp will overflow in 2038. We haven't seen any implemented solutions for that yet, so we recommend to support also a 64 bit time stamp (string with 16 hex digits) while allowing leading zeros to be omitted.
