******************************************************************************

               STANDARD-REQUEST-MACROS FOR REQUEST-PROCESSORS      (SRM/RP)
                 (C) 1993-95 by Kai-Jens Meyer (2:2476/222)
                      & Stefan Briesenick (2:2476/223)
                  Translation by Gerd Troeger (2:249/1110)

******************************************************************************

                         -= Dated 25.Feb.1995 =-

Preface:
~~~~~~~
In future, request-macros should become a powerful tool for the requester,
to give additional parameters comfortably to the host-system.

This document was written to create a common standard, to avoid different
creations by any programmer of a request-processor (shortened "RP"), which
will certainly result in a chaos and force the requester first to investi-
gate, which RP the sysop is using, before he can use it, instead of having
the same conditions everywhere.

Our EasyERP was the first RP using such request-macros. Because they are
used successfully since August '93, we take the freedom to fix them as a
standard for future. We named them SRM/RP (Standard Request-Macros for
Request Processors). We call upon every programmer of another RP to join
this new standard. We cannot force anybody to do so, but think about the
advantages of a common standard!

To make our "Look & Feel" even more public, we ask you to take the
following lines into your documentation, etc.:

   Ŀ
    Requestmacros (%TIC, %BBS, etc.) SRM/RP Standard defined by: 
    Kai-Jens Meyer (2:2476/222) & Stefan Briesenick (2:2476/223) 
   

