1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Information / Description of a new standard
S tandard
R equest
I nformation
F ile
Copyright (c) 1994,95,96 by Gordian Schuermann & Mirko Mucko
Current revision 1.02, dated of June 02 1996
The latest revision of this document is avail
for file request with magic "SRIF"
I Overview
Introduction 0
Contact person 0.1
Description in general 1
Required statements 1.1
Optional statements 1.2
Undefined options 1.3
Implementation 2.0
Updates to this revision 3.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
0.1 Contact persons
In case of trouble understanding SRIF, the concept, meaning ot purpose
of ot, or even have questions concerning the implementation, or if you
have bug fixes or any other note for us, you may reach us at:
Mirko Mucko
e-mail fidonet 2:2433/920.0
internet mirko.mucko@technet.net
FAX +49-211-9083026
snail Mirko Mucko
Thomas-Mann-Str. 43
40470 Duesseldorf
GERMANY
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
CallerID <Phone Number>
The phone number as delivered by the PTT. This is
only possible in digital networks like ISDN.
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 SRIF 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
Xenia EasyERP
TMail [*]
[*] means : SRIF is not completely correct implemented and therefor
may cause troubles in operation
Other products will follow soon ! If YOUR product also supports SRIF,
just drop us a mail and we will include it here.
3.0 Updates to this revision
To revision 1.02, we added the "CallerID" field within optional parameters
to make Request Reject possible depending on the delivered phone number.
This is only possible in ISDN and similar networks and must be supported
by the mailer AND the fossil.
Also, section 0.1 (contact person) has been added.
|
