= Сообщение: 2492 из 3030 =================================== GANJANET.LOCAL = От : Mithgol the Webmaster 2:5063/88 14 Oct 07 00:41:20 Кому : All 14 Oct 07 00:41:20 Тема : [10/11] FidoURL.txt FGHI : area://GANJANET.LOCAL?msgid=2:5063/88+47112e0c На : area://GANJANET.LOCAL?msgid=2:5063/88+47112dad = Кодировка сообщения определена как: CP866 ================================== ============================================================================== * изначально написано в эхоконференцию FTSC_Public * также было отослано в эхоконференцию GanjaNet.Local * также было отослано в эхоконференцию Ru.Fido.WWW * также было отослано в эхоконференцию Ru.FTN.Develop * также было отослано в эхоконференцию SU.FidoTech * также было отослано в эхоконференцию Titanic.Best
textsection 10 of 11 of file FidoURL.txt textbegin.section
7.2.4. Controlling the visibility of kludges and hidden lines -+-----------------------------------------------------------
This section is informative. Its subsection is normative.
Kludges (also known as klugde lines or as control paragraphs) are special lines embedded in the text body of a Fidonet message. Sometimes kludges are used to support new addressing and other control information, sometimes they contain pieces of auxiliary information about the message's author (location, ICQ UIN, Jabber ID, real name, current music, current mood, etc.) See technical details in FTS-4000.
It is said in FTS-4000 that the contents of kludges are intended for the programs processing the message (or the copies of the message) and not for presentation on the user interface level.
Fidonet messages usually contain some other special lines of the same nature, intended for the programs processing the message, and usually hidden from the user. However, that hidden lines do not start from SOH (Ctrl+A, ASCII 1) symbol, and thus are not kludges. Seen-by stamps, for example, are hidden lines.
Users are generally able to specify (in user settings or just by hotkeys) which kludges and hidden lines are hidden and which are visible in their Fidonet browsers. For example, moderators use hidden lines to control the expansion of their echoes. Many of the non-standard kludges (e.g. location, ICQ UIN, Jabber ID, real name, current music, current mood, etc.) are intended to be read by humans, but are designed as kludges so that thay can be easily hidden by readers annoyed by excessive headers.
If an author of some "area://" URL feels that some kludge and/or some hidden line of the designated message(s) contains relevant information, then the author MAY append an optional parameter to that URL, in order to overcome the user settings and to show the desired kludge or hidden line.
The value of the "kl" optional parameter contains a regular expression; if the rest of the URL designates message(s), then the Fidonet browser, when it shows the body (bodies) of that message(s) to its user, SHOULD NOT hide any of kludges or hidden lines that match the given expression.
See section 7.2.3 for the details about regular expressions.
When testing whether a kludge matches a regular expression, the SOH (Ctrl+A, ASCII 1) symbol MUST be omitted. For example, /^[PT]ID/ expression MUST match both "PID" and "TID" kludges, though there is SOH between the line beginning (^) and the first symbol of the kludge ([PT]) in both of the kludges.
Consequently, "kl=" regular expressions differ with "find=" regular expressions for kludges (see subsection 7.2.1.4), and "kl=" expressions are shorter.
Note: It is not necessary for a "kl=" expression to contain "/m" flag, because the "^" construct already matches at the beginning of each kludge.
encoded: ...&kl=/path/i regex: /path/i matches: PATH: 5030/1543 966 5020/4441 5080/1003 5020/830 matches: Now playing: Children of Dune - The Golden Path
encoded: ...&kl=/.*/ regex: /.*/ what it means: The browser SHOULD show all of the kludges and hidden lines of the message(s).
7.3. "faqserv://" scheme -+----------------------
FAQ servers are Fidonet stations that accept special requests containing file names (or aliases) of certain texts. Such requests are sent via Fidonet netmail. The FAQ server processes the request and sends the requested text to the sender of request; the text is sent via Fidonet netmail in a single letter (as a whole) or in several letters (in sections).
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>/<request>/<object-path>), playing the role of delimiter between parts of the path. However, inside <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 faqserv 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 faqserv URL specifies the Fidonet address of the station (the FAQ server) which is implied to be queried.
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 an object embedded in the netmail text of the response sent by that FAQ server. Either that object or some of its inner parts, according to <object-path>, is designated.
However, the netmail response messages MAY contain more than one object of the same name. In this case the designated object is the latest one among only those which are known how to decode them. See section 7.2.2.2 for the details of what object is considered the latest.
The <request> part of a faqserv URL, if present, MUST NOT be empty.
If the <request> part of a faqserv URL is not present at all, then the <object-path> MUST also be empty and "<request>/<object-path>" MUST be omitted entirely, and the preceding "/" character MAY also be omitted. In this case the faqserv URL designates the FAQ server itself, as a Fidonet system. Such an URL MAY designate an action and not a resource; for example, it MAY designate adding the given FAQ server to some list or to a database of FAQ servers.
However, such an action MUST NOT imply sending any requests to the designated server. Different FAQ servers use different names of the default request; it can be 'FILES', 'LIST', 'INDEX', 'HELP' or any other name. That's why a Uniform Resource Locator MUST NOT expect the URL processor to have any extra knowledge besides the data given in the URL itself. If a request is needed, than the corresponding part of a faqserv URL MUST be present and not empty, containing the request (see details below).
If the <request> part of a faqserv URL is present, it contains the request to be sent to the given server. The URL designates either the response as a whole (if the <object-path> is empty), or just an object inside the response (if the <object-path> is not empty).
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.
An <areatag> MAY contain "@domain" suffix (see section 5.2.2.3.1).
If the <object-path> part is empty, the fecho URL designates the file echo as a whole.
If the <object-path> of a 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.
Future versions of this document MAY introduce some optional parameters for "fecho://" URLs, but Fidonet software MAY safely ignore any unknown parameters in "fecho://" URLs.
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.
textend.section
With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 182. I won't hold any sort of public celebration within my castle walls. --- Something is rotten in the state of Denmark. (Shakespeare, Hamlet, I, IV) * Origin: And the Soviets ── waist-deep in the snow ── marched in (2:5063/88)
