[2/11] FidoURL.txt
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 2 of 11 of file FidoURL.txt
textbegin.section
5.1. The main parts of URLs
-+-------------------------
In general, Fidonet URLs are written as follows:
<scheme>:<scheme-specific-part>
Any URL contains the name of the scheme being used (<scheme>)
followed by a colon and then a string (the <scheme-specific-part>)
whose interpretation depends on the scheme.
Scheme names consist of a sequence of characters. The lower case
letters "a"--"z", digits, and the characters plus ("+"), period
("."), and hyphen ("-") are allowed. For the sake of resiliency,
programs interpreting Fidonet URLs SHOULD treat upper case letters
in scheme names as equivalent to the corresponding lower case
letters (e.g., allow "AREA" scheme name as well as "area").
Only the first colon of the URL plays the role of delimiter
between <scheme> and <scheme-specific-part>. The scheme-specific
part of any URL MAY contain other colons.
The colon delimiter between <scheme> and <scheme-specific-part>
MAY be immediately followed by an optional double slash ("//").
Fidonet programs interpreting URLs MUST treat the delimiter "://"
as equivalent to the simple colon before <scheme-specific-part>.
5.1.1. Conformance note
-+---------------------
This subsection is informative.
The Fidonet URL schemes defined in this document consist of
lower case letters "a"--"z" only. However, digits, and the
characters plus ("+"), period ("."), and hyphen ("-") MUST also
be allowed in scheme names, so that Internet schemes conforming
with the specifications of RFC 1738 are correctly dealt with.
5.1.2. Delimiter guidelines
-+-------------------------
In current Internet practice they distinguish between delimiters
":" and "://". The delimiter "://" is often used after scheme
names that designate objects and resources ("http://", "ftp://",
"gopher://", "nntp://", "ed2k://", "file://", etc.).
The delimiter ":" is often used after scheme names that
designate actions (e.g. "mailto:", "skype:").
The same difference exists between Fidonet resources (objects)
and actions. That's why, though these delimiters MUST always
be interpreted as equivalent, it is still RECOMMENDED that ":"
SHOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SHOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://", etc.).
5.2. URL character encoding
-+-------------------------
URLs are sequences of characters (i.e., letters, digits, and/or
special characters). URLs may be represented in a variety of ways:
e.g., ink on paper, or a sequence of octets in a coded character
set. The interpretation of URL depends only on the identity of the
characters used.
It is useful to distinguish between a "character" (distinguishable
semantic entity) and an "octet" (an 8-bit byte).
In most URL schemes, the character sequences in different parts
of a URL are used to represent sequences of octets used in Fidonet
services. For example, in the "netmail:" scheme, the Fidonet
address, netmail subject and addressee name are such sequences of
octets, represented by parts of the URL. That sequences of octets,
in turn, represent the original characters (of subject line, or of
sysop's name, etc.); each original character is represented by one
or more octets.
So there are always two mappings, one from URL characters to
octets, and the second from octets to original characters:
URL character sequence<->octet sequence<->original character sequence
5.2.1. Encoding of original characters
-+------------------------------------
The following paragraph is informative.
The sequence of octets defined by a component of the URL
is subsequently used to represent a sequence of original
characters. That process could have a very volatile nature.
Being an international network, Fidonet always needs to deal
with hundreds of national characters, with dozens of available
encoding traditions and character sets. There is a number of
FSC (Fidonet Standard Proposal documents) suggesting several
kludge-based methods to define which character set is used.
However, it is not wise to implement any equivalents to kludges
as a required part of every Fidonet URL; and it could be hard to
mantain complete lists of all possible character sets inside all
programs interpreting Fidonet URLs. (Remember, it should be also
made possible for Fidonet URLs to appear and be well interpreted
in traditional HTML hypertext environment of the Web, Internet
e-mail, instant messaging, etc.) That's why only one encoding,
with large enough character set, has to be chosen.
The following paragraphs of this subsection are normative.
The sequence of octets used in Fidonet URLs MUST always contain
UTF-8 encoded representation of original characters.
ISO/IEC 10646-1 defines a multi-octet character set called the
Universal Character Set (UCS), which encompasses most of the
world's writing systems. And UTF-8, one of a few so-called UCS
transformation formats (UTF), preserves the 7-bit ASCII range,
thus providing some compatibility with file systems, parsers and
other software elements that rely on 7-bit ASCII values but are
transparent to other values.
UTF-8 is defined in RFC 2279. Its description can also be found
in Unicode Technical Report #4 and in the Unicode Standard,
version 2.0.
5.2.2. Encoding of octets
-+-----------------------
The character sequences in different parts of a URL are used
to represent sequences of octets.
It is possible to represent an octet by the chararacter
which has that octet as its code within the pure 7-bit ASCII
character set. However, there are some exceptions (see below).
Alternatively, octets MAY be encoded by a character triplet
consisting of the character "%" followed by the two hexadecimal
digits (from "0123456789ABCDEF") which form the hexadecimal
value of the octet. (The characters "abcdef" MAY also be used in
hexadecimal encodings.)
Hexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. However, it is RECOMMENDED to avoid
unnecessary hexadecimal encoding, thus keeping URLs reasonably
short.
It is either REQIRED or RECOMMENDED to use the hexadecimal
encoding of octets if they have no corresponding graphic
character within the 7-bit ASCII character set, or if the use
of the corresponding character is unsafe, or if the
corresponding character is reserved for some other
interpretation within the particular URL scheme. These
requirements and recommendations are detailed below.
5.2.2.1. No corresponding graphic 7-bit character
-+-----------------------------------------------
URLs are written only with the graphic printable characters
of the 7-bit ASCII coded character set.
The octets 80-FF hexadecimal do not belong to 7-bit ASCII,
and the octets 00-1F and 7F hexadecimal represent control
characters; these octets MUST be encoded.
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 204. I will hire an entire squad of blind guards.
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 3 of 11 of file FidoURL.txt
textbegin.section
5.2.2.2. Unsafe characters
-+------------------------
Characters can be unsafe for a number of reasons.
The space character is unsafe because significant spaces may
disappear and insignificant spaces may be introduced when URLs
are transcribed or typeset or subjected to the treatment of
word-processing programs. The octet 20 hexadecimal MUST always
be encoded.
The characters "<" and ">" are unsafe because they are used
as the delimiters around tags in HTML hypertext and XML data.
The octets 3C and 3E hexadecimal MUST always be encoded.
The quote mark (""") is used to delimit URLs in some systems,
including valid XHTML and XML. The octet 22 hexadecimal
MUST always be encoded.
The character "#" is unsafe because it is used in World Wide
Web and in other systems to delimit a URL from a fragment or
anchor identifier that might follow it.
The octet 23 hexadecimal MUST always be encoded.
The character "%" is unsafe because it is used for encodings
of other characters. The octet 25 hexadecimal MUST always be
encoded.
The character sequence of triple minus ("-" repeated thrice)
has a special meaning in Fidonet and can accidentally start
a tearline in some cases (e.g. when a line is wrapped).
At least one of the three corresponding octets
(2D 2D 2D hexadecimal) MUST be encoded if they follow
each other in a sequence.
Other characters were declared unsafe in RFC 1738 because some
gateways and other transport agents were known to sometimes
modify such characters. These characters are "{", "}", "|",
"\", "^", "~", "[", "]", and "`". The corresponding octets
(7B 7D 7C 5C 5E 7E 5B 5D 60 hexadecimal) MUST always be
encoded for the sake of Internet compatibility.
All unsafe characters MUST always be encoded within a URL.
For example, the character "#" MUST be encoded within URLs
even in software programs that do not normally deal with
fragment or anchor identifiers, so that if the URL is copied
into another program that does use them, it will not be
necessary to change the URL encoding.
5.2.2.3. Reserved characters
-+--------------------------
Many URL schemes reserve certain characters for a special
meaning: appearance of that characters in the scheme-specific
part of the URL (in <scheme-specific-part> after scheme name)
has a designated semantics.
Usually a URL has the same interpretation when an octet is
represented by a character and when it is encoded. However,
this is not true for reserved characters: encoding a character
that is reserved for a particular scheme may cause harm to
the meaning of a URL, if the character is used according
to its designated semantics. And vice versa.
The character "?" is used as the delimiter between required
and optional parts of the URL. The delimiter itself MUST NOT
be encoded. If the character "?" appears in any other part of
a URL, it MUST be encoded, so it won't be confused with the
delimiter.
The character "=" is used as the delimiter between parameter
names and parameter values. The delimiters themselves MUST NOT
be encoded. If the character "=" appears in any other part
of a URL, it MUST be encoded, so it won't be confused with
any of the delimiters.
The character "&" is used as the delimiter between
"parameter=value" pairs. The delimiters themselves MUST NOT
be encoded. If the character "&" appears in any other part
of a URL, it MUST be encoded, so it won't be confused with
any of the delimiters.
The character "/" is scheme-specific:
*) In some schemes ("netmail:", for example) the character "/"
has its own (literal) meaning, as it is widely used
in standard Fidonet addressing notation
<zone>:<net>/<node>.<point> (see FSP-1004 for details).
*) In some other schemes the character "/" is reserved
to be used in the file path
(<directory>/<directory>/...<directory>/<filename>),
and its corresponding octet (2F hexadecimal)
MUST be encoded if it does not delimit parts of the path.
See the scheme-specific details below (in scheme sections).
5.2.2.4. The plus ("+") and the encoding of white spaces
-+------------------------------------------------------
White spaces (octets 20 hexadecimal) are the most common
unsafe characters in Fidonet, and so they play a significant
role in some scheme-specific parts of the URL: they appear in
MSGID kludges, they are used as delimiters between words
in lines of text, etc.
To enhance human readability of Fidonet URLs, and to make them
shorter, a new shorter synonym for "%20" hexadecimal triplet
is available. It is the plus sign ("+").
Programs interpreting scheme-specific part of Fidonet URL
MUST treat the character plus ("+") there as equivalent
to the white space hexadecimal triplet ("%20").
Because of that, the plus character itself is reserved, and
its own corresponding octet (2B hexadecimal) MUST be encoded
if it appears in scheme-specific part of Fidonet URL.
5.2.2.4.1. Specificity note
-+-------------------------
The rule of equivalence between "+" and "%20" does not apply
outside of the scheme-specific part of URL; the plus sign
has no special meaning in scheme name, since white spaces
are not allowed in scheme names.
5.2.2.4.2. Internet practice note
-+-------------------------------
The same shortening already happens in Internet. Open
http://www.google.ru/search?q=Fidonet+URL URL, and you'll
get the Google search for "Fidonet URL" (not "Fidonet+URL");
http://www.google.ru/search?hl=ru&q=Fidonet%2BURL is needed
if you're looking for "Fidonet+URL".
This practice is not documented in RFC 1738. It is, however,
documented in RFC 1630.
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... i have no capslock and i must scream (Bugzilla Quip System)
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 7 of 11 of file FidoURL.txt
textbegin.section
7.1.1. The leading slash and the trailing slash
-+---------------------------------------------
The leading slash of <object-path> is a mere delimiter between
<basic-required-part> and <object-path>. If the <object-path>
part of a URL is empty, its leading slash MUST be ignored by the
program interpreting the URL. If the <object-path> part of a URL
is empty, its leading slash MAY be omitted by the author of that
URL, thus the following URLs are equivalent:
<scheme>://<basic-required-part>/?<optional-part>
<scheme>://<basic-required-part>?<optional-part>
However, the trailing slash of <object-path> has its own value,
makes some real difference. For example, "example.zip" means
the archive itself (a file that may be saved or sent, etc.),
and "example.zip/" means the root directory of that archive
(a container that may be browsed, updated, etc.)
The trailing slash of <object-path> MUST NOT be ignored.
7.1.2. Dealing with unknown containers
-+------------------------------------
Sometimes an <object-path> designates an object inside
such a container that certain Fidonet browsers are not able
to open by themselves. This MAY happen when the archive format
is unknown (or is known, but is newer than the supported one).
If the object is requested as a separate entity (for example,
its URL is entered in the address line of a Fidonet browser,
or the user follows a hyperlink specifying that URL),
the browser MAY inform the user about the unknown container
encountered, and suggest saving that container for possible
manual analysis (after all, the user may have unpacker tools
in his avail that are not yet integrated into a Fidonet browser,
and may be willing to try them).
If the requested object is not a separate entity (for example,
if it is just one of images on a hypertext page), if many such
objects are requested at the same time and for the same purpose,
then it would not be wise to flood the user with information
about each of such obstacles concurrently encountered, and so
the browser SHOULD follow its standard procedures prescribed for
the state of error (display a "broken image" icon, or use
an alternate object or an alternate text where it is provided).
7.2. "area://" scheme
-+-------------------
Echomail is an important and powerful force in Fidonet. Echomail
is, by definition, a broadcast medium. See echomail specifications
in FTS-0004.
An echomail area is a shared base of messages that have common
areatag (area identifier) and are distributed through Fidonet
via hierarchical and/or p2p-alike connections between individual
Fidonet systems (nodes and points).
Due to the immanent modularity of Fidonet software packages,
echomail composer and echomail browser can be different programs
(for example, the latter does not require read/write access to the
area message base and is able to work through a read-only gate).
The "echomail:" scheme (defined above) is designed to designate
an action of a Fidonet echomail composer; the "area://" scheme,
defined is this section, designates a resource that is located
in an area message base. These schemes can be handled by different
software modules, even if they were manufactured independently.
The area URLs take the form:
area://<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 an <areatag> corresponds to an echomail area which is not
available on the system, the URL MAY be treated as equivalent
to areafix:<areatag> and the user MAY be asked whether he wants
to subscribe.
If <object-path> is empty and <optional-part> does not contain
message-identifying parameters, the area URL designates an area
as a whole.
Examples:
area://Ru.FTN.Develop
area://Ru.FTN.Winsoft/
area://FTSC_Public?
area://Ru.Fidonet.Today/?
When such a link is used (clicked, followed), an echomail browser
MAY open a sorted list of echomail messages present in the given
area, or a threaded list of replies. This depends on user settings
of the browser.
If <areatag> is empty, the <object-path> MUST also be empty;
such URL leads to the list of the available echomail areas,
also known as the arealist.
Examples:
area://
area:///
area://?
7.2.1. Message-identifying optional parameters
-+--------------------------------------------
If one of the message-identifying optional parameters is present
in the <optional-part> of an area URL, then
area://<areatag>?<optional-part>
no longer designates the whole message base of the given area,
but only the message(s) specified by the given value of the
message-identifying optional parameter(s).
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... BETA: Bugs Exist, Try Again. (Bugzilla Quip System)
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 1 of 11 of file FidoURL.txt
textbegin.all
**********************************************************************
FGHI FIDONET GLOBAL HYPERTEXT INTERCHANGE
**********************************************************************
Status: draft
Revision: 0.3
Title: FGHI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:5063/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Revision Date: 10 Feb 2007
-+--------------------------------------------------------------------
Contents:
1. Status of this document
2. Introduction
3. Key words to indicate requirement levels
4. Changelog of this document
5. General Fidonet URL syntax
5.1. The main parts of URLs
5.1.1. Conformance note
5.1.2. Delimiter guidelines
5.2. URL character encoding
5.2.1. Encoding of original characters
5.2.2. Encoding of octets
5.2.2.1. No corresponding graphic 7-bit character
5.2.2.2. Unsafe characters
5.2.2.3. Reserved characters
5.2.2.4. The plus ("+") and the encoding of white spaces
5.2.2.4.1. Specificity note
5.2.2.4.2. Internet practice note
5.3. Parsing the scheme-specific part of URL
5.3.1. Dealing with inappropriate reserved characters
6. Fidonet URL schemes designating actions
6.1. "netmail:" scheme
6.1.1. Optional parameter "to"
6.1.2. Optional parameter "subject"
6.1.3. Optional parameter "subj"
6.1.4. Optional parameter "from"
6.1.5. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameters "unsubscribe" and "leave"
6.2.3. Future optional parameters
6.2.4. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "subj"
6.3.4. Optional parameter "from"
6.3.5. Optional parameter "body"
7. Fidonet URL schemes designating objects
7.1. The <object-path> part of URL. Possible forms of the path
7.1.1. The leading slash and the trailing slash
7.1.2. Dealing with unknown containers
7.2. "area://" scheme
7.2.1. Message-identifying optional parameters
7.2.1.1. Optional parameter "msgid"
7.2.1.2. Optional parameter "mid"
7.2.1.3. Optional parameter "from"
7.2.1.4. Optional parameter "find"
7.2.1.5. Future message-identifying optional parameters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. How the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. Regular expressions
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "bot"
7.3.2. Future optional parameters
7.4. "fecho://" scheme
7.5. "freq://" scheme
7.5.1. Future optional parameters
-+--------------------------------------------------------------------
1. Status of this document
-+------------------------
This document is a draft of a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard
that can be used both in the Fidonet community and in the Web,
and requests discussion and suggestions for improvements.
Implementation of the protocols defined in this document is not
mandatory, but all implementations of these protocols are expected
to adhere to this standard.
Distribution of this document is unlimited,
provided that its text is not altered without notice.
2. Introduction
-+-------------
This document specifies several Fidonet schemes of Uniform Resource
Locators (URL), providing both syntax and semantics of formalized
information for location and access of resources and services
via Fidonet.
It is designed to conform with the specifications of RFC 1738, so
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional HTML hypertext
environment of the Web and Internet e-mail.
Besides its independent significance, this document will serve as
the first and the most basic part of FGHI (pronounced 'fig-high',
stands for 'Fidonet Global Hypertext Interchange') -- that is future
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of HTML-alike illustrated hypermedia over
the traditional set of echomail and netmail plain-text connections,
and probably some other elements of hypertext-over-Fido networking.
3. Key words to indicate requirement levels
-+-----------------------------------------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in FTA-1006 (based on RFC 2119).
4. Changelog of this document
-+---------------------------
In version 0.3: [10 Feb 2007]
*) started this changelog
*) added subsection 7.2.1.3 (Optional parameter "from")
*) added subsection 7.2.1.4 (Optional parameter "find")
*) edited the surrounding subsection 7.2 to reflect the fact that
now several messages can be identified, not only a single message
*) edited the subsection 7.2.1.5 to reflect the fact that messages
can already be searched with regexes
*) added special thanks to NoSFeRaTU
*) edited subsection 5.2.2.4.2, RFC 1630 is mentioned
*) edited the list of examples in section 5
*) added subsection 7.2.3 (Regular expressions)
*) added subsection 7.2.4 (Controlling the visibility of kludges
and hidden lines)
*) edited subsection 5.2.2.2, the word "Origin" in not unsafe now
*) edited the subsection 7.5.1 to reflect the fact that requests
may be delayed
5. General Fidonet URL syntax
-+---------------------------
Just as there are many different types of Fido objects and services,
there are several URL schemes for describing the location of such
resources.
The generic syntax for URLs provides a framework for new schemes
to be established using protocols other than those defined in this
document.
URLs are used to 'locate' resources, by providing an abstract
identification of the resource location. Having located a resource,
a Fidonet system may perform a variety of operations on the resource
(as might be characterized by such words as 'access', 'subscribe',
'unsubscribe', 'send', 'request', 'show attributes').
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 66. My security keypad will actually be a fingerprint scanner.
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 5 of 11 of file FidoURL.txt
textbegin.section
6.1.5. Optional parameter "body"
-+------------------------------
The "body" optional parameter is used to designate the body part
of the netmail message composed. (Its default value is empty.)
The netmail composer MAY wrap the value of "body" parameter in
elements of some user-defined message template (user-defined
signature, greeting, etc.)
Examples:
netmail:2:5063/88?subj=About+FGHI&body=Fidonet+2.0+approached
netmail:2:50/0?subj=Complaint&body=That+sysop+is+so+annoying!
netmail:2:5030/1520.9?body=HellEd+needs+enormously+large+DLLs
6.2. "areafix:" scheme
-+--------------------
Areafixing letters is a special sort of netmail. Areafixing letter
commands an uplink node (to which the letter is addressed and sent
directly) to change some of its echomail subscription options. For
example, the downlink (who writes the letter) may request itself
to be subscribed and/or unsubscribed from certain echomail areas,
order the rescan of message base, change packer/unpacker settings,
view the list of echoes available, etc.
An echomail area is a shared base of messages that have common
areatag (area identifier) and are distributed through Fidonet
via hierarchical and/or p2p-alike connections between individual
Fidonet systems (nodes and points). See echomail specifications
in FTS-0004.
Areafixing letters usually follow a very strict scheme: they must
have the downlink's password in subject line (in order for request
to be properly authentified), and the name of a certain areafixing
robot (e.g. "AreaFix", or "AreaMgr", or "AreaLink") must be given
as the addressee name. All of these requirements are confidential
by nature, and thus the above described "netmail:" scheme can not
be used to design hyperlinks that invite to subscribe or to leave
certain Fidonet echomail areas. A separate URL scheme is needed.
The "areafix:" scheme is used to designate a Fidonet areafixing
action that involves some echomail area.
The character "/" has its literal meaning for this scheme.
The areafix URLs takes the form:
areafix:<areatag>?<optional-part>
When "areafix:" hyperlink is used (clicked, followed), it SHOULD
launch a netmail composer (or subscription manager) software that
automatically composes the proper areafixing letter (addressed
to an uplink node and ordering subscription to the given echomail
area). However, it is RECOMMENDED that the software asks its user
to confirm the ready subscription order or cancel it
before that letter is sent.
Examples:
...if you're a developer, subscribe via areafix:SU.FidoTech
and enjoy there an endless stream of FAQs...
...join today's Fidonet life discussions, use the hyperlink
leading to areafix:Ru.Fidonet.Today
6.2.1. Optional parameter "uplink"
-+--------------------------------
Fidonet software usually has its own means to determine which
uplink has the requested echomail area and would receive the
areafixing netmail letter. However, if the system has several
uplink nodes able to distribute the given echo, the "uplink"
optional parameter MAY be used to recommend the preferred uplink
node (provided that the author of the hyperlink has some reasons
to recommend one uplink above all others).
The "uplink" parameter takes a value that uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
However, some parts of address ("<zone>:", "@<domain>"
and/or ".<point>") MAY be omitted (see FSP-1004 for details).
The point number is often omitted in the "uplink" parameter
values, because Fidonet points almost never become uplinks.
Examples:
...get the echo about embedded systems directly from its
moderator, use areafix:Ru.Embedded?uplink=2:5029/32
...those Titanic echoes never were on the backbone, use
areafix:Titanic.PVT?uplink=2:5020/830 and subscribe to one
from the primary hub...
The "uplink" parameter has no default value; the default
behaviour of the subscription management software has to be
determined by the network topology of uplink-downlink relations.
Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. However, if
the "uplink" optional parameter is present, the software MAY
choose to cancel echomail subscription order formerly sent to
the current uplink for the given echomail area, and then arrange
for supply of the same echomail area from the preferred uplink
provided by the value of the "uplink" parameter. (The user
SHOULD be asked first whether such an action is appropriate.)
6.2.2. Optional parameters "unsubscribe" and "leave"
-+--------------------------------------------------
If the "unsubscribe" optional parameter and/or its shorter
synonym parameter "leave" appear in the areafix URL, then
unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.
The value of these parameters is ignored; only their presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value to them, and to omit
the "=" character, thus keeping areafix URL resonably short.
Examples:
areafix:Ru.PHP?unsubscribe
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave
6.2.3. Future optional parameters
-+-------------------------------
Future versions of this document may introduce even more
optional parameters for the areafix URLs, encouraging somewhat
tighter control over rescan parameters, packer/unpacker settings
and formats, etc.
Programs interpreting areafix URLs SHOULD NOT be sure whether
it is safe to ignore any of the unknown parameters. Some of
future extensions may dramatically change the URL's meaning,
as "unsubscribe" is already able to change it to the opposite.
If an unknown parameter is encountered in the areafix URL,
the user SHOULD always be asked whether it can be discarded
safely enough.
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 230. I will not procrastinate regarding any ritual granting immortality.
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 6 of 11 of file FidoURL.txt
textbegin.section
6.2.4. Relative "areafix:" URLs
-+-----------------------------
If an areafix URL is published in the same echomail area that is
involved in the designated action, then the <echomail-area-name>
MAY be omitted.
Examples:
...if you don't like this area, areafix:?unsubscribe from it!
...if you feel that some echomail messages is missing, then
your current uplink is not reliable. You'd better subscribe
using areafix:?uplink=2:5063/88
If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.
6.3. "echomail:" scheme
-+---------------------
Echomail is an important and powerful force in Fidonet. Echomail
is, by definition, a broadcast medium. See echomail specifications
in FTS-0004.
An echomail area is a shared base of messages that have common
areatag (area identifier) and are distributed through Fidonet
via hierarchical and/or p2p-alike connections between individual
Fidonet systems (nodes and points).
The "echomail:" scheme is used to designate a Fidonet echomail
area as a location where echomail can be sent to.
The character "/" has its literal meaning for this scheme.
The echomail URLs take the form:
echomail:<areatag>?<optional-part>
Examples:
echomail:Ru.FTN.Develop
echomail:Ru.FTN.WinSoft
echomail:FTSC_Public
When an "echomail:" hyperlink is used (clicked, followed),
an echomail message composer SHOULD be launched.
6.3.1. Optional parameter "to"
-+----------------------------
The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SHOULD be "All", meaning
all of the area audience. The default value MAY also be given by
some user setting of the echomail composer used to process
the "echomail:" URL.
Examples:
echomail:Ru.FTN.Develop?to=Mithgol+the+Webmaster
echomail:Ru.FTN.WinSoft?to=Trooper
echomail:Ru.Fidonet.Today?to=Alex%20Kocharin
6.3.2. Optional parameter "subject"
-+---------------------------------
The "subject" optional parameter is used to designate
the subject line of the echomail message composed. Its default
value is empty; the default value MAY also be determined by
some user setting of the echomail composer used to process
the "echomail:" URL.
Examples:
echomail:SU.Chainik?subject=How+do+I+set+up+a+tosser%3F
echomail:Ru.GoldEd?subject=GoldEd%2b+changelog
echomail:R50.Bone?to=R50BM&subject=%D0%AD%D1%85%D0%B8%3F
6.3.3. Optional parameter "subj"
-+------------------------------
The "subj" optional parameter is used as a shorter equivalent to
the "subject" parameter. If the optional parameter "subject" is
not present in a given URL, the value of "subj" parameter MUST
be taken instead the value of "subject", provided that "subj"
is present.
Example:
echomail:FTSC_Public?subj=Long+subject+may+avoid+line+wrapping+limits
6.3.4. Optional parameter "from"
-+------------------------------
The "from" optional parameter is used to designate the name of
the echomail letter's author. Its default value is usually
defined within the echomail composer settings.
Examples:
echomail:Ru.Moderator?to=R50EC&from=Moderator+of+XXX.chat
echomail:Ru.Fidonet.Yo?from=Moderator&subject=*+*+*+Rules
6.3.5. Optional parameter "body"
-+------------------------------
The "body" optional parameter is used to designate the body part
of the echomail message composed. (Its default value is empty.)
The echomail composer MAY wrap the value of "body" parameter in
elements of some user-defined message template (user-defined
signature, greeting, etc.)
Examples:
echomail:Ru.FTN.Develop?subj=FGHI&body=Fidonet+2.0+approached
echomail:400.Link?subj=Interface&body=A+much+better+option%3F
echomail:GSS.ParToss?body=Will+it+ever+toss+JAM%3F&subj=Hopes
7. Fidonet URL schemes designating objects
-+----------------------------------------
The URL schemes enumerated below designate named objects
that can be accessed, read, browsed, etc.
According to the above section of delimiter guidelines,
the "://" character triplet (and not the ":" character)
SHOULD be used as the delimiter after <scheme> part of such URLs.
7.1. The <object-path> part of URL. Possible forms of the path
-+------------------------------------------------------------
Sometimes Fidonet is regarded as a text-only network. At least,
Fidonet is notable for its very few means of transferring binary
data. File echoes do not enjoy an audience comparable to that
of traditional echo areas; file requests and attaches are almost
never routed between nodes. In that somewhat harsh circumstances,
however, several means of encoding and embedding the binary data
inside text messages exist. Files (and sometimes whole directories
of files) are packed to economize traffic; some of the resulting
archives are encoded in text lines that are sent via text-only
means of communication -- in echomail, in netmail.
That's why all the following Fidonet URL schemes must have some
common method to designate, if necessary, an object inside packed
(archive) files and/or embedded in some text. The <required-part>
of their URL always ends with "/<object-path>", and so URLs are
written as follows:
<scheme>://<basic-required-part>/<object-path>?<optional-part>
The character "/" always has its reserved meaning in <object-path>
part of URL; this character plays the role of delimiter between
parts of the path.
The <object-path> part of URL takes one of the following forms:
<object-name>
If <object-path> contains just a name of some object, the URL
designates that object. The object itself is embedded or is
contained inside the resource specified by the rest of URL:
<scheme>://<basic-required-part>?<optional-part>
<object-name>/
The named object itself is a container (e.g. packed archive).
The URL designates the root directory of that container.
<object-name>/<needed-object>
The <object-name> is a container (e.g. a packed archive),
and its root directory contains <needed-object>; the URL
designates that <needed-object>. If <needed-object>
is a directory (i.e. not a file), the <object-path>
is equivalent to its following form,
<object-name>/<needed-object>/
<object-name>/<needed-object>/
The <needed-object> inside <object-name> is either a container
itself (e.g. a packed archive file) or a subdirectory inside
<object-name> container. The URL designates the contents of
<needed-object> container or directory. (If <needed-object>
is a container with subdirectories, the URL designate the
contents of its root directory.)
<object-name>/<elem1>/<elem2>/.../<elemN>/<needed-object>
or
<object-name>/<elem1>/<elem2>/.../<elemN>/<needed-object>/
The <object-name> contains a hierarchy as deep as N elements,
they're either subdirectories or container objects (packed
archive files, for example). It is necessary to enter those
containers and browse into directories, one after another,
in the given order. The innermost element contains the object
<needed-object>. The URL designates either the object itself
(if trailing slash is missing and <needed-object> is not
a subdirectory) or its contents (if <needed-object> is
a subdirectory, that directory's contents is designated;
otherwise, <needed-object>/ means the root directory of
<needed-object>).
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 78. I will not tell my Legions of Terror "And he must be taken alive!"
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 11 of 11 of file FidoURL.txt
textbegin.section
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 is either empty, or not empty,
or not present at all. These are three separate possible cases.
If the <request> part of a faqserv URL is present but empty,
the slashes around it MUST not be omitted. Such an URL implies
a default request to the given server. This MAY be a request
for help (i.e. "HELP" request), a request for the list of topics
(e.g. "%LIST" request), or any other request probably determined
by some user settings or contents of a database of FAQ servers.
Examples:
faqserv://2:5020/1641.7//
The list of FAQServer topics is requested.
faqserv://2:5030/1410.100//sample.zip
ZIP file is located inside the standard response.
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
If the <request> part of a faqserv URL is not empty, it specifies
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.
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.
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.
7.5.1. Future optional parameters
-+-------------------------------
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 or delay file requests that are sent
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
future extensions may dramatically change the probability
of the success of a file request, especially when such
a parameter controls the file request time.
If an unknown parameter is encountered in the freq URL,
the user SHOULD always be asked whether it can be discarded
safely enough.
**********************************************************************
EOTD END OF THE DOCUMENT
**********************************************************************
textend.all
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 6. I will not gloat over my enemies' predicament before killing them.
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 4 of 11 of file FidoURL.txt
textbegin.section
5.3. Parsing the scheme-specific part of URL
-+------------------------------------------
As it was stated above, Fidonet URLs are written as follows:
<scheme><scheme-delimiter><scheme-specific-part>
where <scheme-delimiter> is either ":" or "://".
The <scheme-specific-part> uses the reserved character "?"
as the delimiter between required and optional part or URL:
<scheme><scheme-delimiter><required-part>?<optional-part>
The required part is REQUIRED. The optional part MAY be empty;
if the optional part is empty, the "?" character before it MAY
be omitted. If the optional part is empty and the "?" character
is present, then the "?" character MUST be ignored.
If the optional part is not empty, it consists of one or more
"parameter=value" settings, delimited by the reserved "&"
character as follows:
<setting1>&<setting2>&<setting3>&<setting4>& ... &<settingN>
However, the optional part MAY have the "&" character on URL's end
as follows:
<setting1>&<setting2>&<setting3>&<setting4>& ... &<settingN>&
(in this case the last "&" character MUST be ignored).
Each of these settings is expected to appear in "parameter=value"
form:
<parameter's name>=<parameter's value>
If the value part is omitted, then the corresponding parameter
is assigned an empty value. In this case the "=" character MAY
also be omitted. Example of such an optional part of URL:
subj=Test&path=&subscribe&to=Test+Robot
In this example, parameters "path" and "subscribe" become empty,
the parameter "subj" becomes equal to "Test" value, and the
parameter "to" becomes equal to "Test Robot" value (because "+"
represents the white space, see the corresponding section above).
Parameters specified in the optional part of URL are also optional
by nature. If a certain parameter does not appear in the given URL
at all, it takes a default value; and default values for most of
optional parameters are defined below, where the URL schemes are
enumerated.
The "parameter=value" pairs MAY have an arbitrary order
of appearance in an optional part of URL.
For example, this optional part of URL:
to=Test+Robot&path=&subj=Test&subscribe
is equivalent to the previous example.
5.3.1. Dealing with inappropriate reserved characters
-+---------------------------------------------------
The reserved character "?" MUST be used only once in a URL; if
there are many "?" in some URL, then the first appearance of "?"
SHOULD be treated as the delimiter between required and optional
parts of that URL, and the remaining "?" MAY be treated as if
they were properly encoded ("%3F" character triplets), or even
ignored.
The reserved character "=" MUST be used only once in a parameter
setting; if there are many "=" characters in some setting, then
the first appearance of "=" SHOULD be treated as the delimiter
between that parameter's name and the parameter's value; and
the remaining "=" characters, encountered before the next "&"
(or before URL's ending, if it's the rightmost "parameter=value"
pair) MAY be treated as if they were properly encoded octets of
that parameter's value ("%3D" triplets), or even ignored.
"The first appearance" means the leftmost one, because
it is natural to parse the scheme-specific part of URL
in left-to-right order.
The programs interpreting Fidonet URL MAY also stop the whole
interpreting and ignore the rest of URL after the position where
an inappropriate reserved character is first encountered. This
behaviour is especially RECOMMENDED for the programs trying to
isolate URLs from some plain text, where the white spaces and/or
other delimiters before and after URLs tend to be sometimes
omitted by chance.
6. Fidonet URL schemes designating actions
-+----------------------------------------
The URL schemes enumerated below designate resources
that are most often used in typical actions
involving netmail or echomail composed and sent.
According to the above section of delimiter guidelines,
the ":" character (and not the "://" character triplet)
SHOULD be used as the delimiter after <scheme> part of such URLs.
6.1. "netmail:" scheme
-+--------------------
The "netmail:" scheme is used to designate the Fidonet netmail
address of an individual or service. It uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).
The character "/" has its literal meaning for this scheme.
The netmail URLs take the form:
netmail:<zone>:<net>/<node>.<point>@<domain>?<optional-part>
However, some parts of address ("<zone>:", "@<domain>"
and/or ".<point>") MAY be omitted (see FSP-1004 for details).
Examples:
netmail:2:5030/1520.9 (point address)
netmail:2:5063/88 (node address)
netmail:182:5043/1@forestnet (node address outside of Fido)
When a "netmail:" hyperlink is used (clicked, followed), a netmail
composer software MAY be launched. With this possibility in mind,
several optional parameters are designed for the "netmail:"
URL scheme.
6.1.1. Optional parameter "to"
-+----------------------------
The "to" optional parameter is used to designate the name of
netmail addressee. Its default value MAY be "Sysop" or "SysOp".
The default value MAY also be determined by some user setting
of the netmail composer used to process the "netmail:" URL.
Examples:
netmail:2:5063/88?to=Mithgol+the+Webmaster
netmail:2:5030/1520.9?to=Trooper
netmail:2:50/13?to=Alex%20Kocharin
6.1.2. Optional parameter "subject"
-+---------------------------------
The "subject" optional parameter is used to designate
the subject line of the netmail message composed. Its default
value is empty; the default value MAY also be determined by
some user setting of the netmail composer used to process
the "netmail:" URL.
Examples:
netmail:2:5063/88?subject=Is+the+hypertext+Fidonet+ready%3F
netmail:2:5030/830.17?subject=Yet+another+GoldEd%2b+feature
netmail:2:5030/84?to=R50EC&subject=%D0%AD%D1%85%D0%B8
6.1.3. Optional parameter "subj"
-+------------------------------
The "subj" optional parameter is used as a shorter equivalent to
the "subject" parameter. If the optional parameter "subject" is
not present in a given URL, the value of "subj" parameter MUST
be taken instead the value of "subject", provided that "subj"
is present.
Example:
netmail:2:5063/88?subj=Long+subject+may+avoid+line+wrapping+limits+:-)
6.1.4. Optional parameter "from"
-+------------------------------
The "from" optional parameter is used to designate the name of
the netmail letter's author. Its default value is usually
defined within the netmail composer settings.
Examples:
netmail:2:5030/84?to=R50EC&from=Moderator&subject=New+echo+rules
netmail:2:5024/1024?from=Moderator&subject=%5B%21%5D+read+only
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 136. If I build a bomb, I will make every wire red.
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 8 of 11 of file FidoURL.txt
textbegin.section
7.2.1.1. Optional parameter "msgid"
-+---------------------------------
The "msgid" optional parameter is used to designate a single
message in the given message base. The value of this parameter
is the contents of MSGID kludge of that message, without the
leading "^MSGID: " string.
MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers of echomail messages.
Examples:
area://R50.SysOp?msgid=2:5063/88+44585f4d
area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
Note that the "msgid" optional parameter MAY designate some
message that is not present in the current echomail message
base of the given area. In this case, a Fidonet system MAY ask
its uplink for a rescan of such an area, or use some external
archive of Fidonet echomail messages, or try some other means
of getting the desired message. The designated message is not
available until this actions bring the desired result. And
programs interpreting Fidonet URLs SHOULD NOT discard "msgid"
and pretend that area://<areatag>?<optional-part> designates
the whole area if the desired message can not be accessed
immediately.
7.2.1.2. Optional parameter "mid"
-+-------------------------------
The "mid" optional parameter is used as a shorter equivalent
to the "msgid" parameter. If the optional parameter "msgid"
is not present in a given URL, the value of "mid" parameter
MUST be taken instead the value of "msgid", provided that
"mid" is present.
Examples:
area://Ru.List.CityCat.Business.Tax.NewLawTaxes?mid=2:5063/88+00000000
area://Ru.List.CityCat.Comp.Soft.Others.ARCTest?mid=2:5063/88+11111111
area://Ru.List.CityCat.COMP.Soft.Win.SoftPileRu?mid=2:5063/88+22222222
area://Ru.List.CityCat.Fin.Review.UkrStockDaily?mid=2:5063/88+33333333
area://Ru.List.CityCat.Home.ModeBeauty.NewSport?mid=2:5063/88+44444444
area://Ru.List.CityCat.HScope.Daily.Sagittarius?mid=2:5063/88+55555555
area://Ru.List.CityCat.INet.News.ComputerReview?mid=2:5063/88+66666666
area://Ru.List.CityCat.Job.Careerist.Technology?mid=2:5063/88+77777777
area://Ru.List.CityCat.Job.Education.Philosophy?mid=2:5063/88+88888888
area://Ru.List.CityCat.Media.News.Review.UkrMet?mid=2:5063/88+99999999
area://Ru.List.CityCat.Media.Science.ForestNews?mid=2:5063/88+aaaaaaaa
area://Ru.List.CityCat.News.Russia.PavlovoPosad?mid=2:5063/88+bbbbbbbb
area://Ru.List.CityCat.Rest.Mystery.AstroMskSPb?mid=2:5063/88+cccccccc
area://Ru.List.CityCat.Science.News.Conferences?mid=2:5063/88+dddddddd
area://Ru.List.CityCat.Science.Psychology.Child?mid=2:5063/88+eeeeeeee
area://Ru.List.CityCat.State.Politics.WorldStat?mid=2:5063/88+ffffffff
7.2.1.3. Optional parameter "from"
-+--------------------------------
The "from" optional parameter is used to define the Fidonet
netmail address of an individual or service that designated
message(s) originate from.
The value of the "from" parameter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).
If "from" is present in the <optional-part> of an area URL,
then
area://<areatag>?<optional-part>
no longer designates the whole message base of the given area,
but only the message(s) posted to that area by the specified
node or point. The field of that messages can be narrowed even
further if some other message-identifying parameters are used
in the same URL.
7.2.1.4. Optional parameter "find"
-+--------------------------------
The "find" optional parameter implies that the designated echo
area should be searched for a specific message, or several
messages. The value of that "find" optional parameter contains
a regular expression; the body (bodies) of found message(s)
MUST match that expression.
See section 7.2.3 for the details about regular expressions.
If "find" is present in the <optional-part> of an area URL,
then
area://<areatag>?<optional-part>
no longer designates the whole message base of the given area,
but only the message(s) that match the specified regular
expression. The field of that messages can be narrowed even
further if some other message-identifying parameters are used
in the same URL.
Examples:
encoded: ...&find=/\bFido(net)%3f\b/i
regex: /\bFido(net)?\b/i
matches: Fido
matches: FIDOnet
matches: FidoNet
does not match: Fidonet-alike
does not match: Fidobrowser
does not match: fidoshnik
does not match: triffidos
encoded: ...&find=/(P(2P)%7b1,4%7d%7cfile\s%2bexchange)/
regex: /(P(2P){1,4}|file\s+exchange)/
matches: P2P
matches: P2P2P2P
matches: P2P2P2P2P
matches: file exchange
matches: file exchange
does not match: P2P2P2P2PP2P2P2P2P
does not match: P2P2P2P2P2P
does not match: fileexchange
does not match: file_exchange
does not match: p2p
does not match: FiLe ExChanGe
Fidonet messages are able to contain kludges (see technical
details in FTS-4000). Consequently, it is possible for an URL
to designate a set of messages tagged by a certain kludge type
or certain kludge values. The corresponding regular expression
starts with ^\x1 or ^\01 symbols, which mean the begginning of
line immediately followed by the SOH (Ctrl+A, ASCII 1) symbol.
The expression MUST use the multi-line mode of matching ("m"
flag) for the "^" construct to match at the beginning of each
kludge.
Examples:
encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/im
regex: /^\01Real\s*name:\s+(?!\s).*/im
Matches all messages with non-empty realname kludges.
Useful for moderators who check how the subscribers
identify themselves.
encoded: ...&find=/%5E\x1Category:\s.*(music%7cweather)/im
regex: /^\x1Category:\s.*(music|weather)/im
matches kludge: Category: music
matches kludge: Category: hardcore music
matches kludge: Category: weather
matches kludge: Category: real life, bad weather, bad mood
Matches all messages that belong to at least one of the
given categories.
Useful to collect a single-theme subset of messages from
a blog or any other information channel with a wide set
of themes.
If there's a need for some URL to contain several regular
expressions and to designate Fidonet messages that match
at least one of those regular expressions, then the URL's
author MUST unite those expressions as alternative branches
of one single pattern (expression1|expression2|...) as shown
in the above category-related example.
If there's a need for some URL to contain several regular
expressions and to designate Fidonet messages that match
every of those regular expressions, then the URL's author MUST
use several "find" parameters in that URL.
Examples:
find=/%5E\01Location:\s*Moscow/im&find=/%5E(%3f!\x1).*Kremlin/im
Regular expression 1: /^\01Location:\s*Moscow/im
Regular expression 2: /^(?!\x1).*Kremlin/im
Find messages with kludge "Location: Moscow" (or even
"Location:Moscow" without a space) that contain the word
"Kremlin" outside of kludge lines.
find=/%5E\x1Category:\s/im&find=/%5E\01Now\s%2bplaying:\s/im
Regular expression 1: /^\x1Category:\s/im
Regular expression 2: /^\01Now\s+playing:\s/im
Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 199. I will not make alliances with those more powerful than myself.
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 9 of 11 of file FidoURL.txt
textbegin.section
7.2.1.5. Future message-identifying optional parameters
-+-----------------------------------------------------
Future versions of this document MAY introduce additional
message-identifying optional parameters. For example,
hypertext messages could be identified by meta information
in their HTML headers. Messages could also be searched for,
using different methods than the regular expressions.
However, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SHOULD
probably warn their users if an unknown parameter is discarded
and when such a warning is appropriate.
7.2.2. Encoded objects within echomail messages
-+---------------------------------------------
It is possible for a Fidonet echomail message to contain one
or more binary objects, encoded to appear in text-alike lines
of characters. Possible methods of encoding include UUE, MIME
(RFC 2045-2049), "data:" (RFC 2397), etc.
An echomail message MAY contain several objects, which MAY be
encoded in different manner. On the other hand, an encoded
object MAY span several Fidonet messages: for example, each
of those Fidonet messages MAY bear a section or two of UUE,
and the whole bunch of sections is needed to decode a file.
7.2.2.1. Names of encoded objects
-+-------------------------------
This subsection is informative.
Most of encoded objects within echomail messages are named.
The name of a UUE-encoded object usually appears within
"begin" and/or "section" line of UUE codes.
The name of a MIME-encoded object usually appears within
either the "Content-type" header (in its "name" section) or in
the "Content-disposition" header (in its "filename" section).
RFC 2397 "data:" does not specify an object name; however, the
hypertext object populated by that data MAY be named itself,
via "id" or "name" attribute of its tag.
7.2.2.2. How the designated object is determined
-+----------------------------------------------
If the <object-path> of an area URL is not empty, then the URL
designates either an encoded object as a whole or some inner
part of such an object. Abstracting from this inner details,
the whole object is called "the designated object" in this
subsection.
If the <object-path> of an area URL is not empty, then its
<object-name> MUST also be non-empty by definition, and it
specifies the name of the designated object.
However, the echomail message base (of the area given in
<areatag> section of the URL) MAY contain more than one object
of the same name. It is therefore important to define what
object is considered "the latest".
Among those messages that contain objects of the same name
(or just parts of those objects, e.g. UUE sections), there is
the latest message. If that latest message contains only one
of those objects (partly or as a whole), then that object is
the latest one. If that latest message contains parts and/or
whole encoded images of more than one object of the same name,
then the object whose complete encoding or just the last
section of encoding (last among its sections contained in this
latest message) appears nearest to the bottom of that message
(farthest from top) is the latest object.
How "the latest message" itself is defined is beyond the scope
of this document. It MAY be the latest received, it MAY be
the one with the most up-to-date creation date, etc.
The designated object is always determined as the latest one
among those of the name given in <object-name>.
Fidonet browser software MUST ignore objects which have such
encodings that browser can not decode; the designated object
MUST always be the latest of only those ones of the given name
that are able to be decoded from the echomail message base.
If one or several message-identifying optional parameters are
present in the optional part of the URL, then the designated
object is the latest one among only those decodable objects
of the same name whose complete encoding (or just a section
of encoding) appears in one of the messages identified by the
optional parameter(s).
7.2.2.2.1. Possible applications
-+------------------------------
This subsection is informative.
As the <object-name> always designates the latest object of
the same name, it is possible for "area://" URL to designate
an object that is updated by means of Fidonet echomail area
transport. Such objects MAY update daily (as in a weather
forecast), weekly (as in a nodelist statistical report),
etc. That's how Fidonet may easily serve dynamic up-to-date
content. And if some URL is intended to point to an older
static version instead of the up-to-date dynamic one, then
an optional message-identifying parameter (if matches just
a single message) is always able to ensure that.
If several nodes have write access to the same echo area,
and it is not possible to rely just on the latest object of
the same name, then "from" parameter can be used to ensure
that the trusted origin is chosen.
As any Fidonet browser software MUST ignore objects which
have such encodings that browser can not decode, it is made
possible to include several alternative versions of the same
object (encoded differently), even in the same one echomail
letter, provided that the names of published object versions
are all the same. The browser will happily pick the encoding
it understands. For example, someone may post both UUE (for
GoldEd+) and RFC 2397 (for Gecko) versions of the same icon.
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 105. I will design all doomsday machines myself.
Mithgol the Webmaster
* также было отослано в эхоконференцию CU.TALK
* также было отослано в эхоконференцию GANJANET.LOCAL
* также было отослано в эхоконференцию RU.FIDO.WWW
* также было отослано в эхоконференцию RU.FIDONET.TODAY
* также было отослано в эхоконференцию RU.FTN.DEVELOP
* также было отослано в эхоконференцию SU.FIDOTECH
* также было отослано в эхоконференцию TITANIC.BEST
textsection 10 of 11 of file FidoURL.txt
textbegin.section
7.2.3. Regular expressions
-+------------------------
It is possible for an optional parameter of an area URL
to contain a regular expression. In section 7.2.1.4 a regex
is used to specify the designated message(s); in section 7.2.4.1
a regex defines whether a kludge is visible.
The language of regular expressions has several dirrerent
dialects. Perl Compatible Regular Expressions (PCRE) are chosen
here as the recommended; that's because PCRE engine has a rich
set of features, and because the engine is already embedded in
ECMAScript-compatible browsers of the modern Web.
The language of regular expressions is far beyond the scope of
this document. The article http://en.wikipedia.org/wiki/PCRE (in
Wikipedia) and the external links referenced there are probably
the best to start learning how to write PCRE regexes.
Some Fidonet browsers have their own JavaScript engines, that
SHOULD conform to the requirements of the ECMA-262 standard,
third edition, section 15.10. (The form and functionality of
its regular expressions is modelled after the regular expression
facility in the Perl 5 programming language.) Any other Fidonet
browsers SHOULD use the PCRE library package, which is an
open source software, written by Philip Hazel, and downloadable
at http://www.pcre.org/
Fidonet gates in the Web SHOULD use either Perl itself, or PCRE
implementation in PHP (preg_grep() function, for example), or
any other suitable PCRE-compatible implementation.
A regular expression in a Fidonet URL MUST always take the form
/pattern/flags
The only possible flags (pattern modifiers) in Fidonet URLs are
the letters "i" (if this modifier is set, letters in the pattern
match both upper and lower case letters) and "m" (if this
modifier is set, then the "start of line" and "end of line"
constructs match immediately following or immediately before any
newline in the subject string, respectively, as well as at the
very start and end).
(In brief, "i" means ignoring of case, and "m" means multi-line
mode of matching.)
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 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.
It is also 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).
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 151. I will not set myself up as a god.
Sergey Lawrinenko
10 Feb 07 13:50, You wrote to everyone:
MW> * изначально написано в эхоконференцию FTSC_PUBLIC
Hе написано.
Там последнее письмо:
====== Hачало Windows Clipboard =======
─ FTSC_PUBLIC (2:550/78) ───────────────────────────────────────── FTSC_PUBLIC
Msg : 270 of 270 -267 Snt
From : Kees van Eeten 2:280/5003 09 Jan 07 23:13:28
To : All 10 Jan 07 04:07:08
Subj : Election '06: Ballot
─1305─────────────────────────── Heerhugowaard ────────────────────────────────
@GATEWAY: RFC1036/822 ddutch.hobby.nl [FIDOGATE 4.4.1]
[skip by sl]
@PATH: 280/5003 379/1 123/500 140/1 292/100 550/78
====== Конец Windows Clipboard =======
Bye!
--