Cleanup of HTML code
This commit is contained in:
Michiel Broek
@@ -1,331 +1,332 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Implementation and Usage of FileFind Utilities.</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||
<BODY
|
||||
BGCOLOR="#FFFFFF"
|
||||
TEXT="#000000"
|
||||
LINK="#0000FF"
|
||||
VLINK="#000080"
|
||||
ALINK="#FF0000"
|
||||
>
|
||||
<PRE>
|
||||
Document: fsc-00xx
|
||||
Version: 0.6
|
||||
Date Aug 30, 1995
|
||||
Title: Implementation and Usage of FileFind Utilities
|
||||
Authors: Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
|
||||
|
||||
Intro
|
||||
|
||||
A portion of the document is derived from information in
|
||||
AllFix.DOC by Harald Harms @ 2:281/910
|
||||
with additional sections from
|
||||
FQuery.DOC by Robert Williamson @ 1:167/104
|
||||
|
||||
The MSdos program ALLFIX by Harald Harms first introduced the idea
|
||||
of searching for files via echomail. The term applied to this function
|
||||
is 'FileFind'. A FileFind system allows sysops, points and BBS users
|
||||
to search for files by placing a message to 'ALLFIX' in an echo
|
||||
designated for the purpose of finding files. All FTN sites running a
|
||||
FileFind processor which is configured to scan that echo will reply to
|
||||
that user if there any files matching his query. This system provides
|
||||
a method for searching many FTN sites throughout the world, with a
|
||||
single message.
|
||||
|
||||
FileFind programs work by either scanning through defined message
|
||||
bases or scanning packets for defined AREA tagnames for messages to the
|
||||
default name ALLFIX. All FileFind programs MUST respond to the name
|
||||
ALLFIX, but may also respond to the name FILEFIND and the name of the
|
||||
particular FileFind program in use or defined for the echo. The
|
||||
FileFind program will process these messages, examining the Subject
|
||||
field for search queries. If any valid query is found, the FileFind
|
||||
program will search the sites files database for files matching the
|
||||
users's query.
|
||||
|
||||
If the FileFind program finds any matches, it will generate a reply
|
||||
containing a list of the files found, and some basic information ABOUT
|
||||
the system posting the reply. When the user who initially wrote the
|
||||
request reads the reply, he will then be able to decide if any of the
|
||||
reported files meet his needs, and from the ABOUT included in the
|
||||
reply, learn where and how he may get those files.
|
||||
|
||||
|
||||
FileFind Query Message Structure
|
||||
|
||||
To: name_of_FileFind program
|
||||
|
||||
The message must be addressed to ALLFIX so that all FileFind programs
|
||||
can respond. To use features specific to a particular FileFind
|
||||
program, or to limit the responses to a particular platform, the
|
||||
message should be addressed to that program's name. Some FileFind
|
||||
programs will respond to more than two names.
|
||||
|
||||
Subject:
|
||||
A space-separated list of file specifications, keywords or quoted
|
||||
strings.
|
||||
|
||||
keyword - single word preceeded by a '/' with no intervening spaces,
|
||||
must be at least 3 characters, not including the '/'.
|
||||
a keyword search is in actually a substring search of the
|
||||
site's filelist.
|
||||
|
||||
description - string enclosed in double-quotes,
|
||||
if a single word, must be more than 3 characters.
|
||||
|
||||
filespec - single word, no spaces, no double-quotes or preceding /,
|
||||
must be at least 3 characters, not including any wildcard
|
||||
or pattern matching charcaters, such as '*'.
|
||||
Messages addressed to ALLFIX must not have any embedded
|
||||
pattern matching characters.
|
||||
|
||||
|
||||
The minimum number of characters for description, keyword and
|
||||
filespec queries is an implementation detail of the FileFind program.
|
||||
These values should be configurable, but should never be settable to
|
||||
values of less than 3.
|
||||
|
||||
Each implementation should allow the operator the ability to
|
||||
configure a list of disallowed keywords.
|
||||
|
||||
NetMail Queries
|
||||
|
||||
Some FileFind programs may also have the ability to process file
|
||||
search queries received as netmail and addressed to the name of the
|
||||
particular FileFInd program with this capability. In this case, all
|
||||
replies are via netmail also.
|
||||
|
||||
NetMail Commands
|
||||
FileFind Netmail commands are identifed by a leading '%'.
|
||||
Implementation of netmail commands is optional. If implemented,
|
||||
compliant FileFind utilities should be able to process the following
|
||||
minimum NetMail command set.
|
||||
|
||||
|
||||
%HELP - netmail only, returns an extended help text for the
|
||||
FileFind program, the ABOUT of the the site and a list
|
||||
of MAGIC freqable names.
|
||||
%ABOUT - netmail only, returns the ABOUT of the site and a full
|
||||
or %MAGIC list of MAGIC names.
|
||||
|
||||
%NEWFILES - netmail only, returns the NEWFILES list of the site
|
||||
or %NEW via netmail.
|
||||
|
||||
Extended NetMail Commands:
|
||||
Implementation of the following netmail commands is optional and
|
||||
not required for compliance with the FileFind NetMail Command set.
|
||||
|
||||
%REPORT <tagname>
|
||||
- sends a configuration report for echo <tagname>
|
||||
this allows an echo moderator to check if a site running
|
||||
a FileFind utility is compliant with the rules of the
|
||||
filefind echo.
|
||||
|
||||
%REQUEST <filename>
|
||||
- if found, will place requested file on hold for remote
|
||||
site
|
||||
|
||||
%UUREQUEST <filename>
|
||||
- if found, and the filesize after uuencoding is less
|
||||
than 60K, it will be sent as multiple netmail messages
|
||||
|
||||
|
||||
The Site ABOUT
|
||||
|
||||
Obviously, a system that neither accepts file requests nor allows
|
||||
users to download on their first call should not be responding to
|
||||
FileFind messages. If there are any limitations for the caller to
|
||||
acquire any of the files that the site has advertised as being
|
||||
available in it's FileFind response, these limitations MUST be listed
|
||||
in the reply. This information should be included in the ABOUT file
|
||||
that the FileFind program user creates.
|
||||
|
||||
The site ABOUT should contain the following information. The
|
||||
FileFind program implementor should instruct his users on these
|
||||
requirements.
|
||||
|
||||
- sitename
|
||||
- site operator's name
|
||||
- complete phonenumber
|
||||
- baud rate
|
||||
- hours during which filerequests are accepted, if at all
|
||||
- hours during which users can download
|
||||
- conditions for file requests and user downloads
|
||||
NOTE: the above information should be within the first 14 lines.
|
||||
optional:
|
||||
- a list a MAGIC names
|
||||
- an indication if magic names are also available to terminal users.
|
||||
|
||||
Searching for Files and Creating Replies
|
||||
|
||||
The method used by the FileFind program to search for requests is
|
||||
up to the implementor. However, if searching a list, the FileFind
|
||||
program should confirm the actual existance of all files that match the
|
||||
query specification.
|
||||
|
||||
The FileFind program should only process description strings,
|
||||
filespecs or keywords that contain more than 3 valid characters and
|
||||
should have configuration options to define greater minimum lengths on
|
||||
a per-echo basis.
|
||||
|
||||
For filespecs, the wildcard character '*' IS considered a valid
|
||||
specification as well as the '?' wildcard, but only the '?' is to be
|
||||
counted as a character when determining the length of query. File
|
||||
extensions are not necessary and any characters AFTER a '*' are to be
|
||||
ignored. The FileFind program should be configurable so as to allow
|
||||
replacement all of the file extensions with '.*' or '#?' dependant on
|
||||
platform. This results in queries being independant of the various
|
||||
archivers in use.
|
||||
|
||||
Replies
|
||||
|
||||
Replies created by FileFind utilities are expected to be in
|
||||
compliance with the following FTN specifications:
|
||||
FTS-0001 - packed message format
|
||||
FTS-0009 - MSGID/REPLY
|
||||
FSC-0046 - PID and tear line
|
||||
|
||||
In addition, a FileFind utility may use the FID: control line for
|
||||
any information needed that cannot be put in a PID: without violating
|
||||
that specification.
|
||||
|
||||
^AFID: ascii text CR
|
||||
|
||||
Must be less than 80 characters including ^A and terminating CR.
|
||||
|
||||
There are three ways in which the FileFind program can create replies:
|
||||
- write the replies in the echo in which the query appeared.
|
||||
- write the replies in an echo that has been specifically
|
||||
designated for that purpose in the particular FTN or for
|
||||
a gorup of echos in that FTN.
|
||||
- reply via routed netmail.
|
||||
|
||||
Since each FTN site connected to a particular FileFind program area
|
||||
is capable of creating an information reply, there is much concern as
|
||||
to the amount of traffic that can be generated, FileFind program
|
||||
developers must be sensitive to these concerns by providing the means
|
||||
to their users to limit the traffic on a per-echo basis. For example,
|
||||
various FileFind echos have rules limiting the size or number of
|
||||
replies, or the length of the system information that may be included
|
||||
in a reply.
|
||||
|
||||
Limiting replies
|
||||
|
||||
It is strongly suggested that some default limitations be built-in.
|
||||
|
||||
Limiting Site Header (ABOUT):
|
||||
|
||||
If the site's ABOUT, (the text that has been configured in order to
|
||||
add the system's information and Magic names list to the reply), is
|
||||
greater than 14 lines, the remainder should NOT be posted. A line
|
||||
should be added to the response indicated this, and the user may be
|
||||
invited to either Freq or download the MAGIC name's ABOUT or MAGIC, for
|
||||
a full list of magic names. The FileFind program may optionally send
|
||||
the full system information and magic name list via routed netmail.
|
||||
|
||||
Limiting Match List due to ambiguity of query:
|
||||
|
||||
If the list of matches (note: not the size of the message itself)
|
||||
is greater than 32K, the FileFind program should post a message to the
|
||||
user to indicate that his query may have been too ambiguous and perhaps
|
||||
invite him to freq or download the MAGIC name FILES for a full list.
|
||||
|
||||
Splitting Match List into Multiple Messages:
|
||||
|
||||
If the list of matches is greater than 10K, it should be split into
|
||||
multiple messages of no more than 8K. Although the backbone permits
|
||||
messages up to 16K in length, 8K is a more readable size. Only the
|
||||
first split message may contain the ABOUT information of the site.
|
||||
Each message must be given both a unique Subject field (eg: prepended
|
||||
by "Part n/n") and a unique MSGID:. This because some tossers may use
|
||||
either or both for dupe detection.
|
||||
|
||||
Limiting Number of Split Messages:
|
||||
|
||||
If the number of messages is greater than the preset limit of the
|
||||
echo, and the FileFind Program does not have an option to forward the
|
||||
replies via netmail, the replies should be discarded and the user
|
||||
informed that his request may have been too amibiguous.
|
||||
|
||||
|
||||
NetMail Reply:
|
||||
|
||||
The FileFind program may have an option to forward all replies via
|
||||
routed netmail, or to do so under certain conditions as outlined above.
|
||||
Obviously, if the FileFind program can process netmail queries, it MUST
|
||||
respond via netmail.
|
||||
|
||||
User NetMail Reply Request:
|
||||
|
||||
Alternativly the user can request a netmail reply for his echomail
|
||||
query by preceeding the query with either "%" or "!".
|
||||
eg;
|
||||
Subject: % /fsc /fts
|
||||
|
||||
If the FileFind program does not support this feature, it must
|
||||
ignore any echomail query message that has a "%" or "!" as the first
|
||||
WORD of the Subject field.
|
||||
|
||||
Second Reply or Extended Response Request:
|
||||
|
||||
The FileFind site indicates availablility of Second Reply by
|
||||
placing the string 'program_name 4d_address' in the From: field of the
|
||||
message.
|
||||
eg: FROM: FQUERY 1:167/104.0
|
||||
|
||||
When a user replies to a FileFind reply, the message will be to the
|
||||
FileFind program @ {network address}. When processing the FileFind
|
||||
conferences, the FileFind program will treat any message to itself that
|
||||
includes the site address as a Second Reply Request.
|
||||
|
||||
If this feature is available, the FileFind program will include up
|
||||
to a maximum of 15 files (maximum 12K match list) in it's replies. If
|
||||
the user wants a more detailed listing, he simply replies to the
|
||||
FileFind program's reply. Only the system that posted the original
|
||||
reply will respond to that new request. This second, specific reply,
|
||||
will contain up to 50 files (32K of matchlist) either including or
|
||||
SKIPPING the first 15. These numbers may be replaced by byte limits in
|
||||
some implementations.
|
||||
|
||||
No Second Reply in Designated Reply Echo:
|
||||
|
||||
The Designated Reply Echo method does not allow replies to be made,
|
||||
because the FileFind program may not be permitted to scan a Designated
|
||||
Reply Echo. The FileFind program should automatically report up to 50
|
||||
files for any requests. Therefore, the traffic limitaion features may
|
||||
be disabled for networks that require the FileFind program to reply in
|
||||
a Designated Reply Echo, and disallow Second Reply in that echo.
|
||||
|
||||
Disable Local Messages:
|
||||
|
||||
The FileFind program must be able to to disable the processing of
|
||||
local messages. What this means is that the FileFind program will not
|
||||
process any messages generated on that FTN site, including messages by
|
||||
the sysop using an offline reader, or by a site's BBS or off-line
|
||||
reader users. This should NOT exclude messages from a site's points.
|
||||
|
||||
|
||||
Limit by Age:
|
||||
|
||||
The FileFind program must be configurable so that the operator can
|
||||
limit the age of an query message that is acceptable for processing.
|
||||
This should be in number of days. The FileFind program may be
|
||||
configured to process all the FileFind requests regardless of how old
|
||||
they are. Age should never be greater than 365 days.
|
||||
|
||||
LinkMGR Support:
|
||||
Implmentors may choose to support the LinkMGR proposal for netmail
|
||||
queries and commands. In this proposal, the queries and commands do
|
||||
not appear in the subject field but rather, in the the BODY of the
|
||||
message. The subject field wil contain the LinkMGR password.
|
||||
Use of the LinkMGR method allows the user to send multiple commands
|
||||
to the fIleFind program.
|
||||
</PRE>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
<HTML>
|
||||
<!-- $Id$ -->
|
||||
<HEAD>
|
||||
<TITLE>Implementation and Usage of FileFind Utilities.</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||
<BODY
|
||||
BGCOLOR="#FFFFFF"
|
||||
TEXT="#000000"
|
||||
LINK="#0000FF"
|
||||
VLINK="#000080"
|
||||
ALINK="#FF0000"
|
||||
>
|
||||
<PRE>
|
||||
Document: fsc-00xx
|
||||
Version: 0.6
|
||||
Date Aug 30, 1995
|
||||
Title: Implementation and Usage of FileFind Utilities
|
||||
Authors: Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
|
||||
|
||||
Intro
|
||||
|
||||
A portion of the document is derived from information in
|
||||
AllFix.DOC by Harald Harms @ 2:281/910
|
||||
with additional sections from
|
||||
FQuery.DOC by Robert Williamson @ 1:167/104
|
||||
|
||||
The MSdos program ALLFIX by Harald Harms first introduced the idea
|
||||
of searching for files via echomail. The term applied to this function
|
||||
is 'FileFind'. A FileFind system allows sysops, points and BBS users
|
||||
to search for files by placing a message to 'ALLFIX' in an echo
|
||||
designated for the purpose of finding files. All FTN sites running a
|
||||
FileFind processor which is configured to scan that echo will reply to
|
||||
that user if there any files matching his query. This system provides
|
||||
a method for searching many FTN sites throughout the world, with a
|
||||
single message.
|
||||
|
||||
FileFind programs work by either scanning through defined message
|
||||
bases or scanning packets for defined AREA tagnames for messages to the
|
||||
default name ALLFIX. All FileFind programs MUST respond to the name
|
||||
ALLFIX, but may also respond to the name FILEFIND and the name of the
|
||||
particular FileFind program in use or defined for the echo. The
|
||||
FileFind program will process these messages, examining the Subject
|
||||
field for search queries. If any valid query is found, the FileFind
|
||||
program will search the sites files database for files matching the
|
||||
users's query.
|
||||
|
||||
If the FileFind program finds any matches, it will generate a reply
|
||||
containing a list of the files found, and some basic information ABOUT
|
||||
the system posting the reply. When the user who initially wrote the
|
||||
request reads the reply, he will then be able to decide if any of the
|
||||
reported files meet his needs, and from the ABOUT included in the
|
||||
reply, learn where and how he may get those files.
|
||||
|
||||
|
||||
FileFind Query Message Structure
|
||||
|
||||
To: name_of_FileFind program
|
||||
|
||||
The message must be addressed to ALLFIX so that all FileFind programs
|
||||
can respond. To use features specific to a particular FileFind
|
||||
program, or to limit the responses to a particular platform, the
|
||||
message should be addressed to that program's name. Some FileFind
|
||||
programs will respond to more than two names.
|
||||
|
||||
Subject:
|
||||
A space-separated list of file specifications, keywords or quoted
|
||||
strings.
|
||||
|
||||
keyword - single word preceeded by a '/' with no intervening spaces,
|
||||
must be at least 3 characters, not including the '/'.
|
||||
a keyword search is in actually a substring search of the
|
||||
site's filelist.
|
||||
|
||||
description - string enclosed in double-quotes,
|
||||
if a single word, must be more than 3 characters.
|
||||
|
||||
filespec - single word, no spaces, no double-quotes or preceding /,
|
||||
must be at least 3 characters, not including any wildcard
|
||||
or pattern matching charcaters, such as '*'.
|
||||
Messages addressed to ALLFIX must not have any embedded
|
||||
pattern matching characters.
|
||||
|
||||
|
||||
The minimum number of characters for description, keyword and
|
||||
filespec queries is an implementation detail of the FileFind program.
|
||||
These values should be configurable, but should never be settable to
|
||||
values of less than 3.
|
||||
|
||||
Each implementation should allow the operator the ability to
|
||||
configure a list of disallowed keywords.
|
||||
|
||||
NetMail Queries
|
||||
|
||||
Some FileFind programs may also have the ability to process file
|
||||
search queries received as netmail and addressed to the name of the
|
||||
particular FileFInd program with this capability. In this case, all
|
||||
replies are via netmail also.
|
||||
|
||||
NetMail Commands
|
||||
FileFind Netmail commands are identifed by a leading '%'.
|
||||
Implementation of netmail commands is optional. If implemented,
|
||||
compliant FileFind utilities should be able to process the following
|
||||
minimum NetMail command set.
|
||||
|
||||
|
||||
%HELP - netmail only, returns an extended help text for the
|
||||
FileFind program, the ABOUT of the the site and a list
|
||||
of MAGIC freqable names.
|
||||
%ABOUT - netmail only, returns the ABOUT of the site and a full
|
||||
or %MAGIC list of MAGIC names.
|
||||
|
||||
%NEWFILES - netmail only, returns the NEWFILES list of the site
|
||||
or %NEW via netmail.
|
||||
|
||||
Extended NetMail Commands:
|
||||
Implementation of the following netmail commands is optional and
|
||||
not required for compliance with the FileFind NetMail Command set.
|
||||
|
||||
%REPORT <tagname>
|
||||
- sends a configuration report for echo <tagname>
|
||||
this allows an echo moderator to check if a site running
|
||||
a FileFind utility is compliant with the rules of the
|
||||
filefind echo.
|
||||
|
||||
%REQUEST <filename>
|
||||
- if found, will place requested file on hold for remote
|
||||
site
|
||||
|
||||
%UUREQUEST <filename>
|
||||
- if found, and the filesize after uuencoding is less
|
||||
than 60K, it will be sent as multiple netmail messages
|
||||
|
||||
|
||||
The Site ABOUT
|
||||
|
||||
Obviously, a system that neither accepts file requests nor allows
|
||||
users to download on their first call should not be responding to
|
||||
FileFind messages. If there are any limitations for the caller to
|
||||
acquire any of the files that the site has advertised as being
|
||||
available in it's FileFind response, these limitations MUST be listed
|
||||
in the reply. This information should be included in the ABOUT file
|
||||
that the FileFind program user creates.
|
||||
|
||||
The site ABOUT should contain the following information. The
|
||||
FileFind program implementor should instruct his users on these
|
||||
requirements.
|
||||
|
||||
- sitename
|
||||
- site operator's name
|
||||
- complete phonenumber
|
||||
- baud rate
|
||||
- hours during which filerequests are accepted, if at all
|
||||
- hours during which users can download
|
||||
- conditions for file requests and user downloads
|
||||
NOTE: the above information should be within the first 14 lines.
|
||||
optional:
|
||||
- a list a MAGIC names
|
||||
- an indication if magic names are also available to terminal users.
|
||||
|
||||
Searching for Files and Creating Replies
|
||||
|
||||
The method used by the FileFind program to search for requests is
|
||||
up to the implementor. However, if searching a list, the FileFind
|
||||
program should confirm the actual existance of all files that match the
|
||||
query specification.
|
||||
|
||||
The FileFind program should only process description strings,
|
||||
filespecs or keywords that contain more than 3 valid characters and
|
||||
should have configuration options to define greater minimum lengths on
|
||||
a per-echo basis.
|
||||
|
||||
For filespecs, the wildcard character '*' IS considered a valid
|
||||
specification as well as the '?' wildcard, but only the '?' is to be
|
||||
counted as a character when determining the length of query. File
|
||||
extensions are not necessary and any characters AFTER a '*' are to be
|
||||
ignored. The FileFind program should be configurable so as to allow
|
||||
replacement all of the file extensions with '.*' or '#?' dependant on
|
||||
platform. This results in queries being independant of the various
|
||||
archivers in use.
|
||||
|
||||
Replies
|
||||
|
||||
Replies created by FileFind utilities are expected to be in
|
||||
compliance with the following FTN specifications:
|
||||
FTS-0001 - packed message format
|
||||
FTS-0009 - MSGID/REPLY
|
||||
FSC-0046 - PID and tear line
|
||||
|
||||
In addition, a FileFind utility may use the FID: control line for
|
||||
any information needed that cannot be put in a PID: without violating
|
||||
that specification.
|
||||
|
||||
^AFID: ascii text CR
|
||||
|
||||
Must be less than 80 characters including ^A and terminating CR.
|
||||
|
||||
There are three ways in which the FileFind program can create replies:
|
||||
- write the replies in the echo in which the query appeared.
|
||||
- write the replies in an echo that has been specifically
|
||||
designated for that purpose in the particular FTN or for
|
||||
a gorup of echos in that FTN.
|
||||
- reply via routed netmail.
|
||||
|
||||
Since each FTN site connected to a particular FileFind program area
|
||||
is capable of creating an information reply, there is much concern as
|
||||
to the amount of traffic that can be generated, FileFind program
|
||||
developers must be sensitive to these concerns by providing the means
|
||||
to their users to limit the traffic on a per-echo basis. For example,
|
||||
various FileFind echos have rules limiting the size or number of
|
||||
replies, or the length of the system information that may be included
|
||||
in a reply.
|
||||
|
||||
Limiting replies
|
||||
|
||||
It is strongly suggested that some default limitations be built-in.
|
||||
|
||||
Limiting Site Header (ABOUT):
|
||||
|
||||
If the site's ABOUT, (the text that has been configured in order to
|
||||
add the system's information and Magic names list to the reply), is
|
||||
greater than 14 lines, the remainder should NOT be posted. A line
|
||||
should be added to the response indicated this, and the user may be
|
||||
invited to either Freq or download the MAGIC name's ABOUT or MAGIC, for
|
||||
a full list of magic names. The FileFind program may optionally send
|
||||
the full system information and magic name list via routed netmail.
|
||||
|
||||
Limiting Match List due to ambiguity of query:
|
||||
|
||||
If the list of matches (note: not the size of the message itself)
|
||||
is greater than 32K, the FileFind program should post a message to the
|
||||
user to indicate that his query may have been too ambiguous and perhaps
|
||||
invite him to freq or download the MAGIC name FILES for a full list.
|
||||
|
||||
Splitting Match List into Multiple Messages:
|
||||
|
||||
If the list of matches is greater than 10K, it should be split into
|
||||
multiple messages of no more than 8K. Although the backbone permits
|
||||
messages up to 16K in length, 8K is a more readable size. Only the
|
||||
first split message may contain the ABOUT information of the site.
|
||||
Each message must be given both a unique Subject field (eg: prepended
|
||||
by "Part n/n") and a unique MSGID:. This because some tossers may use
|
||||
either or both for dupe detection.
|
||||
|
||||
Limiting Number of Split Messages:
|
||||
|
||||
If the number of messages is greater than the preset limit of the
|
||||
echo, and the FileFind Program does not have an option to forward the
|
||||
replies via netmail, the replies should be discarded and the user
|
||||
informed that his request may have been too amibiguous.
|
||||
|
||||
|
||||
NetMail Reply:
|
||||
|
||||
The FileFind program may have an option to forward all replies via
|
||||
routed netmail, or to do so under certain conditions as outlined above.
|
||||
Obviously, if the FileFind program can process netmail queries, it MUST
|
||||
respond via netmail.
|
||||
|
||||
User NetMail Reply Request:
|
||||
|
||||
Alternativly the user can request a netmail reply for his echomail
|
||||
query by preceeding the query with either "%" or "!".
|
||||
eg;
|
||||
Subject: % /fsc /fts
|
||||
|
||||
If the FileFind program does not support this feature, it must
|
||||
ignore any echomail query message that has a "%" or "!" as the first
|
||||
WORD of the Subject field.
|
||||
|
||||
Second Reply or Extended Response Request:
|
||||
|
||||
The FileFind site indicates availablility of Second Reply by
|
||||
placing the string 'program_name 4d_address' in the From: field of the
|
||||
message.
|
||||
eg: FROM: FQUERY 1:167/104.0
|
||||
|
||||
When a user replies to a FileFind reply, the message will be to the
|
||||
FileFind program @ {network address}. When processing the FileFind
|
||||
conferences, the FileFind program will treat any message to itself that
|
||||
includes the site address as a Second Reply Request.
|
||||
|
||||
If this feature is available, the FileFind program will include up
|
||||
to a maximum of 15 files (maximum 12K match list) in it's replies. If
|
||||
the user wants a more detailed listing, he simply replies to the
|
||||
FileFind program's reply. Only the system that posted the original
|
||||
reply will respond to that new request. This second, specific reply,
|
||||
will contain up to 50 files (32K of matchlist) either including or
|
||||
SKIPPING the first 15. These numbers may be replaced by byte limits in
|
||||
some implementations.
|
||||
|
||||
No Second Reply in Designated Reply Echo:
|
||||
|
||||
The Designated Reply Echo method does not allow replies to be made,
|
||||
because the FileFind program may not be permitted to scan a Designated
|
||||
Reply Echo. The FileFind program should automatically report up to 50
|
||||
files for any requests. Therefore, the traffic limitaion features may
|
||||
be disabled for networks that require the FileFind program to reply in
|
||||
a Designated Reply Echo, and disallow Second Reply in that echo.
|
||||
|
||||
Disable Local Messages:
|
||||
|
||||
The FileFind program must be able to to disable the processing of
|
||||
local messages. What this means is that the FileFind program will not
|
||||
process any messages generated on that FTN site, including messages by
|
||||
the sysop using an offline reader, or by a site's BBS or off-line
|
||||
reader users. This should NOT exclude messages from a site's points.
|
||||
|
||||
|
||||
Limit by Age:
|
||||
|
||||
The FileFind program must be configurable so that the operator can
|
||||
limit the age of an query message that is acceptable for processing.
|
||||
This should be in number of days. The FileFind program may be
|
||||
configured to process all the FileFind requests regardless of how old
|
||||
they are. Age should never be greater than 365 days.
|
||||
|
||||
LinkMGR Support:
|
||||
Implmentors may choose to support the LinkMGR proposal for netmail
|
||||
queries and commands. In this proposal, the queries and commands do
|
||||
not appear in the subject field but rather, in the the BODY of the
|
||||
message. The subject field wil contain the LinkMGR password.
|
||||
Use of the LinkMGR method allows the user to send multiple commands
|
||||
to the fIleFind program.
|
||||
</PRE>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user