If the <request> part of a faqserv URL is present, then receiving a message (or several messages) via netmail is implied. However, most of the auxiliary technical and decorative elements of netmail (i.e. taglines, tearlines, origin lines, greeting lines, signature lines, etc.) SHOULD be stripped from the response text when the netmail is received and the response is extracted from it. It is useful to remember that the response MAY span several messages, and sections of it SHOULD be stripped of all their wrappings before they are finally combined.
If is possible for resources designated by faqserv URLs to appear as elements of complex data structures (e.g. as objects on pages of hypertext). Fidonet browsers SHOULD cache the extracted objects and/or raw netmail response letters to allow immediate rendering of the resources already requested before.
Sometimes the FAQ server station does not respond to the request that is not addressed to a certain name of the service robot. Such a behaviour is especially natural for stations where the same <zone>:<net>/<node>.<point>@<domain> address is shared by both human and automatic addressees, or where several bots exist (e.g. a FAQ robot and an areafixing robot).
In such cases the "bot" optional parameter is appended to the faqserv URL. The value of the "bot" optional parameter specifies the name of the necessary addressee; it MUST be copied verbatim to the corresponding message field of the netmail request.
Future versions of this document may introduce even more optional parameters for faqserv URLs, encouraging somewhat tighter control how the request is sent (e.g. whether the <request> part of the URL is copied to the subject line of netmail or to the message body).
7.4. "fecho://" scheme -+--------------------
Fidonet file echoes are somewhat similar to the echomail areas in the terms of transport and distribution. However, files are broadcast there instead of messages. File echo is a shared base of files that have common areatag (file echo identifier) and are distributed through Fidonet via hierarchical and/or p2p-alike connections between individual Fidonet systems (nodes and points).
The fecho URLs take the form:
fecho://<areatag>/<object-path>?<optional-part>
The character "/" has its literal meaning in the <optional-part> of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (<areatag>/<object-path>), playing the role of delimiter between parts of the path. If an <areatag> contains the character "/" in its literal meaning, the character MUST be encoded.
If the <object-path> part is empty, the fecho URL designates the file echo as a whole.
If the <object-path> of an fecho URL is not empty, then its <object-name> MUST also be non-empty by definition, and it specifies the name of a file that is available as a result of a broadcast though the given file echo.
If an <areatag> corresponds to a file echo which is not available on the system, then the designated resource is not available. The user MAY be asked whether he wants to subscribe to that echo. An FTP mirror of the file echo MAY also be used, if an Internet connection to such a mirror is available.
7.5. "freq://" scheme -+--------------------
It is possible for Fidonet stations to request files directly from each other; there is even a protocol of distributed file requests, proposed in FSC-0071.
The freq URLs take the form:
freq://<server>/<object-path>?<optional-part>
The character "/" has its literal meaning in the <optional-part> of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (<server>/<object-path>), playing the role of delimiter between parts of the path. However, inside the <server> part the character "/" again MUST have its literal meaning and MUST appear once (and only once!) as the delimiter between parts of the server address.
The <server> part of a freq URL MUST be present. The standard Fidonet addressing notation, <zone>:<net>/<node>.<point>@<domain> (see FSP-1004 for details), is used in <server> address. However, some parts of address ("<zone>:", "@<domain>" and/or ".<point>") MAY be omitted (again, see FSP-1004 for details). The <server> part of a freq URL specifies the Fidonet address of the station that will provide the requested file.
If the <object-path> is empty, the freq URL designates the station itself, as a Fidonet system able to provide files by request.
If the <object-path> of a faqserv URL is not empty, then its <object-name> MUST also be non-empty by definition, and it specifies the name of a file that is requested from the remote Fidonet station specified by the <server> part of the URL. The URL designated either the file itself or one of inner part of the file (according to the structure of the <object-path> part of the URL).
If is possible for resources designated by freq URLs to appear as elements of complex data structures (e.g. as objects on pages of hypertext). Fidonet browsers SHOULD cache the requested files when they are received, in order to allow immediate rendering of the resources already requested before.
Future versions of this document may introduce even more optional parameters for freq URLs, encouraging somewhat tighter control how the file is requested. For example, some Fidonet stations MAY deny file requests that are send in a certain inappropriate time of the day, or day of the week; so a parameter or two MAY appear to specify the time and the week day when the file request is relatively safe.
Programs interpreting freq URLs SHOULD NOT be sure whether it is safe to ignore any of the unknown parameters. Some of
Пока!
--- иногда пронзительно свистит на горе рак и свершается страшное (c) Marїnais * Origin: Я отдал голос за народно-патриотический союз ,,Родина`` (2:5063/88)