In the following part are all the request-macros listed. A request-macro
is send like a alias/magic to the system and always starts with a '%'-sign.
The evaluation of the requests are to be made like in the descriptions
below. Because of there use like pseudo-aliases they are downward-
compatible to RPs without SRM/RP; maximum what can happen is a "File not
found"...


 %TIC 

 For the files requested after this macro in this session the user will
 recieve a TIC-file. If the RP has a userbase, this macro will not change
 anything in the userprofile!


 %AREA<name>  or  %AREA=<name> 

 For the with %TIC requested TIC-files the filearea is set to <name>.
 Normally it will be saved to the userprofile and, if it is saved, it has
 to be taken as the default for any following requests. If %AREA is used
 without any <name> the entry in the userprofile is deleted and therefor
 the default-value, which should be definable by the sysop, is used.
 The maximum length of <name> is 16 characters.


 %PWD<pw>  or  %PWD=<pw> 

 Defines the password used in the TIC-files. It should be saved in the
 userprofile, too. If the user asked for TICs, but did not set the
 password, a random key must be generated. If %PWD is used without a
 password, the record in the userprofile must be deleted and a random
 key must be used (as above). The password has a maximum length of
 16 characters.


 %UPD<name>  or  %UPD=<name> 

 Some filetossers (i.e. AllFix) allow a keyword in the TIC-files, which
 allows the user to keep his alias files up-to-date. This keyword is
 'Magic' and includes the aliasname, which should be updated. This macro
 must be used before each single file. It is not saved or noticed somewhere
 at all. If this macro is not send, the 'Magic'-kludge must not be send, too.


 %REP<name>  or  %REP=<name> 

 This macro defines the 'Replaces'-kludge in the TIC-file. Same conditions
 as for the %UPD macro. This macro must be used before each single file!


 %FAKE<aka>  or  %FAKE=<aka> 

 Defines a fake-aka to be used in the TIC-files. Normally, the real system-
 address of the RP-system is used in the TICs. If the requester does not
 want to add an entry in his filetosser for every system, he could set
 the same (fake-)aka to be used by all the systems. This aka must be used
 only in the 'From'- and 'Origin'-kludges of the TIC-file, the SEEN-BYs must
 contain the real akas! The fake-aka should be saved in the userbase. Because
 many mailers have problems to handle the aka in the 3D- or 4D-format, the
 following alternative notations should be possible:

   <zone>-<net>-<node>  or  <zone>-<net>-<node>-<point>
   <zone>_<net>_<node>  or  <zone>_<net>_<node>_<point>

 Examples:  2:2476/223    -  2-2476-223     -  2_2476_223
            2:2476/222.5  -  2-2476-222-5   -  2_2476_222_5

 If %FAKE is used without <aka>, the earlier defined fake-aka is deleted
 and the real system-aka is used in the TIC-files.


 %NOTIC 

 Disables sending of TIC-files for the later this session requested files.
 This one does not change the userprofile, it is only for this session.


 %TIC_ON  %TIC_OFF 

 These two work like %TIC and %NOTIC, but they do change the userprofile.
 %TIC_ON works like %TIC in this session, and as if %TIC is requested in
 all following sessions as the first files/magic. To make this posssible,
 it should be saved in the userprofile. %TIC_OFF works like %NOTIC and
 also as the default for any later requests.
 The next macros have the same structure and must be implemented equally,
 of cause matching the actual function. So %??? and %NO??? concern only
 this session, while %???_ON and %???_OFF additionally change the profile.


 %CRC  %NOCRC  %CRC_ON  %CRC_OFF 

 Because the creation of the CRC32 for the TIC-files can take a while and
 many filetossers can handle TIC-files without the 'CRC'-kludge, the user
 can set with this macro whether he wants CRCs or not. Used like the
 %TIC-macros.


 %LD  %NOLD  %LD_ON  %LD_OFF 

 Newer filetossers allow long descriptions to be stored in 'LDESC'-lines.
 With these macros the user can enable or disable them in the TIC-files.


 %BBS  %NOBBS  %BBS_ON  %BBS_OFF 

 Work like the %TIC-variants, but for FILES.BBS- instead of TIC-files. The
 *.BBS are ascii-files, compatible to FILES.BBS, and include all the files
 with their descriptions requested after %BBS.


 %DLC<cnt>  or  %DLC=<cnt> 

 Configure the download-counters in the FILES.BBS. Example: %DLC=[00] will
 set the download-counter to [00]. If set, it must be inserted by the RP
 into each first description line in the FILES.BBS. Should be saved in the
 userbase as default.


 %BTM  %NOBTM  %BTM_ON  %BTM_OFF 

 Special feature for 4DOS-, 4OS2- etc. users. It will send a *.BTM (4DOS-
 batch), which includes a DESCRIBE-statement for each file. Read the 4DOS-
 documentation for details on 'DESCRIBE'. Anything else like in the %TIC-
 equivalents.


 %HOLD  %NOHOLD  %HOLD_ON  %HOLD_OFF 

 Again, these macros are used like the %TIC-macros. The configure, whether
 the files are put on Hold so the user can pickup them later instead of
 recieving them in the same session as requested. Because this function is
 a bit more complex, it is not absolutely necessary to implement it, but
 if, then with these macros!


 %MSG  %NOMSG  %MSG_ON  %MSG_OFF 

 Turn on/off sending of answer-mails. Can accelerate the request. Or the
 user is simply annoyed receiving all the replies... ;-)


 %DUPE_ON  %DUPE_OFF  %NODUPE 

 Some requesters have a few BBS they most likely request on. Then it can
 happen, that files are requested twice. As an example take the filelist,
 when it has not been updated yet. If it is a long distance CONNECT 2400
 this is not so fine. Therefore a user can ask the RP to save all his
 requests in a small, user-related database (via %DUPE_ON). If a file was
 already sent and has still the same name, size and date it won't be sent
 again until turned off forever (via %DUPE_OFF) or explicitely for this
 request (via %NODUPE). Also, the database is deleted with %DUPE_OFF.
 To keep the database in affordable size, the RP can delete old files
 from it.


 %KILL 

 The Germans have a little problem: they overstress the topic data protection
 a bit. Therefore a german RP must have a special function... So when the
 requester does not want his personal data to be saved and maybe processed
 [Ann. by translator: i.e. in request-statistics], he can use this macro.
 Then only a few statistics may be saved to asure the user keeps his limits.
 Afterwards all data about the user must be deleted! [Ann. by translator:
 this means if there is a limit of 1 meg/day, the user-data may be kept
 only this one day.]


 %HELP 

 Provides the requester with help texts about the RP, his functions and,
 of cause, the request-macros. It is not important, how this function is
 implemented (within the reply or in another mail or...).


 %INFO 

 Should send the requester for example his limits and maybe other statistics.
 It is not important, how it is implemented. If the RP has a userbase, with
 this macro the configuration of the user should be sent. It is usefull to
 sent this automatically, if the user has made any changes to his confi-
 guration (via %???_ON/OFF-macros).


 %ABOUT 

 Here the RP may send infos about the BBS, the sysop, system etc. Normally
 the sysop will introduce himself and his system here. The manner of imple-
 mentation is free.


 %MAGIC 

 The RP should send a list of the available aliases (magics). He may
 differenciate between secure/unsecure aliases, but this is not necessary.


 %CD 

 More and more systems use CD-ROM-drives and some have very much CDs
 available. This macro should send the requester a list of the (currently)
 on the system available CDs. How this information is aquired (i.e. through
 the filebase or just an ascii-file) is not important.


 %ERP  %REQ 

 These both macros are so called Dummy-Macros. They have to be ignored
 by the RP! To create (online-) requests, which have the request list not
 in the subject but in the mailbody, with many mailers it is necessary
 to specify at least one 'file' in the subject to recognize the mail as a
 valid requestmail. For that case, you can use one of these Dummy-Macros.




Annotations:
~~~~~~~~~~~
Some conditions must be considered when using the keywords. The macros
%AREA, %FAKE, %PWD, %UPD, %REP and %DLC must be followed by the descriptor
_without_any_ whitespaces between them. They may be separated only by an
equal sign ("="). Whitespaces in the descriptor are not allowed due to
technical reasons at all.

The macros %HELP, %INFO, %ABOUT, %MAGIC and %CD are only as informations
for the requester. Many sysops pack dumb information into their reply mails,
which mostly do not interrest the requester and only cost transfer time.
These macros give the user the chance to decide, which informations he
wants to receive.

If you have good ideas for expansions of the macros send them to us and
we will include them with a comment in this overview so that all interrested
people may keep the overview.

Send any comments/corrections etc. on the translation to Gerd Troeger.

******************************************************************************

Have fun in programming!
    Kai-Jens Meyer & Stefan Briesenick

...and don't forget about your (BASIC :-) ) roots!
    Gerd Troeger

[EOF]
