Text 1059, 318 rader
Skriven 2007-10-14 00:42:52 av Mithgol the Webmaster (2:5063/88)
Ärende: [10/11] FidoURL.txt
===========================
* originally in FTSC_Public
* also sent to GanjaNet.Local
* also sent to Ru.Fido.WWW
* also sent to Ru.FTN.Develop
* also sent to SU.FidoTech
* also sent to 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.
7.2.4.1. Optional parameter "kl"
-+------------------------------
This subsection is normative.
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.
Examples:
encoded: ...&kl=/%5ep/i
regex: /^p/i
matches: PATH: 5030/1543 966 5020/4441 5080/1003 5020/830
matches: PID: GED+W32 1.1.5-b20060515
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 faqserv URLs take the form:
faqserv://<server>/<request>/<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>/<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.
Examples:
faqserv://2:5043/17.100@fidonet/
faqserv://2:5054/80.999
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).
Examples:
faqserv://2:5054/83/ELINE/blath/Feainnewedd (an object)
faqserv://2:5054/83/TNT (<object-path> is empty)
faqserv://2:5054/83/TNT_FAQ/ (<object-path> is 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.
7.3.1. Optional parameter "bot"
-+-----------------------------
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.
7.3.2. Future optional parameters
-+-------------------------------
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.
Examples:
fecho://aftnbinkd
fecho://XOFCELIST/
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.
Examples:
fecho://aftnmisc/HATCHDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/
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)
|