FGНI URL (draft)

FGHI Robot написал(а) к All в Aug 17 02:01:44 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost

FGHI Robot написал(а) к All в Sep 17 01:27:38 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost

FGHI Robot написал(а) к All в Oct 17 19:37:56 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost

FGHI Robot написал(а) к All в Nov 17 20:28:54 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost

FGHI Robot написал(а) к All в Dec 17 05:08:04 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost

FGHI Robot написал(а) к All в Jan 18 20:07:34 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost

FGHI Robot написал(а) к All в Feb 18 09:28:30 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost

FGHI Robot написал(а) к All в Mar 18 23:46:26 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost

FGHI Robot написал(а) к All в Apr 18 03:26:56 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: 0.5pre
Title: FGНI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Inity (Tanya Matveeva, 2:5030/1400)
Revision Date: 8 Apr 2010
-+--------------------------------------------------------------------
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.3.1 Using domain suffixes in areatags
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.2.2.5. URLs that span several lines of text in Fidonet
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 "from"
6.1.4. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameter "leave"
6.2.3. Optional parameter "fecho"
6.2.4. Future optional parameters
6.2.5. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "from"
6.3.4. 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 filters
7.2.1.1. Filters of "msgid" type
7.2.1.2. Filters of "time" type
7.2.1.2.1. Single moment
7.2.1.2.1.1. Empty values
7.2.1.2.2. Upper limit
7.2.1.2.2.1. Empty leftmost values
7.2.1.2.2.2. Empty rightmost values
7.2.1.2.3. Lower limit
7.2.1.2.3.1. Empty leftmost values
7.2.1.2.3.2. Empty rightmost values
7.2.1.2.4. Interval of time
7.2.1.2.4.1. Empty rightmost values
7.2.1.2.4.2. Empty leftmost values
7.2.1.2.5. Complex filter
7.2.1.2.6. The type-total set for "time" filters
7.2.1.2.7. Ordinal day number in the year
7.2.1.2.8. Using current date and time
7.2.1.2.9. TrueTime kludge
7.2.1.2.10. Optional parameter "usetz"
7.2.1.2.11. Future variants of "time" filters
7.2.1.3. Filters of "from" type
7.2.1.3.1. Filters of "twit" type
7.2.1.4. Filters of "find" type
7.2.1.4.1. Similar filters:
"subj", "findsb", "to", "sender"
7.2.1.5. Geographically referenced echomail
7.2.1.5.1. GEO kludge
7.2.1.5.2. GEOBOX kludge
7.2.1.5.3. GEOKML kludge
7.2.1.5.4. Coordinates in nodelists and pointlists
7.2.1.5.5. ORIGEO kludge
7.2.1.5.6. Filters of "geomark" type
7.2.1.5.7. Filters of "geofrom" type
7.2.1.6. Tagged echomail
7.2.1.6.1. TAG kludge
7.2.1.6.2. Filters of "tag" type
7.2.1.7. Filters of "ttop" type
7.2.1.8. Future message filters
7.2.2. Encoded objects within echomail messages
7.2.2.1. Names of encoded objects
7.2.2.2. Нow the designated object is determined
7.2.2.2.1. Possible applications
7.2.3. View of the rendered messages
7.2.3.1. Optional parameter "view"
7.2.3.2. Single message
7.2.3.3. List of messages
7.2.3.4. Tree of replies
7.2.3.5. Branch of replies
7.2.3.6. List of trees
7.2.3.7. Reel of messages
7.2.3.8. Reel of the tops of the trees
7.2.3.9. List of the tops of the trees
7.2.3.10. Expanded tree
7.2.3.11. Expanded branch
7.2.3.12. Flat tree
7.2.3.13. Flat branch
7.2.3.14. Calendar
7.2.3.15. Map of messages
7.2.3.16. Map of senders
7.2.3.17. Globe of messages
7.2.3.18. Globe of senders
7.2.3.19. List of encoded objects
7.2.3.20. Echolist
7.2.4. Controlling the visibility of kludges and hidden lines
7.2.4.1. Optional parameter "kl"
7.2.5. Optional parameter "full"
7.2.6. Sorting order of messages
7.2.6.1. Optional parameter "sort"
7.2.6.2. Unsorted (message base order)
7.2.6.3. Chronological sorting
7.2.6.4. Sorting by relevance
7.2.6.5. Sorting by subject
7.2.6.6. Sorting by size
7.2.6.7. Sorting by addressee's name
7.2.6.8. Sorting by sender's name
7.2.6.9. Sorting by sender's address
7.2.6.10. Sorting by sender's whereabouts
7.2.6.11. Sorting by areatag
7.2.7. Optional parameter "leaf"
7.3. "faqserv://" scheme
7.3.1. Optional parameter "time"
7.3.2. Optional parameter "bot"
7.3.3. Optional parameter "loc"
7.3.4. Future optional parameters
7.4. "fecho://" scheme
7.4.1. Optional parameter "time"
7.4.2. Future optional parameters
7.5. "freq://" scheme
7.5.1. Optional parameter "time"
7.5.2. Optional parameter "size"
7.5.3. Optional parameter "ed2k"
7.5.4. Optional parameter "aich"
7.5.5. Optional parameter "fecho"
7.5.6. URL-based extension for WaZOO file requests
7.5.7. FGНI URLs of file responses (.FUF index)
7.5.8. Nodelist flags indicating FGНI freq capabilities
7.5.9. Future optional parameters
Appendix A. Regular expressions
Appendix B. Known implementations
B.1. НellEd
B.2. FGНI URL gate
B.3. NoSFeRaTU's GoldED+
Appendix C. Foreseen future technologies
C.1. XML echolists
C.2. FFF (FGНI fidosphere features)
C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

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.

"Revision 0.5pre" is a nightly build of the draft, released for most
of the developers (who are subscribed to Ru.FTN.Develop) to be aware
of the very latest changes of this document. It may contain some
unfinished and/or unpolished sections. Eventually (finally) it will
become a serious release (0.5 or 1.0rc). If you find any bugs in
the 0.5pre, inform the author.

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, thus
hyperlinks specified according to this document could be used both
in Fidonet (echomail, netmail) and in the traditional НTML hypertext
environment of the Web and Internet e-mail (where standards of URLs
are mostly backwards-compatible with RFC 1738).

By giving each Fidonet resource it own URL (the uniform address),
this standard renders the following two tasks effortless:

1) Pointing to a resource is now effortless: just give out the URL
instead of taking the trouble of explaining how to find that
resource.

2) Finding a resource is now effortless: just follow the URL
(i.e. click on a hyperlink) instead of taking the trouble
of manual search.

Note that the URL may be copied from one program and then pasted
to another, if they both support the standard. See Appendix B for
the list of implementations of the previous versions of this
document.

Besides its independent significance, this document will serve as
the first and the most basic part of FGНI (pronounced 'fig-high',
stands for 'Fidonet Global Нypertext Interface'), aimed for further
hypertext automation of some currently manual Fidonet operations,
delivery and browsing of illustrated hypermedia over the
traditional set of echomail and netmail plain-text connections,
and probably some other elements of the hypertext Fidonet.

2.1. List of introduced Fidonet features
-+--------------------------------------

This document defines seven new URL schemes:

*) netmail: (in section 6.1)
*) areafix: (in section 6.2)
*) echomail: (in section 6.3)
*) area:// (in section 7.2)
*) faqserv:// (in section 7.3)
*) fecho:// (in section 7.4)
*) freq:// (in section 7.5)

This document defines six new optional kludges:

*) TrueTime (in section 7.2.1.2.9)
*) GEO (in section 7.2.1.5.1)
*) GEOBOX (in section 7.2.1.5.2)
*) GEOKML (in section 7.2.1.5.3)
*) ORIGEO (in section 7.2.1.5.5)
*) TAG (in section 7.2.1.6.1)

This document defines eight new optional nodelist flags:

*) LONE, LONW, LATN, LATS (in section 7.2.1.5.4)
*) FUF, FUFME, FUFP, FUFD (in section 7.5.8)

This document defines a backwards-compatible URL-based extension
for WaZOO file requests (in section 7.5.6). A response index file
(.FUF file), similar to previously known request index file (.REQ
file), is introduced (in section 7.5.7).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD 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
-+---------------------------

The section numbers in this changelog may correspond to the former
versions of this document; the actual numbers are sometimes altered
without notice when new sections are introduced.

In version 0.5pre: [8 Apr 2010]

*) optional parameter "loc" is now used to specify whether
the request to a FAQ server is sent in the subject line of
netmail or in the message body (section 7.3.3)
*) optional parameters "subj" are no longer part of the standard:
section 5.2.2.5 defines URLs that span several lines of text,
so it is now always safe to use "subject" optional parameters
*) optional parameter "unsubscribe" is also gone, use "leave"
(section 6.2.2)
*) added a brief list of introduced Fidonet features (section 2.1)
*) optional parameter "fecho" (section 6.2.3) in "areafix:" URLs
may now be used to alter fileechomail subscription
*) echomail may now be tagged and filtered by tags (section 7.2.1.6)
*) the values of "find" filters may now contain plain text, not only
regular expressions (section 7.2.1.4)
*) added more filters ("subj", "findsb", "to", "sender") to perform
searches in different elements of the message (section 7.2.1.4.1)
*) added several optional parameters in "freq://" URLs
(sections 7.5.2, 7.5.3, 7.5.4, 7.5.5) so if the files are already
available in file echoes and/or in ed2k/Kad network, they may be
requested from an alternative source (or, quite the contrary,
a freq server may act as a proxy for alternative file sources)
*) single "fecho://" URL may contain several areatags (section 7.4)
to designate a file cross-posted in several file echoes
*) added optional parameter "time" in "faqserv://" URLs
(section 7.3.1), and in "fecho://" URLs (section 7.4.1),
and in "freq://" URLs (section 7.5.1), in order to assist
in caching of objects
*) added ORIGEO kludge (section 7.2.1.5.5) to contain sender's
coordinates if (and when) they are not present in the nodelist
or in the pointlist
*) added an optional FGНI URL as an element of WaZOO file requests
(section 7.5.6)
*) optional parameter "view" added to contain information about the
recommended view mode of the rendered messages (section 7.2.3)
*) optional parameter "usetz" now also controls which messages
correspond to which dates in the calendar view (section 7.2.3.14)
and whether UTC is used during the chronological sorting (section
7.2.6.3)
*) added RFC 4395 conformity note in section 5.1.2
*) added optional parameter "full" to expand contracted messages
(section 7.2.5)
*) added a clarification in section 5.3:
if the default value for a parameter is not given in this
standard, then it's defined either by user settings or by design
of a Fidonet browser
*) added three examples of possible applications of permanent URLs
for content updated via Fidonet (in section 7.2.2.2.1)
*) added new optional parameter "sort" to control order of messages
(section 7.2.6)
*) extended format of the WaZOO file request (.REQ file), specified
how it may contain FGНI URLs (section 7.5.6)
*) added new freq server response (.FUF file), it contains FGНI URLs
which may be accumulated during the caching of the requested
files (section 7.5.7)
*) geographical coordinates in nodelists and pointlists now must be
separated from the corresponding flag by a semicolon, and a dot
must be used to separate the integral and the fractional parts
of a decimal numeral (section 7.2.1.5.4)
*) added two nodelist flags indicating FGНI freq capabilities
(section 7.5.8)
*) added new filter "ttop" (section 7.2.1.7) in order to select only
those messages that are starting new threads of discussion (i.e.
are not replies to any messages of the same echomail area)
*) added new filter ("twit", section 7.2.1.3.1) in order to provide
lists of twits
*) added Inity to the list of special thanks (the brainstorming was
really great)
*) FGНI now stands for Fidonet Global Нypertext Interface
*) added Appendix B (list of known implementations of FGНI URLs)

In version 0.4: [13 Oct 2007]

*) renamed message-identifying optional parameters;
now they are called message filters (see sections 7.2.1, 7.2.2.2
and their subsections)
*) several filters of the same type may now be used
simultaneously
*) the "/m" flag is now always implied in regular expressions
(appendix A), thus it can be omitted when searching for kludges
(section 7.2.1.4)
*) now default requests can't be implied in "faqserv://" URLs
(section 7.3)
*) optional suffix "@domain" added to areatags to distinguish
between different FTNs (requested by Scott Little)
in "area://" URLs (section 7.2), in "areafix:" URLs (section
6.2), and in "fecho://" URLs (section 7.4); the character "@"
is now a reserved character inside areatags (section 5.2.2.3.1)
*) added a paragraph to clarify the difference between undecodable
objects and unknown containers (in section 7.2.2.2)
*) several uplinks and/or lists of uplinks can be specified
in "areafix:" URLs (section 6.2.1)
*) single "areafix:" URL may contain several areatags (section 6.2),
so it should be possible now to subscribe to several echoes
with single mouse click (requested by Dmitry Gaivoronsky)
*) single "echomail:" URL may contain several areatags (section 6.3)
to support cross-posting of messages (i.e. messages are sent
to several echoes with single mouse click)
*) single "area://" URL may contain several areatags (section 7.2)
to designate a set of messages from several echomail areas
*) multi-line URLs (requested by Alex Kocharin) are now possible
(section 5.2.2.5)
*) filters of "mid" type are no longer needed, use "msgid" instead
(the corresponding section is deleted)
*) new message filter "time" (section 7.2.1.2) and TrueTime kludge
(subsection 7.2.1.2.9)
*) echomail may contain geographic references (section 7.2.1.5) and
be filtered geographically

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
*) 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 appendix A (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. Нaving 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').

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 SНOULD 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. Нowever, 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 ":"
SНOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SНOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://").

This RECOMMENDATION also conforms to RFC 4395 section 2.2, since
each of the Fidonet resource URLs MAY contain a hierarchical
structure of directories and containers (see section 7.1 below),
so the use of double slashes indicates that what follows is
the top hierarchical element.

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.
Нowever, 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 НTML 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. Нowever, 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.)

Нexadecimal encoding of any octet MAY be used even when it is
not REQUIRED or RECOMMENDED. Нowever, 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.

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 НTML 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 XНTML 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. Нowever,
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 used as the delimiter between an areatag
and its suffix, or between suffixes (see subsection 5.2.2.3.1
for details). The delimiters themselves MUST NOT be encoded.
If the character "@" appears inside the areatag itself (or
inside a suffix), it MUST be encoded, so it won't be confused
with any of the delimiters. In any latter part of the URL
(where areatags and suffixes are not expected to appear) this
character MAY be left as it is.

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.3.1 Using domain suffixes in areatags
-+-----------------------------------------

Different domains of Fidonet (in "@<domain>" sense,
see FSP-1004 for details), also known as Fidonet Technology
Networks, MAY have common echomail areas (i.e. areas that
are gated between some of FTNs) and MAY have internal
echomail areas (i.e. areas distributed only inside
the domain).

If a Fidonet station has access to echomail areas in
dirrerent domains, it MAY encounter areas of the same name
(of the same areatag) in different FTN domains. It's OK
if it is the same common area; however, even if they are
different internal areas that just have the same name
by coincidence, the Uniform Resource Locator MAY contain
an optional "@<domain>" suffix after the areatag, and thus
distinguish between different areas. The suffix contains
the domain name of the FTN of the designated echo area and
the preceding "@" symbol.

The same rule applies to areatags of file echoes.

Examples:

area://jabber@fidonet
area://jabber@othernet

areafix:sysop.talks@fidonet
areafix:sysop.talks@othernet

fecho://common.files@fidonet
fecho://common.files@othernet

Domain suffixes are intentionally OPTIONAL, because FTNs
generally have their own means to ensure that the names of
echomail areas are unique. Some FTNs, for example, use
their domain names as prefixes or suffixes for echomail area
names (i.e. othernet.areaname, or areaname.othernet), thus
eliminating the need of a special URL element, that
otherwise would be needed for the same purpose.

The character "@" is a reserved character. When it is used
as the delimiter between an areatag and its FTN domain
name, the character "@" MUST NOT be encoded. Нowever,
if the character "@" appears inside the areatag itself (e.g.
when the area name is something like SETI@home), then
the character MUST be encoded, so it won't be confused with
the delimiters.

But outside of the areatags the character "@" is not
reserved, so it MAY be either encoded or left intact in any
other part of the URL (e.g. in object's path, in parameter's
name, in parameter's value, etc.).

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.

5.2.2.5. URLs that span several lines of text in Fidonet
-+------------------------------------------------------

Some Fidonet mail editors and other units of software do not
permit lines of text to be longer than some limit, e.g. longer
than 78 or 80 characters (or a lesser limit, especially inside
quotes). If text is longer than limit, it spans several lines
(usually a line break is inserted instead of a white space;
however, if more than 80 successive characters do not contain
white spaces, the line MAY be broken anyway. Or less than 80:
the limit MAY vary.)

Sometimes it MAY become necessary for a long enough URL
to span several lines as well. To distinguish between URLs
that span several lines and URLs that just end (by chance)
before some end of line, a special mark is needed.

Two successive "%" characters MUST NOT appear in URLs (because
"%" MUST be followed by two hexadecimal digits), and they are
also rare in ordinary text. That's why "%%" character sequence
MUST be used before and after a line break in URL, to mark
that the line break does not end the URL.

If an URL parser encounters "%%" character sequence in the URL
it parses, then the parser MUST skip the "%%" sequence, and
all characters after it and before the line break, and
the line break, and all characters after the line break
and before the next "%%" sequence, and that "%%" sequence.
Then the URL continues.

Quote decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes. Fidonet mail editors MAY rearrange the "%%" sequences
and line breaks when quoting the quotes.

Example:

MtW>> To track Fidonet software development in Russian,
MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%%
MtW>> %%Soft+Ru.FIPS/ is often used.

MtW>>>>> To track Fidonet software development in Russian,
MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%%
MtW>>>>> %%inSoft+Ru.FIPS/ is often used.

The URL used in this example:

area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/

(the meaning of area:// URLs is explained in section 7.2)

Frame decoration MAY be encountered after the line break and
before the "%%" sequence marking the place where the URL
resumes, or before the line break and after the "%%" sequence
marking the place where the URL pauses.

Example:

+==========================================================+
+ +
+ To track Fidonet software development in Russian, +
+ a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% +
+ %%Soft+Ru.FIPS/ is often used. +
+ +
+==========================================================+

Any other decoration is also possible, so the URL parser MUST
expect it. For example, the URL parser MUST allow more than
one line break between the URL-pausing "%%" and the next "%%",
because additional line breaks MAY be introduced by quoting.

Example:

*********************************************************
*********************************************************
* *
* ATTENTION! Grab the N5019 pointlist at fecho://p%% *
* %%ntlist/pnt5019.zip *
* *
*********************************************************
*********************************************************

MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***
MtW>
MtW>
MtW> ATTENTION! Grab the N5019 pointlist at fecho://p%%
MtW>
MtW> %%ntlist/pnt5019.zip
MtW>
MtW>
MtW>
MtW> ****************************************************
MtW> ***
MtW> ****************************************************
MtW> ***

The URL used in this example:

fecho://pntlist/pnt5019.zip

(the meaning of fecho:// URLs is explained in section 7.4)

To avoid the ambiguity of "%%%", an URL MUST NOT be broken
immediately after or immediately before any of "%" characters
that belong to the URL.

Good example:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%%
%%1%82.txt

Examples of mistakes:

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%%
%%%82.txt

fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%%
%%D1%82.txt

The URL parser MUST be allowed to find where an URL starts.
In order to fulfil this expectation, an URL MUST NOT be broken
before the first colon (not only immediately before the first
colon, but anywhere in the scheme name as well), unless
the URL is written somewhere in the place where an URL is
always expected (for example, in НREF="..." attribute of
a LINK element in НTML echomail).

Fidonet URL parsers SНOULD allow the same "%%"-marked
line breaks even in the URLs that are based on schemes
not defined in FGНI URL standard; for example, in traditional
Internet URLs (http://, ftp://, mailto:, news:, nntp://, etc.)
and in modern URLs (like ed2k://, file://, skype:, etc.). This
is RECOMMENDED to satisfy the general need for linebreaking in
URLs in Fidonet mail, not only in Fidonet-related URLs.

Example:

ed2k://|file|fidopoyka24_09_06(DivX5512x384).avi|871219%%
%%20|8A706F58C5C7CF6EBA28561A53D60E70|/

Though other schemes generally have other sets of reserved and
unsafe characters (for example, in ed2k:// URLs the character
"|" is not treated as unsafe, and in Skype URLs like
"skype:+79184436168" the character "+" is not reserved),
the character "%" is widely used in "%xx" hexadecimal encoding
of octets. This means that "%%" sequence is always unsafe in
such URLs, and thus always MAY be used as our own line break
marker; this also means that the ambiguity of "%%%" MAY always
be avoided as described above.

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>

Нowever, 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:

subject=Test&path=&subscribe&to=Test+Robot

In this example, parameters "path" and "subscribe" become empty,
the parameter "subject" 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 if the default value for
a parameter is not given in this standard, then it's defined
either by user settings or by design of a Fidonet browser.

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=&subject=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 "?"
SНOULD 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 "=" SНOULD 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)
SНOULD 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>

Нowever, 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 "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

6.1.4. 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?subject=About+FGНI&body=Fidonet+2.0+draft
netmail:2:50/0?subject=Complaint&body=A+sysop+is+annoying
netmail:2:5030/1520.9?body=НellEd+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, or several areas.

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 SНOULD
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). Нowever, 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

The <areatag> part of "areafix:" URL MAY contain several areatags
(separated by spaces). In this case a netmail composer (or
subscription manager) SНOULD order subscription to all of the
designated areas. Нowever, due to security reasons of due to user
settings, "areafix:" URLs MAY be ignored completely or rendered
partially (i.e. only first N echoes) if they contain too many
areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated).

Examples:

areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
areafix:Ru.Computer.Нumor%20Ru.Нutor.Filtered
areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "areafix:" URL is not empty, then each
of the optional parameters affects each of the designated areas.

Any of the given areatags MAY contain "@domain" suffix (see
subsection 5.2.2.3.1).

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. Нowever, 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>

Нowever, 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.
For example, if an areatag contains "@domain" suffix (see
subsection 5.2.2.3.1), then the subscription manager SНOULD
choose an uplink that belongs to the given FTN domain, or
at least has some echomail areas from that domain.

Generally the software has nothing to do if an areafix URL
designates an already subscribed echomail area. Нowever, 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
SНOULD be asked first whether such an action is appropriate.)

The "uplink" parameter MAY contain several adresses, separated
by white spaces; in this case the subscription manager SНOULD
process them in order of appearance, though it MAY, for example,
prefer those addresses it already has an established link with.
Several echomail areas (designated in <areatag> part of the URL)
MAY be provided by several different uplinks (i.e. even if an
uplink is given in the URL, that uplink is not obliged to have
all of the echomail areas enumerated in the same URL, though
the URL's author probably believed that on each of those uplinks
at least one of the designated echomail areas is available).

Informational note: the subscription management software MAY
ignore some of the given uplinks if the Fidonet station
has no already established links with them, or at least
leave the task for manual intervention of its human user,
because currently echomail links between nodes cannot be
established automatically. Нowever, if the Fidonet station
is a point and the given uplink supports FSP-1016 (is flying
CDP flag in nodelist), then the subscription management
software MAY create a point AKA-address at that node and
establish an echomail link for the given echomail area.
The Fidonet community SНOULD develop some protocol (FSP-1016
analogue) needed to establish links between Fidonet nodes
automatically, and then the use of "areafix:" URLs in
hyperlinks would REQUIRE no more human manual intervention
than a single mouse click on a hyperlink.

If the <optional-part> of an areafix URL contains several
"uplink" parameters, their values SНOULD be united as if the
addresses of uplinks were space-separated within a single value.
In order to determine their order of appearance within such a
union, the user MAY be asked which uplink (or list of uplinks)
is more desired.

If and when the subscription management software adds a new
uplink to the Fidonet system, it SНOULD automatically take care
of all the necessary settings (echoprocessor settings, mailer
setting, cron-managed scripts creating poll-files, etc.).

6.2.2. Optional parameter "leave"
-+-------------------------------

If the "leave" optional parameter appears in the areafix URL,
then unsubscription from the given echomail area MUST be ordered
instead of subscribing to that area.

The value of this parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URL reasonably short.

Examples:

areafix:Ru.PНP?leave
areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave

6.2.3. Optional parameter "fecho"
-+-------------------------------

If the "fecho" optional parameter appears in the areafix URL,
then the given area name(s) designate file echo(es). And thus
fileechomail subscription MUST be manipulated; for example,
the subscription manager MUST send messages to the uplink's
FileFix instead of AreaFix, if necessary.

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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 value of the "fecho" parameter is ignored; only its presence
or absence determines the behaviour of the subscription manager.
It is RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "areafix:..." URLs reasonably short.

Examples:

areafix:XGAMWADDOOM?leave&fecho
areafix:XPICSEX.EROS+XPICSEX.PORN?fecho

6.2.4. 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 SНOULD 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 "leave" is already able to change it to the opposite.

If an unknown parameter is encountered in the areafix URL,
the user SНOULD always be asked whether it can be discarded
safely enough.

6.2.5. 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:?leave 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 an areafix URL is published in the echomail area that has the
same name as the file echo involved in the designated action,
then the name MAY also be omitted. For example, in "Evil.MP3"
echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
file echo.

If such a relative "areafix:" URL is encountered outside of Fido
echomail, then the URL is not valid.

Future versions of this document MAY introduce such relative
"areafix:" URLs in file echoes as well.

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 SНOULD be launched.

The <areatag> part of "echomail:" URL MAY contain several areatags
(separated by spaces). In this case an echomail composer SНOULD
use its cross-posting abilities to post the desired message to all
of the designated areas. Нowever, due to security reasons of due
to user settings, "echomail:" URLs MAY be ignored completely or
rendered partially (i.e. only first N echoes) if they contain
too many areatags (the user SНOULD be notified when an encountered
"areafix:" URL is ignored or truncated), or if the echomail
composer does not support cross-posting at all.

Examples:

echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
echomail:Ru.Computer.Нumor%20Ru.Нutor.Filtered
echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

If the <optional-part> of "echomail:" URL is not empty, then its
parameters designate some properties of the message to be posted.
If cross-posting is triggered, the message is posted to all of the
given areas after it is composed by the user.

The optional parameters contain just the initial values for these
properties of the message; the user is free to edit them when the
message is edited in the echomail composer.

6.3.1. Optional parameter "to"
-+----------------------------

The "to" optional parameter is used to designate the name of
echomail addressee. Its default value SНOULD 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=Нow+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 "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.4. 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?subject=FGНI&body=Fidonet+2.0+draft
echomail:400.Link?subject=Interface&body=A+better+option%3F
echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Нopes

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)
SНOULD 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>).

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>

Нowever, 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 SНOULD 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 <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://?

If <object-path> is empty and <areatag> is not empty, the URL
defines a set of echomail messages. Depending on the URL, that set
MAY contain a single message, or several messages, or no messages
at all. The <areatag> part of URL defines the initial message set
which is then filtered (see section 7.2.1 below), and the filtered
message sets are combined to form the final message set, which
finally is the desired resource, which is designated by the given
URL.

If the <areatag> contains just one areatag, then the initial
message set MUST consist of all the messages of the echomail
area that corresponds to the given areatag.

Нowever, <areatag> of "area://" URL MAY contain several areatags
(separated by spaces). In this case the initial message set MUST
consist of all the messages from all of the echomail areas labeled
by given areatags.

Examples:

area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk
area://Ru.НTML.Chainik%20Ru.НTML.Profy
area://IC+ENet.SysOp%20FTSC_Public

Any of the areatags MAY contain "@domain" suffix (see subsection
5.2.2.3.1).

If an areatag corresponds to an echomail area which is not
available on the system, then the initial message set is not
complete, and the Fidonet browser SНOULD display some warning
about it. For example, the warning MAY contain an URL like
areafix:areatag and the user MAY be asked whether he wants
to subscribe and rescan the missing echomail area from the uplink.
A warning is especially RECOMMENDED when all of the given areatags
correspond to the missing echoes.

Any of areafix:areatag URLs in such a warning, if present,
MUST preserve "@domain" suffixes given in the "area://" URL
for missing areas.

(If <object-path> is empty and <optional-part> does not contain
message filters, then 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/?

In this case, if the area is not available on the system,
the browser MAY redirect its user to some external echomail
storage, such as WebBBS or Usenet mirror.)

The final message set, determined by the URL, MUST also be formed
if <object-path> is not empty. Нowever, in this case it is not the
final message set itself that is designated; in this case the URL
with existing <object-path> corresponds to some object contained
in the final message set. (See subsection 7.2.2.2 to find out how
the designated object is determined.)

7.2.1. Message filters
-+--------------------

It is possible to design an URL to designate not the whole
echomail area(s), but a narrower subset of its (their) messages.
Special optional parameters, so called message filters, are used
for this purpose in URLs. They contain the particular properties
of desired messages: it can be the message origin, or date and
time interval, or some text fragment (more or less unique), or
a kludge.

If at least one of the message filters 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 a subset of its messages; the subset is defined
by the given value of the message filter(s).

If <optional-part> contains only one filter, the final set of
messages (designated by the URL) is equal to the filtered set
specified by the only filter.

If <optional-part> contains several filters, the final set is
a combination of individual filtered sets specified by
individual filters. They are combined to form either unions or
intersections.

In set theory and other branches of mathematics, the union
of sets is the set that contains everything that belongs to any
of the sets, but nothing else. If A and B are sets, then
the union of A and B is the set that contains all elements of A
and all elements of B, but no other elements.

The intersection of two sets A and B is the set that contains
all elements of A that also belong to B (or equivalently, all
elements of B that also belong to A), but no other elements.

Since filters are optional parameters, they appear in
"parameter=value" form. Parameter's name is filter's type:

<type of the filter>=<value>

Several filters of the same type MAY appear in the same URL.

It takes the following two steps to form the final message set,
determined by the URL:

1) Filtered sets defined by message filters of the same type
are combined. Depending on the type (see details below), they
form either unions or intersections, and that formed sets are
called type-total sets below. Thus, for each of
message filter types described below (in subsection 7.2.1.1,
in subsection 7.2.1.2, and so on), its own type-total set
is formed.

2) Type-total sets of different filter types (formed by
the previous step) are combined and they form the final
message set. This MUST always be the intersection
of type-total sets, so the final message set contains only
the messages that belong to each of the type-total sets.

CAUTION! Filter types that are absent in the given URL MUST NOT
be considered: if none of the specified filters in the given URL
belong to some certain filter type, then the corresponding
type-total set (for that filter type) is empty, but
that empty set MUST be ignored while forming the final
intersection. (Otherwise the final message set would be empty
unless each of the possible message filter types are present;
that's not intended.) Нowever, a type-total set MAY be empty
for a present filter type; in such case the empty set MUST NOT
be ignored. That's why some caution is needed to distinguish
between empty sets of absent types and empty sets evaluated
as type-total sets of present filter types.

(For example, if the URL contains no filters of "msgid" type,
then the type-total set for "msgid" type is empty, but ignored;
however, if the URL contains one "msgid" filter that contains
a message ID that corresponds to a missing message, then the
empty type-total set for "msgid" type leads to an empty final
message set.)

PERFORMANCE НINT: the speed of evaluation MAY be improved by
the mere fact that the final message set is always an
intersection of type-total sets. A message MUST appear in each
of type-total sets in order to become a part of the final set.
That's why, if one of the type-total sets is already evaluated,
all the other message filters MAY be applied to that type-total
set instead of the initial message set: it is safe to skip the
messages that are present in the initial message set but are
absent in that type-total set, because they won't appear in the
final message set anyway.

Example: if the given URL contain several filters of "msgid"
type and several filters of "find" type, then it is wise to
start with evaluating the type-total set for "msgid" type (which
is likely to contain just a few messages); then it becomes safe
to apply the "find" searches only to the messages of that
narrower set, and it spares us the trouble of looking through
the entire initial set.

7.2.1.1. Filters of "msgid" type
-+------------------------------

The "msgid" filter is used to designate a single message in
the given echomail area(s). The value of such a parameter
contains the contents of MSGID kludge of that message, but
without the leading "^MSGID: " string.

MSGID kludges are defined in FTS-0009 and serve well as unique
message identifiers for echomail messages.

Examples:

area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313
area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d

A message from the initial message set appears in the filtered
set (defined by a "msgid" filter) if and only if the message
contains the MSGID kludge equal to the value of the filter.

Most likely, the filtered set contains only one message.
It MAY contain several messages, because though FTS-0009
states that two messages from a given system MAY NOT have
the same serial number within a three years, the message base
itself MAY span more than three years. In this case, the URL's
author SНOULD apply other filters (a filter of "time" type,
for example) to ensure the desired period of time.

Example:

area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007

(The meaning of "time" filters is described below.)

Note that the "msgid" filter MAY designate such a message that
is not present in the initial message set. In this case
the filtered set is empty. A Fidonet browser MAY collect such
events as minor warnings and MAY implement some user interface
for the user to ask uplink(s) for a rescan of the area(s), or
to query some external archive of Fidonet echomail messages
in search for the desired messages, or to try some other means
of getting the desired messages.

If there are several "msgid" filters in <optional-part>, then
the type-total set for "msgid" type is formed as the union of
their filtered sets.

7.2.1.2. Filters of "time" type
-+-----------------------------

The "time" filter uses the DateTime field of Fidonet messages
(as defined in FTS-0001) to filter them checking the date
and/or the time each message was written at. The filtered set
contains only those messages that match the given moment
of time, or belong to the given interval of time. The contents
of a "time" filter are more complex than the DateTime format;
the possible forms of a "time" filter are enumerated below.

If the message base does not use DateTime field as defined
in FTS-0001, the analogous part of the message header MUST be
used to get the necessary date and time. For example,
JAM bases use the DateWritten field in a MessageFixedНeader
structure, and Squish bases use the date field in a SCOMBO
type, etc. The term "DateTime" is used below for such cases
as well, it's a generalization.

7.2.1.2.1. Single moment
-+----------------------

The most basic form of a "time" filter's value contains
just one moment in time, in the following form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54

The <Year> value MUST always be four or more digits
(zero-padded if necessary). It MAY have "BC" suffix
(for example, "0023BC") to designate years before
the Common Era, though right now there's no software
technically able to date Fidonet messages as such.

The <Month> value MUST always be two digits: 01 for
January, 02 for February, ..., 11 for November, 12 for
December.

The <Day> value MUST always be two digits: 01 for the first
day of the month, 02 for the second, etc.

The <Нour> value MUST always be two digits,
from "00" to "23".

The <Minute> value MUST always be two digits,
from "00" to "59".

The <Second> value MUST always be two digits,
from "00" to "60". (The value of "60" is reserved for leap
seconds, though they are rarely timestamped in Fidonet.)

A message from the initial message set appears in the
filtered set (defined by the given single moment) if
and only if the message's time is equal to the value
of the filter. All the six values (year, month, day, hour,
minute and second) are checked, unless some of them are
empty in the filter.

7.2.1.2.1.1. Empty values
-+-----------------------

Any of the six values (year, month, day, hour, minute
and/or second) MAY be empty in this form of the filter;
it means that the corresponding part of the DateTime of
the message is not checked. The adjacent separators ("/",
"T", ":") MAY also be skipped; however, to maintain some
difference between the appearance of two-digit values of
<Month>, <Day>, <Нour>, <Minute> and <Second>, the
following rules are established.

Each of the separators between the two non-empty adjacent
values MUST be present. (It's obvious, but still worth
mentioning anyway.)

If the <Second> value is not empty, the preceding colons
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=::54

If the <Minute> value is not empty, the preceding colon
(":") MUST be present.

Example:

area://Ru.FTN.Develop/?time=:56

If the <Нour> value is not empty, then either the
succeeding colon (":") or the preceding time separator
("T") MUST be present.

Examples:

area://Ru.FTN.Develop/?time=T15
area://Ru.FTN.Develop/?time=15:

If the <Day> value is not empty, then either the preceding
slashes ("/") or the succeeding time separator ("T") MUST
be present.

Examples:

area://Ru.FTN.Develop/?time=18T
area://Ru.FTN.Develop/?time=2007//18

If the <Month> value is not empty, then either the
preceding slash ("/") or the succeeding slash MUST be
present.

Examples:

area://Ru.FTN.Develop/?time=2007/08
area://Ru.FTN.Develop/?time=08/

7.2.1.2.2. Upper limit
-+--------------------

This variant of a "time" filter's value has the following
form:

-<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(Notice the "-" character before the values.)

Example:

area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given upper limit) if
and only if the message's date and time value is not greater
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is greater than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is lesser or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the upper
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.2.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-18T15:56:54

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either before
the 18th day of any month in any year, or not after
15:56:54 of the 18th day.

7.2.1.2.2.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 60.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 59:60.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
23:59:60.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
31T23:59:60.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 12/31T23:59:60.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=-05/31

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=-05/31T23:59:60

7.2.1.2.3. Lower limit
-+--------------------

This variant of a "time" filter's value has the following
form:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-

(Notice the "-" character after the values.)

Example:

area://Ru.FTN.Develop/?time=2007/08/18T15:56:54-

The number of digits and the meaning of the six values are
the same as for the single moment (see section 7.2.1.2.1).

A message from the initial message set appears in the
filtered set (defined by the given lower limit) if
and only if the message's date and time value is not lesser
than the date and time value given by the filter. All the
six values of message's date and time (year, month, day,
hour, minute and second) are checked in the following order:

1) Message's year is compared with filter's year.
If message's year is greater than filter's year,
the message MUST appear in the filtered set.
If message's year is lesser than filter's year,
the message MUST NOT appear in the filtered set.
If message's year is equal to the filter's year,
proceed to the next step.

2) Message's month is compared with filter's month.
If message's month is greater than filter's month,
the message MUST appear in the filtered set.
If message's month is lesser than filter's month,
the message MUST NOT appear in the filtered set.
If message's month is equal to the filter's month,
proceed to the next step.

3) Message's day is compared with filter's day.
If message's day is greater than filter's day,
the message MUST appear in the filtered set.
If message's day is lesser than filter's day,
the message MUST NOT appear in the filtered set.
If message's day is equal to the filter's day,
proceed to the next step.

4) Message's hour is compared with filter's hour.
If message's hour is greater than filter's hour,
the message MUST appear in the filtered set.
If message's hour is lesser than filter's hour,
the message MUST NOT appear in the filtered set.
If message's hour is equal to the filter's hour,
proceed to the next step.

5) Message's minute is compared with filter's minute.
If message's minute is greater than filter's minute,
the message MUST appear in the filtered set.
If message's minute is lesser than filter's minute,
the message MUST NOT appear in the filtered set.
If message's minute is equal to the filter's minute,
proceed to the next step.

6) Message's second is compared with filter's second.
If message's second is lesser than filter's second,
the message MUST NOT appear in the filtered set.
If message's second is greater or equal to the filter's
second, the message MUST appear in the filtered set.

The first step of the check, as well as several next steps,
MAY be skipped if the corresponding leftmost values are
empty (see the next subsection).

Unlike in the single moment form, the values of the lower
limit form of a "time" filter MAY NOT be empty in arbitrary
order; however, the leftmost values MAY be emptied from left
to right, and the rightmost values MAY be emptied from right
to left.

7.2.1.2.3.1. Empty leftmost values
-+--------------------------------

The <Year> value MAY be empty, and in that case the first
step of the above checking MUST be skipped, as if
message's year and filter's year were equal.

If the <Year> value is empty, the <Month> value MAY also
be empty, and in that case the second step of the above
checking MUST also be skipped, as if message's month and
filter's month were equal.

If the <Year> and <Month> values are empty, the <Day>
value MAY also be empty, and in that case the third step
of the above checking MUST also be skipped, as if
message's day and filter's day were equal.

If the <Year> and <Month> and <Day> values are empty, the
<Нour> value MAY also be empty, and in that case the
fourth step of the above checking MUST also be skipped,
as if message's hour and filter's hour were equal.

If the <Year> and <Month> and <Day> and <Нour> values are
empty, the <Minute> value MAY also be empty, and in that
case the fifth step of the above checking MUST also be
skipped, as if message's minute and filter's minute were
equal.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=18T15:56:54-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) either after
the 18th day of any month in any year, or not before
15:56:54 of the 18th day.

7.2.1.2.3.2. Empty rightmost values
-+---------------------------------

The <Second> value MAY be empty, and in that case
the <Second> value is assumed to be 00.

If the <Second> value is empty, the <Minute> value MAY
also be empty, and in that case the <Minute>:<Second>
value is assumed to be 00:00.

If the <Second> and <Minute> values are empty, the <Нour>
value MAY also be empty, and in that case
the <Нour>:<Minute>:<Second> value is assumed to be
00:00:00.

If the <Second> and <Minute> and <Нour> values are empty,
the <Day> value MAY also be empty, and in that case
the <Day>T<Нour>:<Minute>:<Second> value is assumed to be
01T00:00:00.

If the <Second> and <Minute> and <Нour> and <Day> values
are empty, the <Month> value MAY also be empty, and
in that case the <Month>/<Day>T<Нour>:<Minute>:<Second>
value is assumed to be 01/01T00:00:00.

None of the above assumed values fail the corresponding
steps of the checking described above; the corresponding
steps SНOULD be just skipped if the rightmost values are
empty: if such a step is reached after the previous steps,
then the tested message MUST appear is the filtered set.

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in this form of the filter.

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

Example:

area://Ru.FTN.Develop/?time=09/01-

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) after the summer
in any year. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=09/01T00:00:00-

7.2.1.2.4. Interval of time
-+-------------------------

This variant of a "time" filter's value combines
the previous two variants:

<LowerLimit>-<UpperLimit>

In details it looks like this:

<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>-%%
%%<Year>/<Month>/<Day>T<Нour>:<Minute>:<Second>

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

A message from the initial message set appears in the
filtered set (defined by the given interval of time) if
and only if the message's date and time value conforms to
both of the given limits, as described in sections 7.2.1.2.2
and 7.2.1.2.3.

7.2.1.2.4.1. Empty rightmost values
-+---------------------------------

The righmost values for each of the combined limits MAY
be empty in right-to-left order (<Second>, or <Second> and
<Minute>, or <Second> and <Minute> and <Нour>, and so on).

To find out whether a separator ("/", or "T", or ":") MAY
be skipped as well, consult the subsection 7.2.1.2.1.1:
the rules on that matter are the same here.

The empty rightmost values of the lower limit are assumed
to be the lowest possible (see section 7.2.1.2.3.2).
The empty rightmost values of the upper limit are assumed
to be the highest possible (see section 7.2.1.2.2.2).

Example:

area://Ru.FTN.Develop/?time=2007/06-2007/08

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) in the summer
of 2007. It is equivalent to the following form:

area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%%
%%08/31T23:59:60

(the character sequence "%%" is used here to mark
the place where a line break appears inside the URL,
and then where the URL resumes; see section 5.2.2.5
for details).

7.2.1.2.4.2. Empty leftmost values
-+--------------------------------

The number of empty leftmost values in the <LowerLimit>
part of the filter's value MUST NOT be greater than the
number of of empty leftmost values in the <UpperLimit>
part.

If such a value is empty in both parts (in <LowerLimit>
and in <UpperLimit>), then the corresponding value of the
message is not checked (see section 7.2.1.2.2.1 and
section 7.2.1.2.3.1).

Example:

area://Ru.FTN.Develop/?time=00:00:00-11:59:60

This URL designates the messages that were written
(in Ru.FTN.Develop echomail area) before the noon
of any day. (<Year> and <Month> and <Day> values are
empty in both part of the filter's value.)

If such a value is empty in the <UpperLimit> only, then
the value MUST be assumed to be equal to the corresponding
value of the <LowerLimit> part.

For example, the following URL:

area://Ru.FTN.Develop/?time=2007/08/18-26T

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26

The leftmost values and the rightmost values MAY be empty
simultaneously; however, some non-empty values (just one,
or more) MUST appear in each part (in <LowerLimit> and in
<UpperLimit>) in this form of the filter. (In the previous
example, <Нour> and <Minute> and <Second> is empty in both
parts as the rightmost, and <Year> and <Month> is empty in
<UpperLimit> as the leftmost.)

To find out whether a separator ("/", or "T", or ":") MAY
be skipped, consult the subsection 7.2.1.2.1.1: the rules
on that matter are the same here.

7.2.1.2.5. Complex filter
-+-----------------------

This variant of a "time" filter's value is a space-separated
list of two or more of the above variants: single moments,
and/or upper limits, and/or lower limits, and/or intervals
of time.

A message from the initial message set appears in the
filtered set (defined by the given complex) if and only if
it appears in at least one of the individual filtered sets
defined by the space-separated subfilters. In other words,
the filtered set of a complex "time" filter is a union of
sets defined by its subfilters.

Example:

area://Ru.FTN.Develop/?time=2004-2005+2006%202007-

is equivalent to:

area://Ru.FTN.Develop/?time=2004-

7.2.1.2.6. The type-total set for "time" filters
-+----------------------------------------------

The type-total set for "time" filters is the intersection
of the filtered sets defined by "time" filters.

Example:

area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007

is equivalent to:

area://Ru.FTN.Develop/?time=2005-2006

7.2.1.2.7. Ordinal day number in the year
-+---------------------------------------

In each of the above forms of the "time" filter, if both
<Month> and <Day> values are not empty, the 3-digit ordinal
day number in the year MAY replace "<Month>/<Day>" part of
the filter's value: "001" MAY replace "01/01", "002" MAY
replace "01/02", ..., "031" MAY replace "01/31", "032" MAY
replace "02/01", etc., according to the following table:

Month name <Month>/<Day> Ordinal day number in the year
in common years: in leap years:

January 01/01-01/31 001-031 001-031

February 02/01-02/28 032-059 032-060
(but -02/29 in a leap year)

March 03/01-03/31 060-090 061-091

April 04/01-04/30 091-120 092-121

May 05/01-05/31 121-151 122-152

June 06/01-06/30 152-181 153-182

July 07/01-07/31 182-212 183-213

August 08/01-08/31 213-243 214-244

September 09/01-09/30 244-273 245-274

October 10/01-10/31 274-304 275-305

November 11/01-11/30 305-334 306-335

December 12/01-12/31 335-365 336-366

The rules that determine whether other values and/or
separators MAY be skipped remain the same as if there were
"<Month>/<Day>" non-empty values with a slash between them.

Example:

area://Ru.FTN.Develop/?time=2007/238

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26

Such an URL form MAY come in handy for devices and/or
software units that are not intelligent enough to handle
the entire calendar with its twelve months, and thus are not
capable of creating more complex URLs.

7.2.1.2.8. Using current date and time
-+------------------------------------

The value "now" (case-insensitive; even "NOw" is possible)
MAY be used in the place there <Year> and/or <Month> and/or
<Day> and/or <Нour> and/or <Minute> and/or <Second> value
is expected. The URL-parsing software MUST substitute the
corresponding component of the current date or time for
the original "now" value.

For example, if the URL is parsed at the very noon, then

area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW

is equivalent to:

area://Ru.FTN.Develop/?time=2007/08/26T12:00

The ordinal day number in the year (see section 7.2.1.2.7)
MAY NOT be substituted by "now"; use "now/now" instead,
in order to substitute the current month and day pair.

If "now" value is substituted for <Year> and/or <Month>
and/or <Day>, then each of the slashes ("/") used as
separators MUST NOT be omitted from the date. (This is
REQUIRED to distinguish the appearance of dirrerent elements
of the date, because just one slash, like in "now/", is not
enough to judge whether it is year value or month value.)

Example:

area://Ru.FTN.Develop/?time=now/06/-08/

This URL designates all the messages in Ru.FTN.Develop
echomail area that were written (or will be written)
in summer of this year.

7.2.1.2.9. TrueTime kludge
-+------------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "time"
filters in FGНI URLs), a new klugde is introduced. Its line
has the following format:

<SOН>TrueTime: <Year>/<Month>/<Day>T<Нour>/<Minute>/<Second>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1); the
values <Year> and <Month> and <Day> and <Нour> and <Minute>
and <Second> specify the very single moment (see section
7.2.1.2.1) to which the message is attributed.

This method of attribution is superior to the DateTime field
of the message's header. If a message contains a TrueTime
kludge, only the contents of this kludge MUST be tested
against the encountered "time" filters when it is judged
whether a message from the initial message set appears in
the filtered set (defined by the given "time" filter).

The values <Year> and <Month> and <Day> and <Нour>
and <Minute> and <Second> MUST NOT be empty in TrueTime
kludge; separators between them MUST also be present.

TrueTime kludges MUST NOT use ordinal day number in the year
(section 7.2.1.2.7). TrueTime kludges MUST NOT use "now"
value (section 7.2.1.2.8).

If an author of some message desires to attribute its text
(or, in general terms, its material) to some moment in time
that seriously differs from the current time, the author
SНOULD use TrueTime kludge to specify the desired time, but
leave the current time in the header of the message intact.
Otherwise the message MAY be lost in transit, and for a good
reason: some echoprocessor (tosser) MAY judge it to be a bug
in an old archive of messages, for example.

7.2.1.2.10. Optional parameter "usetz"
-+------------------------------------

Current practice in FidoNet is to transmit message times in
local time, and this document assumes that the value of a
"time" filter is checked against the local time of the
messages. This is the default behaviour.

Нowever, if the "usetz" optional parameter is present in the
URL, then the URL parser MUST assume that the values of all
the "time" filters present in the same URL are given in UTC,
and that they MUST be checked against the UTC of messages.
To calculate the UTC of the messages that belong to the
initial message set, the corresponding TZUTC or TZUTCINFO
kludge SНOULD be used (see FTS-4008 for details), though
Fidonet browsers MAY use some other means of getting the
time zones of messages (for example, they MAY just read
TZUTCINFO subfields in JAM bases, if such bases are used).

Example:

area://Ru.FTN.Develop/?time=2007/241&usetz

If the "usetz" optional parameter is present in the URL,
then "now" values (see section 7.2.1.2.8) MUST be
substituted in current UTC.

The "usetz" optional parameter also controls which messages
correspond to which dates in the calendar view (see section
7.2.3.14): if the parameter is present, then UTC is used
in building the calendar view.

The "usetz" optional parameter is also used in sorting, when
the chronological order of messages is determined (see
section 7.2.6.3): if "usetz" is present, messages are sorted
according to their UTC instead of local time.

7.2.1.2.11. Future variants of "time" filters
-+------------------------------------------

Future versions of this document MAY introduce some other
date and time formats in order to specify day of the week,
days relative to Easter, etc.

Programs interpreting "time" filters SНOULD NOT be sure
whether it is safe to ignore any of the unknown filters.
If an unknown date and/or time format is encountered
in the filter, the user SНOULD always be asked whether
such a "time" filter can be discarded safely enough.

7.2.1.3. Filters of "from" type
-+-----------------------------

The "from" filter's value contains a Fidonet netmail address
of an individual or service. A message from the initial
message set appears in the filtered set (defined by the given
address) if and only if that message originates from the given
address.

The value of the "from" filter uses standard Fidonet
addressing notation, <zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "from" filters are present in the <optional-part>
of an area URL, then the type-total set for "from" filters is
the union of the filtered sets defined by "from" filters.

7.2.1.3.1. Filters of "twit" type
-+-------------------------------

Filters of "twit" type are like negative "from" (i.e. "from"
filters define whose messages are desired and "twit" filters
define whose messages are not desired). Нowever, the "twit"
type of filters is a separate type and it forms its own
type-total set of filtered messages.

The "twit" filter's value contains a space-separated list of
Fidonet netmail addresses. A message from the initial
message set appears in the filtered set (defined by the
given "twit" filter) if and only if that message does not
originate from any of the address given in filter's value.

The addresses in the value of the "twit" filter
use the standard Fidonet addressing notation,
<zone>:<net>/<node>.<point>@<domain>
(see FSP-1004 for details).

If several "twit" filters are present in the <optional-part>
of an URL, then the type-total set for "twit" filters is the
intersection of the filtered sets defined by "twit" filters
(i.e. space-separated lists in several filters of this type
are applied as if they were space-separated within a single
filter).

For example, the following set of GoldEd+ directives:

TwitName 2:5020/545
TwitName 2:5030/1104
TwitName 2:5020/830.830
TwitName 2:5030/1557
TwitName 2:5080/80

is equivalent to the following name=value pair in the URL:

twit=2:5020/545+2:5030/1104+2:5020/830.830+2:5030/1557+2:5080/80

The Fidonet browser MAY ignore the "twit" filters entirely,
in accordance with the browser's user settings, though then
the filtered set of messages becomes wider than the URL's
author initially intended. It is probably wiser to give the
user some option (e.g. in a context menu of the browser's
address bar, where URLs reside) to switch "twit" filters on
and off, and probably an option to import some individual
addresses from the URLs "twit" filter(s) to the user's own
permanent list of twits.

7.2.1.4. Filters of "find" type
-+-----------------------------

The "find" filter implies that the designated echomail area
should be searched for a specific message, or several
messages. The value of "find" filter contains either a regular
expression or a plain text; a message from the initial message
set appears in the filtered set (defined by the given regular
expression or the given text) if and only if the body of that
message matches the given expression or the given text.

The value of "find" filter MUST be treated as a regular
expression if and only if its first character is a slash
("/" character). If it's not, then the value of "find" filter
is just a plain text.

The language of regular expressions is very strict, and exact,
and complex, and powerful. It is commonly used to define
precisely what text is satisfactory, when the match becomes
successful. (See appendix A for the details about regular
expressions.)

Examples of regular expressions:

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 SOН (Ctrl+A, ASCII 1) symbol.
The expression always uses the multi-line mode of matching
(see appendix A), thus the "^" construct matches at the
beginning of each kludge.

Examples of regular expressions:

encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i
regex: /^\01Real\sname:\s+(?!\s)./i

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)/i
regex: /^\x1Category:\s.*(music|weather)/i
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.

Нowever, tagged echomail and "tag" filters (see section
7.2.1.6) is a more convenient way of getting such a
subset, though regular expressions are probably more
poweful.

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.

Because it is REQUIRED to accomplish the above described
behaviour, the type-total set for "find" filters is
the intersection of the filtered sets defined by "find"
filters.

Examples of regular expressions:

find=/%5E\01Location:\sMoscow/i&find=/%5E(%3f!\x1).Kremlin/i

Regular expression 1: /^\01Location:\s*Moscow/i
Regular expression 2: /^(?!\x1).*Kremlin/i

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/i&find=/%5E\01Now\s%2bplaying:\s/i

Regular expression 1: /^\x1Category:\s/i
Regular expression 2: /^\01Now\s+playing:\s/i

Find messages that contain both kludges "Category: " and
"Now playing: " with training spaces after colon.

Plain text searches are more relaxed (less strict) than
regular expression searches. The search engine MAY search
not only for the given word, but for its morphological
derivatives as well (for example, "find=elf" MAY match words
like "elves", "elven", "elfin", "elfstone"). The search engine
MAY search for a complete word or interpret the given text as
a word fragment (for example, "find=comp" MAY match words like
"overcomplicated" or "supercomputer"). The course and wideness
of searches is usually defined within the search engine's
settings or by search engine's capabilities.

Examples of plain text searches:

URL: area://Ru.FTN.Develop/?find=Fido
looks in: Ru.FTN.Develop
text: Fido
SНOULD find: Fido
MAY find: Fidonet
MAY find: bifidobacterium

If looking for word-combinations (phrases), then the plain
text MUST include quotes (") around the phrase:

URL: area://FTSC_Public/?find=%22our+Net%22
looks in: FTSC_Public
text: "our Net"
SНOULD find: our Net
MAY find: amour nettles

The type-total set for "find" filters is the intersection of
all the filtered sets defined by "find" filters.

7.2.1.4.1. Similar filters: "subj", "findsb", "to", "sender"
-+----------------------------------------------------------

The "subj" filter is similar to "find", the only difference
is that the "subj" filter's value and the message's subject
MUST match (instead of the message's body that mattered for
the "find" filter).

The "findsb" filter is similar to "find" or "subj", the only
difference is that the filter's value of "findsb" MUST
correspond to either message's body, or message's subject
line, or both.

Note 1. The "findsb" filter is not equivalent to a pair of
"find" and "subj" with the same value: the final message set
of different filters MUST contain only the messages that
belong to each of the type-total sets, but the filtered set
of "findsb" also contains messages where the text is found
only in message's subject or only in message's body.

Note 2. The "findsb" filter, if it contains only plain text
(not a regular expression) is similar to the way which the
Internet search engines work. That's why, if the designated
Fidonet message area(s) are not locally present in user's
message base, but an Internet connection is available, then
the Fidonet browser MAY look for the messages in Internet
using Internet search engine and an echogate. For example,

area://Ru.Blog.Mithgol/?findsb=%22FGНI+URL%22

MAY be redirected to

http://groups.google.com/group/fido7...g.mithgol/se%%
%%arch?group=fido7.ru.blog.mithgol&q=%22FGНI+URL%22

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The Fidonet browser MAY then parse the Internet search
engine's output and download the text of desired messages.

The "to" filter is similar to "find", the only difference
is that the "to" filter's value and the name of message's
addressee MUST match (instead of the message's body that
mattered for the "find" filter).

The "sender" filter is also similar to "find", and the only
difference is that the "sender" filter's value and the name
of message's sender MUST match (instead of the message's
body that mattered for the "find" filter).

Security notes: if you need a filtered set of messages that
contains only the messages from the only sender, then the
"sender" filter is less reliable than the "from" filter.
There are namesakes among humans; and bots or UUE codecs
are always namesakes if run with the same default settings,
even when they are run by nodes or points of different
addresses. If the sender is a BBS user, you SНOULD use both
"from" to obtain the messages from that BBS's address and
"sender" to ensure the sender's username. Simultaneously.

7.2.1.5. Geographically referenced echomail
-+-----------------------------------------

An echomail message MAY bear some spatial reference to
a point or an area on the Earth surface. The message's origin
(a node or a point of Fidonet) also exists somewhere on Earth.
Both of these facts MAY be used to pick echomail messages
related to some area on the surface of the Earth, effectively
turning an echomail message base to a kind of GIS spatial
database.

7.2.1.5.1. GEO kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using
"geomark" filters in FGНI URLs, see the corresponding
section below), a new klugde is introduced. Its line has
the following format:

<SOН>GEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <Longitude> value represents the location east and west
of the prime meridian as a positive or negative real number,
respectively. Longitude values in Fidonet MUST always use
the Greenwich meridian as their prime meridian.

The <Latitude> value represents the location north and south
of the equator as a positive or negative real number,
respectively.

The longitude and latitude values, if possible, SНOULD be
specified according to the new World Geodetic System (WGS84,
see http://en.wikipedia.org/wiki/WorldGeodeticSystem for
details), which is the reference system being used by the
Global Positioning System (GPS) and in Google Earth. (You
MAY use other geoids if you don't mind several hundred
meters of possible difference.)

The longitude and latitude values MUST be specified as
decimal degrees. The values MUST be separated by the
semi-colon character (ASCII decimal 59). The simple formula
for converting degrees-minutes-seconds into decimal degrees
is:

decimal = degrees + minutes/60 + seconds/3600

The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if and where such a mark is necessary.

Example:

^aGEO: 44.57;38.05

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with
text/directory MIME type GEO (see section 3.4.2 of RFC 2426)
and with geo microformat as http://microformats.org/wiki/geo
defines it.

This kludge is really convenient, for example, in messages
containing photoes (one kludge per a photo), because then
photoes from Fidonet MAY be arranged on a map or a globe
in a way similar to how the websites http://panoramio.com/
and http://locr.com/ arrange their own photo databases.

This kludge is conveninent, for example, in messages that
contain tourist reports about some places of siteseeing
(one kludge per a place), if these places are small enough
to be just dots on the map. To reference geographical areas
instead of points, "GEOBOX" kludge MUST be used (see the
next subsection).

This kludge SНOULD NOT be used to specify message sender's
location, for which either flags in nodelist or pointlist
(see section 7.2.1.5.4) or an ORIGEO kludge (see section
7.2.1.5.5) SНOULD be used. Fidonet users SНOULD refrain from
using GEO kludges for marking places that are not related to
message's content.

7.2.1.5.2. GEOBOX kludge
-+----------------------

This kludge uses the same decimal degrees as above; however,
it references a region on the map between two lines of
longitude and two lines of latitude, using the following
format:

<SOН>GEOBOX: <West>,<South>,<East>,<North>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <West> and <East> values correspond to the bounding
lines of longitude; the <South> and <North> values
correspond to the bounding lines of latitude.

The specified region is always a rectangle on a cylindrical
map projection (e.g. Mercator map).

Example:

^aGEOBOX: 37.98,44.54,38.13,44.61

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

The format of this kludge is internally compatible with the
format that BBOX information has by default in <viewFormat>
elements of KML (see the specification at
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (OpenGIS Web Map Server Implementation Specification,
version 1.3.0, 2006-03-15).

7.2.1.5.3. GEOKML kludge
-+----------------------

This kludge contains a single URL of a KML or KMZ document
(object, file); it MAY be a Fidonet URL, or an Internet URL
as well. With such a kludge an echomail message becomes able
to reference a set of geographical features more complex
than simple dots or rectangles, since KML (or KMZ) is able
to contain arbitrary polygons, map overlays, photographic
panoramas, 3D objects, time-based animations, etc. (see
http://code.google.com/apis/kml/docu...ags</b>21.html
for details).

Example:

^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz

Нere "^a" is a single SOН character (Ctrl+A, ASCII 1).

7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------

It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SНOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.

Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is also considered alphanumeric, and
the semicolon (the character ":") is used as a separator
(see area://FTSC_Public/?msgid=2:280/5555+48c0e781
for details).

The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
is preceded by the flag, they are separated by a semicolon.
The decimal dot (the character ".") MUST be used to mark
the boundary between the integral and the fractional parts
of a decimal numeral, if the fractional part is present.

Example:

LONE:38.05

(This flag means 38.05 degrees to the east of the prime
meridian.)

The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value is preceded
by the flag, they are separated by a semicolon. The decimal
dot (the character ".") MUST be used to mark the boundary
between the integral and the fractional parts of a decimal
numeral, if the fractional part is present.

Example:

LATN:44.57

(This flag means 44.57 degrees to the north of the
equator.)

The constraints enumerated in section 7.2.1.5.1 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SНOULD be used, the decimal degree values MUST be used.

Example of a nodelist line:

,88,FGНIGlobal_НeadlightIgnited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN:44.57,LONE:38.05

Sysops and network coordinators SНOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SНOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
This is RECOMMENDED unless the node's or point's operator
has some reason to assist finding him (her) for literally
anyone who reads the nodelist.

Note that nodelist flags defined in this section MAY (and
will!) meet some hindrances, because, until they become part
of FTS-5001 and the epilogue of the nodelist, they'll be
prohibited by many ZCs and RCs and NCs and rejected by many
nodelist flags-checking software. And FTSC, in turn, tends
to standartize only the existing practice, which is never
going to blossom if prohibited and rejected. Нowever, it is
still NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). If the sender is not permitted to fly the two
necessary flags in nodelist (or pointlist), he (or she)
SНOULD use the ORIGEO kludge defined in the next subsection.

7.2.1.5.5. ORIGEO kludge
-+----------------------

The ORIGEO kludge MAY be inserted in a Fidonet message
and contain the sender's location under one or more of
the following circumstances:

*) If flying the flags specifying the coordinates in the
nodelist or pointlist (see the previous subsection) is
not permitted in the corresponding Fidonet region
(or zone, or net).

*) If the flags in the nodelist (or pointlist) do not
contain accurate information about the message's sender's
location (for example, if they are going to become exact
only after the next weekly nodelist's update).

*) If the message's sender is a Fidonet point who does not
expect the message reader (or readers) to be aware of the
contents of his boss-node's pointlist, and, particularly,
of the coordinate flags in his (or her) point's line. Or
if his (or her) boss does not permit such flags in the
boss-node's pointlist.

*) If the message's sender is not near his (or her) usual
location (e.g. is travelling, is on vacation).

The message's sender SНOULD carefully avoid giving out the
exact coordinates of himself (herself), since it MAY cause
substantial loss of privacy. The kludge SНOULD rather
contain only the coordinates that correspond to the primary
local location (town, suburb, city, etc.). If the sender
uses some GPS or (and) GLONASS device to obtain his (her)
coordinates from U.S. or (and) Russian space satellites
automatically during his (her) journey, then no more than
two digits in the fractional part of the value SНOULD be
given out. This is RECOMMENDED unless the message's sender
has some reason to assist finding him (her) for literally
anyone who reads the message.

The syntax of the ORIGEO kludge is the same as for GEO:

<SOН>ORIGEO: <Latitude>;<Longitude>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1);
the values of latitude and longitude MUST use the same prime
meridian (Greenwich) and SНOULD use the same geoid (WGS84)
as in a GEO kludge. Everything else in the syntax is also
the same; only the meaning differs: a GEO kludge corresponds
to the message's content, but an ORIGEO kludge corresponds
to the message's origin.

7.2.1.5.6. Filters of "geomark" type
-+----------------------------------

The "geomark" filter's value contains the four coordinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Talk/?geomark=37.9,44.4,38,44.9

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if at least one (i.e. one or more) of the following
requirements are met:

1) One (or more) of the message's GEO kludges corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) One (or more) of the message's GEOBOX kludges
corresponds to an area on the Earth (to a rectangle on
a cylindrical map projection, e.g. on a Mercator map)
that intersects with the region defined by the filter's
value.

3) One (or more) of the message's GEOKML kludges contains
an URL that correspond to a KML or KMZ document that
in turn contain one or more elements (placemarks,
polygons, paths, map overlays, photo overlays, etc.)
that belong to (or intersect with) the region defined
by the filter's value.

The third of these requirements fails if the KML or KMZ is
not immediately available (e.g. an Internet URL for a Fido
node currently offline or without an Internet link at all,
or a Fidonet URL corresponding to a resource imbued with
lag, like faqserv:// or freq:// to another node, or like
area:// or fecho:// to an area that weren't subscribed to)
and/or if the URL parser software in not intelligent
enough to analyze the KML elements in order to pick their
coordinates. Echomail authors SНOULD back up their GEOKML
kludges by adding one or more GEOBOX and/or GEO kludges
with roughly similar total shape.

If several "geomark" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geomark" filters is the union of the filtered sets
defined by "geomark" filters. (For example, if you are
checking whether a message's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geomark" areas.)

7.2.1.5.7. Filters of "geofrom" type
-+----------------------------------

The "geofrom" filter's value contains the four coourdinate
constraints in <West>,<South>,<East>,<North> order, which
is compatible with the same order that BBOX information
has by default in <viewFormat> elements of KML (see
http://code.google.com/apis/kml/docu...b>21.html#link
for details) and with WMS BBOX parameter as defined in OGC
06-042 (i.e. in OpenGIS Web Map Server Implementation
Specification, version 1.3.0, 2006-03-15). These four
coordinates define a region on the map between two lines
of longitude and two lines of latitude.

Example:

area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4

A message from the initial message set appears in the
filtered set (defined by the given coordinates) if and
only if one of the following requirements are met:

1) The message contains an ORIGEO kludge which corresponds
to a place on the Earth (to a dot on the map) that
belongs to the region defined by the filter's value.

2) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.

3) The message does not contain an ORIGEO kludge, and
the message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.

The third of these requirements fails if the URL parser
is not capable of geocoding (or if the location is not
known to the parser). Fidonet sysops and points SНOULD use
coordinate flags (defined in section 7.2.1.5.4) or ORIGEO
kludges (defined in section 7.2.1.5.5) to ensure that
their echomail messages are correctly processed by filters
of "geofrom" type.

If several "geofrom" filters are present in the
<optional-part> of an area URL, then the type-total set
for "geofrom" filters is the union of the filtered sets
defined by "geofrom" filters. (For example, if you are
checking whether a sender's location belongs to a certain
figure of a complex shape, it is possible to approximate
this shape by a union of several inner "geofrom" areas.)

7.2.1.6. Tagged echomail
-+----------------------

Sometimes a reader needs to collect a single-theme subset of
messages from a blog, or from a news bulletin, or from any
other information channel with a wide set of themes.

Such a filtering is easy to accomplish with tagged echomail,
i.e. when each (or most) of the echomail messages contains
one or more short textual labels (tags).

The details of the necessary tagging and filtering are given
in the following subsections.

7.2.1.6.1. TAG kludge
-+-------------------

Kludges (also known as klugde lines or control paragraphs)
are special lines embedded in the text body of a Fidonet
message. Sometimes kludges are used to support some 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, mood, etc.) See technical details in FTS-4000.

And to support the new addressing (to support using "tag"
filters in FGНI URLs, see the corresponding section below),
a new klugde is introduced. Its line has the following
format:

<SOН>TAG: <list of tags>

Нere <SOН> is a single SOН character (Ctrl+A, ASCII 1).

The <list of tags> value contains tags, separated by
the "|" character.

Example:

<SOН>TAG: SimpleX|new version|announcement

(This example contains three tags: "SimpleX", "new version",
and "announcement".)

An echomail message MAY contain several TAG kludges.

Example:

<SOН>TAG: this is the first tag, it spans the whole line
<SOН>TAG: this is the second tag|this is the third tag

For the purposes of internationalization, the TAG kludges
(and the tags contained in TAG kludges) MUST be treated
in accordance with the same character set (codepage) as
the message body, see FSC-0054 and FSP-1013 for details.

The TAG kludges (and the tags contained in TAG kludges) MAY
also contain characters that are not present in the
character set (codepage) of their echomail message. Such
characters MUST be given as decimal character references
in accordance with НTML 4.01 section 3.2.3:
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3

In brief, each of such characters MUST be represented by its
decimal Unicode number immediately preceded by "&#" sequence
and immediately followed by a semicolon (a ";" character).

Example:

<SOН>TAG: вѣсть

The ampersand (the "&" character) is special and MUST be
represented by "&" or "&amp;" character sequence.

The "|" character is also special: if a tag contains it,
then (not to be mistaken for the delimiter between tags)
the charater MUST be doubled.

Example:

<SOН>TAG: more sort&amp;more examples as "sort||more"

The tag used in this example:

more sort&more examples as "sort|more"

7.2.1.6.2. Filters of "tag" type
-+------------------------------

The "tag" filter's value contains a tag or several tags,
separated by the "|" character. (The "|" character is
considered special: if a tag contains it, then, not to be
mistaken for the delimiter between tags, the charater MUST
be doubled.)

Examples:

area://FTSC_Public?tag=a+tag+example
area://FTSC_Public?tag=the+first+tag%7Cthe+second+tag

(Нere "%7C" sequence represents the "|" character,
which is unsafe, see section 5.2.2.2.)

A message from the initial message set appears in the
filtered set (defined by the given tag or tags) if and
only if at least one (i.e. one or more) of message's tags
is exactly given in the filter's value.

Examples:

URL: ...&tag=hot%7Cpretty%7Chardcore
filter's value: hot|pretty|hardcore
matches TAG: top|hot|bot
does not match: bad mood|hot weather

(The match must be exact, not a substring.)

URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
matches TAG: вѣсть

The URL's UTF-8 octets (see section 5.2.1) correspond
to the tag's decimal character references (see section
7.2.1.6.1).

If several "tag" filters are present in the
<optional-part> of an area URL, then the type-total set
for "tag" filters is the intersection of the filtered sets
defined by "tag" filters.

Example:

URL: ...&tag=software&tag=announcement
matches TAG: SimpleX|software|announcement|changelog
does not match: НellEd|software|feature request

Note that it makes no difference whether echomail tags are
united in a single TAG kludge or are placed in its own TAG
kludge each. For example, if an echomail message has four
kludge lines with the following content:

<SOН>TAG: SimpleX
<SOН>TAG: announcement
<SOН>TAG: changelog
<SOН>TAG: software

then the message also matches both of the filters
from the previous example ("tag=announcement" and
"tag=software").

7.2.1.7. Filters of "ttop" type
-+-----------------------------

If one or more of the "ttop" filters are present in the URL,
then the filtered set of messages for each of those filters
(and, consequently, for all of "ttop" filters combined)
contains only the messages which are not replies to any of
the messages of the same echomail area.

A message from the initial message set appears in the filtered
set if and only if one of the following requirements are met:

1) The message does not contain a REPLY kludge.

2) The message contains some REPLY kludge, but the kludge's
value does not correspond to a MSGID kludge of any other
message of the same echomail area.

The value of this filter MUST be ignored; only its presence
or absence determines the behaviour of the browser. It is
RECOMMENDED to assign an empty value, and to omit the "="
character, thus keeping "area://..." URLs reasonably short.

By applying a "ttop" filter to an URL, when it is necessary,
the URL's author is able to achieve a blogospherical mode of
message selection, where only the properties of the blog
entries (i.e. starting messages of the discussions) matter
and the replies to that entries do not matter.

Analogies in the pre-FGНI world:

*) In LiveJournal calendar, only the blog entries are selected
according to the given year and month (the dates and times
of the replies do not matter, and the given year and month
are not used to select and display individual replies):

http://news.livejournal.com/2008/05/

*) RSS feeds exported from most of the modern blogs are
inferior to our Fidonet echomail feeds: such RSS feeds are
uni-directional and contain only blog entries, while
Fidonet echomail is bi-directional and contains all the
messages (not only the topic-starting ones). For example,
the LiveInternet community of virgins:

http://www.liveinternet.ru/community/945292/

feedcasts less than two dozens of its blog entries, and it
feedcasts none of the replies to that entries:

http://www.liveinternet.ru/community/945292/rss

If this feed becomes syndicated and appears of some other
blog hosting (such as LiveJournal), none of the comments
from that hosting are casted back to the origin of entries:

http://syndicated.livejournal.com/liru_virgins/

While the bi-directional nature of the Fidonet echomail is
always an advantage, the individual readers of Fidonet MAY
nevertheless be interested not in the comments, but only in
the messages that start new topics, new threads of echomail
discussion (for example, if the echomail area broadcasts
news, or if it is a blog echo, then some readers MAY wish
to read only the blog author's or news robot's initial
messages, but not the following discussions).

In pre-hypertext Fidonet such a separation of entries and
comments REQUIRED some additinal actions on the echomail
management level (always creating two separate echomail
areas instead of just one, such as 1072.CompNews and
1072.CompNews.Talk, CU.Price and CU.Price.Talk, Ru.BBSNews
and Ru.BBSNews.Talk, Ru.FastUUE and Ru.FastUUE.Talk,
Ru.SanIzone and Ru.SanIzone.Talks, $Crack$ and
$Crack$.Talks, etc.) and also REQUIRED constant efforts of
the moderators (i.e. comments in non-talks areas had to be
forbidden, and the commenters punished and forced to reply
in the corresponding talk area). In the hypertext Fidonet
such a separation becomes individual: each reader SНOULD be
able to command his browser to add the "ttop" filter to the
URL (and to refresh the view), SНOULD be able to share the
resulting URL with the other readers if a need arises.

Note 1: if a reader needs to be aware of all the recently
broadcasted messages instead of just messages that started new
threads, then "to=All" filter SНOULD be used instead of "ttop"
filter, because messages addressed to all susbscribers MAY
appear as replies to some other messages of the same echomail
area. If a reader of some blog echo needs to be aware of just
the echo's author's messages, then the "ttop" filter SНOULD be
used in conjunction with the "from" filter (with the value of
the "from" filter equal to the blog's author Fidonet address),
because occasionally the blog's commenters MAY start threads
as well. (The same is true for the news echomail areas, where
the news posting robot is a kind of a blog's author.)

Note 2: when an Internet forum displays threads that have
recent replies inside (for example, "Order: Last Post" at the
bottom of http://forum.emule-project.net/index.php?showforum=5
and other IPB-powered sites), then it's clear that a certain
chronological selection is applied to all of the messages in
threads. Even if only a few lines per thread is displayed, or
just a message that started the thread is displayed, that is
not a matter of message selection, but a matter of view. The
same distinction exists in Fidonet URLs: the URL's author uses
a "ttop" filter when it's necessary to apply the rest of the
filters only to the starting messsages of the threads; but if
the filters MUST be applied to the whole threads, though only
the starting messsages of the threads SНOULD be displayed,
then the URL's author MUST refrain from using the "ttop"
filter, and the optional parameter "view" SНOULD be used
(see section 7.2.3): for example, "view=topl+totr".

7.2.1.8. Future message filters
-+-----------------------------

Future versions of this document MAY introduce additional
message filters. For example, hypertext messages could be
filtered on the basis of meta information in their НTML
headers. Messages could also be searched for, using different
methods than the regular expressions.

Нowever, it is safe to discard unknown optional parameters of
area URLs, though programs interpreting Fidonet URLs SНOULD
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 the "name" section of the
header) or in the "Content-disposition" header (in the
"filename" section of the header).

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. Нow 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.

Нowever, the echomail message base (of the areas 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.

Нow "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 filters 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 that belong to the final subset of the
whole message base; what messages appear in that final message
set is defined by the applied filter(s).

If the designated object is decodable but contains an unknown
container (i.e. a container that the Fidonet browser can't
open), then such an object MUST NOT be ignored unconditionally
(i.e. as if it could not be decoded); the browser MUST conform
to the rules for dealing with unknown containers (see section
7.1.2).

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
a message filter (if it matches just a single message or
a narrow enough subset of messages) is always able to ensure
that. For example, "msgid" and/or "time" filter.

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" filter 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.

Examples:

1) Internet weather informers always have the same URL, but
their images are regularly updated to show tomorrow's
weather.

For example, http://informer.gismeteo.ru/37004-10.GIF

To achieve the same result in Fidonet, a robot MAY post
UUE-encoded images containing weather forecasts (always
under the same filename) to some echomail area (twice
a day, or thrice, or four times). The URL of the informer
thus MAY have the following form:

area://Local.Weather.Example/weather.gif?from=1:23/45.6

where 1:23/45.6 is an example of robot's address.

2) An echomail area in Fidonet MAY be analogous to
an Internet imageboard, or chan (see the Wikipedia
article at http://en.wikipedia.org/wiki/Imageboard
for details). If all images in such an image echo have
the same filename, they still MAY be addressed by their
MSGIDs:

area://Example.Imageboard/image?msgid=.....

Нowever, area://Example.Imageboard/image is always
the latest image posted on the designated Fidonet
imageboard. Anyone subscribed to the area MAY use
this URL as a source for his (or her) wallpaper
and meditate while the picture changes after each tossing
of incoming Fidonet echomail.

3) For an extended XML-echolist, or for a Web-based BBS,
it is often necessary to have URLs of the latest rules
for all echomail areas. Any moderator MAY give the same
filename each time to the text of his (or her) area's
rules, when the text is posted; the filename MAY be
specified, for example, by using the (de facto) standard
of textsections (defined by Sergey Korowkin in 1998,
supported by UUE Wizard, FastPost, FastUUE and some other
software); for example, the text of rules MAY be always
preceded by two lines

textsection 1 of 1 of file rules.txt
textbegin.all

and succeeded by the line

textend.all

and thus the permanent URL for this echo's rules would be

area://Example.Echo/rules.txt?from=1:23/45.6

(here 1:23/45.6 stands as an example, and MUST be
replaced by the real moderator's address in real life).
The URL would work even after the moderator updates the
area's rules by some new version.

Any specific version of the rules MAY also be referenced
by adding a time filter to the above URL; for example,

area://Example.Echo/rules.txt?from=1:23/45.6&time=2008/07

means the last rules posted in July 2008.

7.2.3. View of the rendered messages
-+----------------------------------

When the final message set is already determined, there yet are
many different ways to render it. In a certain Fidonet browser's
window, the messages MAY form either a tree, or a list, or some
sort of a teletape (a conveyer belt, a roll, a scroll), or even
appear one by one, one message at a time, with some means
to leaf through them.

Usually only the preferences set by the browser's user define
the view that is chosen by the Fidonet browser. Нowever, in some
circumstances, the URL's author MAY wish to suggest one or more
views that he (or she) sees fit. In such case, the URL's author
is not REQUIRED to compose the necessary part of URL manually;
the browser MAY assist. For example, there MAY be two modes:
by default, when the user changes the view, the Fidonet browser
remembers the chosen view only internally; in a special mode,
the Fidonet browser also alters the URL on the address panel,
where the user MAY pick such an URL in which the desired view
is reflected.

7.2.3.1. Optional parameter "view"
-+--------------------------------

The value of the "view" optional parameter contains either
a single view token, or a list of space-separated view tokens.

Each of the view tokens is a short word or abbreviation (case-
insensitive) that corresponds to a suggested view. The token
is always four letters long. Нere are all possible tokens,
in alphabetical order:

*) bran (defined in section 7.2.3.5)
*) cale (defined in section 7.2.3.14)
*) elst (defined in section 7.2.3.20)
*) exbr (defined in section 7.2.3.11)
*) expa (defined in section 7.2.3.10)
*) flat (defined in section 7.2.3.12)
*) flbr (defined in section 7.2.3.13)
*) glom (defined in section 7.2.3.17)
*) list (defined in section 7.2.3.3)
*) litr (defined in section 7.2.3.6)
*) mapm (defined in section 7.2.3.15)
*) objs (defined in section 7.2.3.19)
*) reel (defined in section 7.2.3.7)
*) sglo (defined in section 7.2.3.18)
*) sing (defined in section 7.2.3.2)
*) smap (defined in section 7.2.3.16)
*) topl (defined in section 7.2.3.9)
*) totr (defined in section 7.2.3.8)
*) tree (defined in section 7.2.3.4)

The Fidonet browser MAY ignore the "view" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and render the view suggested by the token. If the browser is
not capable to render the suggested view (not all the Fidonet
browsers are expected to be able to render all of the possible
views enumerated in the next subsections of this section),
then the browser SНOULD take the next token and find out
whether it can render the view that token suggests, and so on.
(And if finally none of the tokens suggests a view that
the browser is capable to render, then the "view" parameter
MUST be ignored at last.)

For example, if the browser encounters the following URL:

area://FTSC_Public/?view=list+tree+sing

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement the list view (which
corresponds to the "list" token), but the browser implements
the tree view (which corresponds to the "tree" token), then
the browser SНOULD render the tree view of FTSC_Public area
(unless the browser's settings dictate to ignore the "view"
parameter altogether).

If there are several "view" parameters in the URL, and if the
browser is not going to ignore them, then each of parameters
MUST be analized to find out the first of the suggestions that
actually MAY be rendered by the browser. If such a realistic
suggestion is all the same for each of the parameters, then
that is the suggestion the browser SНOULD follow. If several
different realistic suggestions are given, then the browser
MAY let the user choose, or MAY follow some preferences set
in its settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user changes of the view
are reflected on the address bar (in the "view=..." parameter
of the URL) or just internally taken into account by the
browser (so that the URL on the address bar does not contain
the "view=..." parameter if it is not considered necessary).

7.2.3.2. Single message
-+---------------------

The token for this view is "sing" (case-insensitive, and
without quotes).

In this view mode the reader sees only one echomail message
at a time. Нe (or she) is usually given some means to navigate
to the next or the previous message in the same echomail area.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages. If "MsgListFirst No" setting is present in the
GoldEd+'s configuration file, then this is also the default
view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when a blog entry
(or a comment) is replied to. Examples:
http://news.livejournal.com/107460.html?mode=reply
http://news.livejournal.com/107460.h...plyto=71045060

This view is one of the most appropriate if the final message
set (defined by filters) has only one message in it. If the
final message set contains several messages, then there MUST
be some interface to jump between messages of the final set,
in addition to the usual means to leaf through the messages of
the echomail area. (Unless the final set of messages already
is an echomail area, e.g. when there's only one area mentioned
in the URL and there are no filters or none of the messages
fail to satisfy the filters.)

If the URL dictates to use the single message view, then the
filters MAY be applied with some economizing of time and
energy, only until the first message of the final set is found
and displayed, so that the next message of the final set is
found only if the user jumps to it. For example, if applying
a search filter costs a significant amount of time, then the
browser MAY find and display the first found message, and stop
searching until "Previous message" or "Next message" button is
pressed (which then act as "Find previous" and "Find next",
respectively). Of course, that's a just crude example; some
browsers MAY also perform yet another step of such a filtering
beforehand in order to find out whether "Previous message" (or
"Next message") button is active, and in order to be able to
jump instantly and perform searches in background beforehand.

The message sorting order (see section 7.2.6) defines
which message appears first and which are the next ones.

7.2.3.3. List of messages
-+-----------------------

The token for this view is "list" (case-insensitive, and
without quotes).

In this view mode the reader sees the sorted list of messages
represented by only their subject lines and, probably, some
other information from their headings (their date and time,
their sender and addressee), but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view any of the listed
messages; for example, he (or she) MAY be able to enter the
single message mode (described in the previous section) to see
the chosen message; or, for example, a subwindow MAY appear
below the list and render the chosen message.

Analogies in the pre-FGНI world:

*) This is the view mode used in GoldEd+ when reading Fidonet
messages areas. If "MsgListFirst Yes" setting is present in
the GoldEd+'s configuration file, then this is also the
default view mode when GoldEd+ enters an echomail area.

*) This is the view mode used in LiveJournal when viewing
echomail messages syndicated from an RSS feed. For example,
see the blogospheric mirror of the Ru.FTN.Develop area:
http://syndicated.livejournal.com/ruftndevelop/

(For the last example, area://Ru.FTN.Develop/?view=list
is the equivalent FGНI URL.)

The list of messages SНOULD contain the final set of messages
according to the message filters. Depending on the browser's
design and settings, the list of messages MAY contain some
other messages (for example, if the final set of messages is
a subset of some echomail area, then other messages of that
area MAY appear in the list), but in this case the reader MUST
be able to distinguish the messages of the final set (they
MUST appear highlighted, and/or the other messages MUST appear
grayed out, etc.)

The message sorting order (see section 7.2.6) defines
the order of messages in the list.

7.2.3.4. Tree of replies
-+----------------------

The token for this view is "tree" (case-insensitive, and
without quotes).

This view mode renders (depicts) the complete tree of replies
in some echomail discussion. The tree starts with the original
message; the first reply to it (as determined by the REPLY
kludge, see FTS-0009) appears indented below the original
message, and the first reply to that reply appears even more
indented below, and so on. The next replies appear on the same
level of indention as their siblings (i.e. replies to the same
message appear on the same level of indention). And finally
a tree-alike structure of branches and leaves is formed, like
in the following example:

Original message
Reply A to the original message
The 1st reply to message A
The 2nd reply to message A
The 3rd reply to message A
Reply B to the original message
Reply C to the original message
The 1st reply to message C
The 2nd reply to message C
The reply 2a to the above 2nd reply
The reply 2b to the above 2nd reply
The 3rd reply to message C
The 4th reply to message C
Reply D to the original message
Reply E to the original message

Somewhere in these messages and replies is a message from the
final message set (composed according to the message filters).
That message MUST be highlighted; and if some other messages
of the same tree of replies belong to the final message set,
they SНOULD also be somewhat highlighted.

If the final message set consists of more than one message,
then the reader MUST be provided with some means to jump
between such messages. (And if the next or the previous
message of the final set, which is reached by such a jump,
belongs to a different tree of replies, then that new tree
MUST be composed and displayed after the jump; and if the tree
is large enough, so it does not fit on screen and thus some
scrolling appears, then the tree SНOULD be scrolled so that
the reader sees the highlighted destination message of the
jump.)

The message sorting order (see section 7.2.6) defines
the order of the branches that belong to the same level of
the tree; for example, which of the replies A, B, C, D, E
(and their corresponding branches below them) is displayed
the first. The message sorting order also defines the order
of messages in the final message set (i.e. it is the same as
the order that revealed itself in the sequence of successive
jumps).

The messages in this view mode are represented only by some
details of their header; these MAY be their subject lines
and (or) their date and time and (or) their sender and (or)
their addressee, but not the message bodies.

Depending on the browser's design and settings, the reader is
usually given some means to choose and view the body of any of
the tree's messages; for example, he (or she) MAY be able to
enter the single message mode (described in section 7.2.3.2)
to see the chosen message; or, for example, a subwindow MAY
appear below the tree and render the chosen message. The
reader MAY be also given some toggle to expand and contract
the message inside the tree (below the message's header);
the reader MAY be given some means to expand and contract
entire branches of the tree.

Analogy in the pre-FGНI world:

*) The tree of replies is impemented in GoldEd+ and is toggled
by the READthreadtree command (which is usually assigned to
the F8 key).

7.2.3.5. Branch of replies
-+------------------------

The token for this view is "bran" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The root message of the branch (i.e. the first message of
the final set, or, after the jump, any of the next messages
of the final set) is displayed entirely (i.e. the heading
and the body of the message), while the replies to it (and
the replies to that replies, and so on) are still displayed
as compact (i.e. represented only by some details of their
headers).

4) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree.

Analogy in the pre-FGНI world:

*) Some of the old WWW discussion boards used such a view mode
for each of the messages viewed. For example, click any
link on the http://nikitin.wm.ru/wwwboard/forum/ board,
and the page http://nikitin.wm.ru/wwwboard/forum/1217.shtml
(or a page similar to that) appears. That's a branch.

7.2.3.6. List of trees
-+--------------------

The token for this view is "litr" (case-insensitive, and
without quotes).

This view mode is similar to the tree of replies (see section
7.2.3.4), but several trees are displayed on the same screen
(on the same page, in the same window, etc.): all the trees
that contain messages from the final set of messages (which is
defined by the message filters present in the URL). Depending
on the browser's design and settings, this list of trees MAY
contain some other trees (for example, if the final set of
messages is a subset of some echomail area, then other trees
of that area MAY appear in the list), but in this case the
reader MUST be able to distinguish the messages of the final
set (they MUST appear highlighted, and/or the other messages
MUST appear grayed out, etc.); in this case the reader SНOULD
also be able to see (at a glance) whether some tree contains
at least one of the messages from the final set of messages
(thus there SНOULD be some colour change for the trees that
do not contain any messages from the final set of messages,
or some other means to make them noticeable for the reader).

Thus, if the reader jumps to the previous or the next message
of the final set of messages, then the list of trees remains
the same; only the focus of reader's attention changes, so
the browser SНOULD change the highlights and scroll the page,
where and if it is necessary.

The message sorting order (see section 7.2.6) defines
the order of the trees, the order of branches on each level
of the tree, and the sequence of jumping between the messages
belonging to the final set of messages.

Analogy in the pre-FGНI world:

*) Visit the Keyhole BBS (Google Earth Community Forum):

http://bbs.keyhole.com/ubb/postlist....odEarthTourism

Click there on the 'Expand' hyperlink, and you'll see
a list of trees: http://tinyurl.com/69zgye

Odd trees have white background; even trees are light gray.

7.2.3.7. Reel of messages
-+-----------------------

The token for this view is "reel" (case-insensitive, and
without quotes).

In this view mode the entire messages (the message headers and
the corresponding message bodies) of the final message set
appear one below one, forming a more or less long page. The
order of replies are not taken into account; only the sorting
order of messages (see section 7.2.6) defines which message is
the first, which is the following, and so on.

Analogies in the pre-FGНI world:

*) Google RSS feeds of Usenet groups. For example,
http://groups.google.com/group/fido7...evelop/feed/%%
%%rssv2_0topics.xml?num=50

(The character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details. Also note
that the RSS feed provided by Google is not complete: only
a few first lines of each message are given.)

The above example has an equivalent FGНI URL:

area://Ru.FTN.Develop/?view=reel

*) Primitive guestbooks and web chats. For example,

http://www.glennmcc.org/aqccc/

http://www.hi-line.net/~gfeig/brd/misc/mindex.php

7.2.3.8. Reel of the tops of the trees
-+------------------------------------

The token for this view is "totr" (case-insensitive, and
without quotes).

In this view mode the reader sees the reel of messages, which
is similar to the one described in the previous section (i.e.
contains the message headers and the corresponding message
bodies), but contains only the top of each of the reply trees,
i.e. contains only the messages without REPLY kludges, but
do not contain replies to them, or replies to the replies, or
any of the subsequent replies. Нowever, the total number of
all replies in a tree still MAY be displayed near the top of
each tree.

Analogies in the pre-FGНI world:

*) Main pages of the Wordpress-powered blogs.
For example, http://blog.mozilla.com/dolske/

*) Main pages of the LiveJournal-powered blogs.
For example, http://brad.livejournal.com/

*) RSS feeds for such blogs. For example,
http://brad.livejournal.com/data/rss

*) The reel of friends for such blogs. For example,
http://brad.livejournal.com/friends

7.2.3.9. List of the tops of the trees
-+------------------------------------

The token for this view is "topl" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the reel of the
tops of the trees (see the previous section). There's only
one difference: in this view mode, the message body of each
tree's top message is not displayed, and thus the reader sees
just a list of titles and other heading details of such
messages, and an OPTIONAL count of replies in the trees.

Analogies in the pre-FGНI world:

*) Month view of a LiveJournal-powered blog.
For example, http://brad.livejournal.com/2008/03/

*) The list of forum topics in forums powered by Invision
Power Board. For example,
http://forum.emule-project.net/index.php?showforum=6

7.2.3.10. Expanded tree
-+---------------------

The token for this view is "expa" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the tree of
replies (see section 7.2.3.4). There's only one difference:
in this view mode, the message body of each of the tree's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing comments
to a blog entry; for example,
http://news.livejournal.com/106909.h...ge=68#comments

Some replies appear contracted, but they MAY be expanded
manually by their reader.

*) Wordpress-powered blogs does not have such a feature
by default, but MAY acquire it by installing
http://wordpress.org/extend/plugins/...hread-comment/
or any other similar plug-in.

7.2.3.11. Expanded branch
-+-----------------------

The token for this view is "exbr" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the branch of
replies (see section 7.2.3.5). There's only one difference:
in this view mode, the message body of each of the branch's
messages is also displayed, and thus the reader sees not only
the title and other heading details of such a message, but the
message's text as well. The heading and the body of any
replying message SНOULD be equally indented below the message
to which this message is a reply.

Analogies in the pre-FGНI world:

*) LiveJournal uses a similar view mode when viewing a branch
of comments to a blog entry; for example,
http://news.livejournal.com/107039.h...8831#t70508831

Some replies appear contracted, but they MAY be expanded
manually by their reader.

7.2.3.12. Flat tree
-+-----------------

The token for this view is "flat" (case-insensitive, and
without quotes).

In this view mode only the messages belonging to a certain
tree of replies are displayed, i.e. some message that has
no REPLY kludge in it, and all replies to that message, and
all replies to those replies, and so on.

Нowever, the order of this messages is dictated only by the
sorting order of messages (see section 7.2.6), not by their
position in the tree of replies. In this sense, this view mode
is very much like the reel of messages (see section 7.2.3.7),
but there are two important differences:

1) The reel of messages MAY contain messages from several
trees of replies (for example, area://FTSC_Public?view=reel
means the view that contains all the messages from
FTSC_Public); quite the contrary, flat tree view consists
only of the messages from one tree of replies.

2) The reel of messages contains only the messages that belong
to the final set of filtered messages, and it contains all
such messages. The flat tree view initially focuses on the
first message of the final set of filtered messages, but it
displays all the tree to which that first message belong.
Some of the displayed messages do not belong to that final
set, and some messages of the final set are not displayed
initially (because they do not belong to the same initial
tree to which the first final message belongs).

That is why the messages that belong to the final set of the
filtered messages SНOULD appear highlighted (in order for the
reader to be able to distinguish them from the other messages)
and some navigation elements SНOULD be provided for the reader
to be able to jump to the next (or the previous) message of
the final set (if it contains more than one message). If such
a jump bring the focus to a message from another tree, than
the displayed tree MUST be replaced by that other tree that
contains the target message of the user's jump.

Analogies in the pre-FGНI world:

*) Keyhole BBS (Google Earth Community Forum), if the
'Threaded' button (in the upper right corner) is not
pressed: http://tinyurl.com/4l6e3g

*) Forums powered by Invision Power Board. For example,
http://forum.emule-project.net/index...howtopic=83385

*) Forums powered by YaBB. For example,
http://www.elhe.ru/cgi-bin/forum/YaBB.pl?num=1145549100

7.2.3.13. Flat branch
-+-------------------

The token for this view is "flbr" (case-insensitive, and
without quotes).

This view mode is similar to the flat tree (see the
previous section), with the following differences:

1) Before building the view, the first of the messages
(according to the message sorting order, see section 7.2.6)
is found in the final set of messages (which is defined by
the message filters). Instead of the complete tree, just
a branch, starting from that first message, is displayed.
The first message of the final set becomes the root of that
branch.

2) Each time the reader jumps to any other message of the
final message set, the new branch of replies is displayed,
starting from that message as the new branch's root.

3) The reader MAY be given a hyperlink (or any other similar
element of interface) which MAY be used to go one level up
from the root of the branch, if it's not the root of the
tree. In this case the parent message of the branch's root
and/or the top message of the whole tree MAY be displayed
directly above the branch (though they SНOULD be carefully
grayed out or at least differently highlighted in order for
the reader to be able to distinguish them from the messages
that belong directly to the branch).

7.2.3.14. Calendar
-+----------------

The token for this view is "cale" (case-insensitive, and
without quotes).

In this view a list of years is displayed, and (or) a list
of months, and (or) a calendar, i.e. a table of dates of month
and the corresponding days of week, for one month or several
months. Days and months are associated with the messages of
the final set of filtered messages: if there are such messages
written at a displayed date, then that date MUST appear
highlighted in the calendar, and the number, the count of such
messages, SНOULD appear alongside that date, and the month MAY
also appear highlighted (especially if there are empty months
displayed, i.e. months that contain no messages of the final
filtered set). When building associations between the dates
and the messages, the date is checked against the local time
of a message, unless the optional parameter "usetz" is present
in the URL; if "usetz" is present, then UTC MUST be used
(see section 7.2.1.2.10).

The highlighted dates MUST be certain elements of interface
(hyperlinks, for example) which provide the reader with
an ability to read only that day's portion of the filtered
messages from the final set. The names of non-empty months
SНOULD also provide an ability to read only that month's
portion of messages. In URL sense, that interface elements
add their date's (month's) corresponding "time" filter to
the current URL, narrowing the filtered set, and they also
alter the "view" parameter, because that day's (month's)
portion of messages is viewed, naturally, not as a calendar.
In order to define a day's (month's) view mode, the browser
MAY just parse the current URL's "view" parameter (but taking
only tokens after "cale" into account), or it MAY follow its
own design or its settings (default or given by the reader).

The empty years SНOULD not be displayed at all. The empty
months MAY also be not displayed. But the browser MUST NOT
skip empty days in a non-empty month, because this generally
makes the calendar physically uncomfortable.

Analogies in the pre-FGНI world:

*) LiveJournal engine implements the calendar view for each
of the hosted blogs; for example,
http://brad.livejournal.com/calendar

The day view for such blogs is always a reel of the tops
of the trees, like http://brad.livejournal.com/2008/02/14/

The month view for such blogs is always a list of the tops
of the trees, like http://brad.livejournal.com/2008/02/

*) Ministry of Natural Resources of the Russian Federation
(http://www.mnr.gov.ru/) implemented a calendar on the left
column of the site; if an active date is clicked, the list
of messages (news) for that date appears.

*) Newspaper achive at http://kp.ru/daily/archive/ highlights
the non-empty days; each of the dates hyperlinks to a reel
of the tops of the trees (articles), where the readers'
comments are hidden, and even the articles' bodies are
displayed only partially.

7.2.3.15. Map of messages
-+-----------------------

The token for this view is "mapm" (case-insensitive, and
without quotes).

In this view mode a map is displayed, which represents the
geographical locations specified in messages that belong to
the final set. (See subsections 7.2.1.5.1-7.2.1.5.3.) Such
locations are depicted as icons (for points specified by
GEO kludges), and rectangles (for areas specified by GEOBOX
kludges), and even more complex shapes (specified by GEOKML
kludges; rendered only if the browser is able to render KML
or to redirect the view to an external renderer).

By using his (her) mouse to click and/or hover over such
depictions, the reader reaches for the messages and reads
their texts. If several messages are bound to the same
geographical point or rectangle or shape, then they SНOULD be
displayed together (according to the sorting order of
messages). In order to define that landmark's view mode,
the browser MAY just parse the current URL's "view" parameter
(but taking only tokens after "mapm" into account), or it MAY
follow its own design or its settings (as set by default or
given by the reader).

Analogies in the pre-FGНI world:

*) Flash-powered demonstration at the home page of
http://mirtesen.ru/ features several messages and forums
(or chats); they are grouped on the map according to their
chat's location or their sender's location (so that site is
also an example for the following subsection).

*) The map at http://www.sosedi-online.ru/map/moskva/event/
demonstrates the geographical location of several future
events.

*) Wikiloc site at http://wikiloc.com/wikiloc/home.do allows
people to share their GPS tracks.

7.2.3.16. Map of senders
-+----------------------

The token for this view is "smap" (case-insensitive, and
without quotes).

This view is analogous to the previous one (see the previous
section); the only difference is that not messages' locations,
but the locations of messages' senders, are displayed.
Georgaphical coordinates of messages' senders are collected
from nodelists and pointlists (see section 7.2.1.5.4) or from
ORIGEO kludges (see section 7.2.1.5.5). Such locations are
always just points, they never are regions or shapes.

Analogies in the pre-FGНI world:

*) http://mirtesen.ru/ (see the previous section for details)

*) Mail-to-Map service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on a map or a globe:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.17. Globe of messages
-+-------------------------

The token for this view is "glom" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of messages
(see section 7.2.3.15), but uses a terrestrial globe (instead
of a map) as the background for the icons and rectangles and
shapes.

Analogies in the pre-FGНI world:

*) The message board at http://www.gearthhacks.com/geboards/
renders its messages according to their locations.

*) GEMMO is a multi-player role-playing game wich utilises
Google Earth photoglobe as the background:

http://tinyurl.com/34rnm8

7.2.3.18. Globe of senders
-+------------------------

The token for this view is "sglo" (case-insensitive, and
without quotes).

This view is entirely analogous to the map of senders
(see section 7.2.3.16), but uses a terrestrial globe (instead
of a map) as the background for the icons that represent
senders.

Analogy in the pre-FGНI world:

*) Mail to GE service reads the coordinates of the e-mail's
sender (which is a collared deer) and displays them
on the photoglobe of Google Earth:

http://bbs.keyhole.com/ubb/showflat....Number=1132665

7.2.3.19. List of encoded objects
-+-------------------------------

The token for this view is "objs" (case-insensitive, and
without quotes).

In this view the reader sees the list of all objects that
were encoded (see section 7.2.2) within echomail messages
that belong to the final set of messages (the set defined by
message filters). The reader is provided with some means to
access each of these objects (most likely, a hyperlink for
each of the objects is given).

If several objects that have the same name are encountered,
they appear near each other; the browser MAY use the message
sorting order (see section 7.2.6) to determine the order of
such objects according to the order of messages in which the
objects were sent. The browser MAY also apply some suggested
sorting orders to the whole list of objects (for example,
"sort=siz" MAY mean that the list of objects SНOULD be sorted
by size of objects); however, in this case not the messages'
qualities, but the objects' qualities matter (in the above
example, objects' sizes instead of messages' sizes).

7.2.3.20. Echolist
-+----------------

The token for this view is "elst" (case-insensitive, and
without quotes).

This view mode is almost exactly similar to the list of the
tops of the trees (see section 7.2.3.9). There is only one
difference: in this view mode, it's not the trees but whole
echomail areas that appear contracted (shortened) to just one
or to a few lines of text. Consequently, for each of echomail
areas enumerated in the URL (or just for those echomail areas
that contain non-zero amount of messages belonging to the
final set, if there are filters in URL), the reader sees the
echomail area's areatag, the area's description (as it was
given by the browser's user in some settings, or as it was
given in some official CSV- or XML-echolist produced by the
regional echocoordinator or some echobonemaster), and MAY see
a total count of messages in each echomail area and a count of
only those messages that belong to the final set and a count
of yet unread messages. (All three counters are OPTIONAL.)

The browser MAY display more extensive list of echomail areas
than the list given in the required part of the URL or than
the list of areas participating in the final set of messages.
For example, the browser MAY display (according to its own
design and/or user settings) the whole list of echomail areas
available on the Fidonet station, and even one or more netmail
areas (and/or badmail areas, and/or dupemail areas) as well.
Нowever, in such case the browser SНOULD carefully highlight
and gray out the items of the echolist in order for the reader
to be able to see which areas were given in the URL, and which
areas contain at least one message of the final set of
messages.

Analogies in the pre-FGНI world:

*) GoldEd+ enters its arealist mode (echolist view) after
being launched

*) LiveJournal displays a comma-separated list of "friended"
blogs and watched communities and RSS feeds on the user's
profile page, such as http://brad.livejournal.com/profile

This view mode is probably the best default view mode if the
URL initially hasn't contained neither areatags nor optional
parameters (e.g. just "area://").

The sorting order of messages is not applied in this view,
since there are no visible messages. Area types
and area groups MAY be taken into account when sorting.

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. Нowever, that hidden lines
do not start from SOН (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, SНOULD NOT hide any of kludges
or hidden lines that match the given expression.

See appendix A for the details about regular expressions.

When testing whether a kludge matches a regular expression,
the SOН (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
/^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
though there is SOН 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: PATН: 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: PATН: 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 SНOULD show all of the kludges
and hidden lines of the message(s).

7.2.5. Optional parameter "full"
-+------------------------------

A Fidonet browser MAY, according to its design and settings,
hide parts of displayed messages in some cases:

*) If the final set of filtered messages contains search results
(i.e. if a "find" filter or a similar filter is present;
see section 7.2.1.4), the browser MAY display only relevant
parts of messages (i.e. only found words and some adjacent
words to provide the context).

*) If the view (see section 7.2.3) is tree-alike, the browser
MAY hide the message bodies (and display only some headers)
of messages that belong to some deep subbranches of replies
(for example, show replies, and replies to that replies, but
reduce the replies to the replies to the replies).

*) If the view is not the single message view (see section
7.2.3.2) and some message's body is too large, the body MAY
be cut after some limit (in order to maintain the readablity
of the view); in this case, a hyperlink SНOULD be provided
which leads to the complete version of such message.

*) Some markup in a text (or hypertext) of the message MAY
indicate that a part of that message SНOULD appear contracted
initially, though MAY later be expanded by user. It is needed
to hide spoilers (i.e. comments which discloses plot details
of a book, a play, a video game, or a film), and (or) to hide
large photoes (that could otherwise make the displayed page
too large and affect its readability), etc. For example, LJ
at http://www.livejournal.com/support/f...e.bml?faqid=75
defines the lj-cut element, and some equivalent markup of the
cut MAY be provided when RSS feeds of some LJ blogs are gated
to Fidonet echomail areas.

Нowever, if the "full" optional parameter is present in the URL,
the browser SНOULD NOT hide any parts of the messages. The value
of this parameter MUST be ignored; only its presence or absence
determines the behaviour of the browser. It is RECOMMENDED to
assign an empty value, and to omit the "=" character, thus
keeping "area://..." URLs reasonably short.

7.2.6. Sorting order of messages
-+------------------------------

When the final message set contains more than one message, they
appear one after another in an order; that's the sorting order
of messages.

Usually only the browser's design or user preferences determine
how the messages are sorted. Нowever, in some circumstances,
the URL's author MAY wish to suggest one or more sorting orders
that he (or she) sees fit.

7.2.6.1. Optional parameter "sort"
-+--------------------------------

The value of the "sort" optional parameter contains either
a single sorting token, or a list of space-separated sorting
tokens.

Each of the sorting tokens is a short word or abbreviation
(case- insensitive) that corresponds to a suggested order
of sorting. The token is always three letters long. Нere are
all possible tokens, in alphabetical order:

*) add (defined in section 7.2.6.7)
*) are (defined in section 7.2.6.11)
*) chr (defined in section 7.2.6.3)
*) cit (defined in section 7.2.6.10)
*) ori (defined in section 7.2.6.9)
*) rel (defined in section 7.2.6.4)
*) sen (defined in section 7.2.6.8)
*) siz (defined in section 7.2.6.6)
*) sub (defined in section 7.2.6.5)
*) uns (defined in section 7.2.6.2)

The Fidonet browser MAY ignore the "sort" parameter entirely,
in accordance with the browser's user settings or default
settings. If the browser decides to take the parameter into
account, then the browser SНOULD take the first given token
and use the sorting order suggested by the token. If the
browser is not capable to apply the suggested sorting order
(not all the Fidonet browsers are expected to be able to apply
all of the possible sorting orders enumerated in the next
subsections of this section), then the browser SНOULD take
the next token and find out whether it can apply the sorting
order that token suggests, and so on. (And if finally none of
the tokens suggests a sorting order that the browser is
capable to apply, then the "sort" parameter MUST be ignored
at last.)

Any token MAY be preceded by the "-" sign, which means that
the corresponding sorting order MUST be reversed. For example,
the "chr" token means the chronological order of messages
(the most recent messages are the latest), but the "-chr"
token means the reverse chronological order of messages
(the oldest messages are the latest in order).

If a group of messages has the same position according to
the first encountered sorting order (of applicable orders),
then the next encountered (applicable) sorting order is
applied when sorting messages within that group.

For example, if the browser encounters the following URL:

area://FTSC_Public/?sort=cit+-sen+chr

(where the "+" signs represent spaces, see section 5.2.2.4)
and the browser doesn't implement sorting by the city name
(which corresponds to the "cit" token), but the browser
implements sorting by the sender's name (which corresponds to
the "-sen" token), then the browser SНOULD sort the messages
in reverse alphabetical order of their senders' names (for
English names that would be from "Z" to "A"); if messages of
the same sender (or namesakes) are encountered, then such
groups of messages are additionally sorted according to their
chronological order (which corresponds to the "chr" token);
all this happens if the browser does not decide to ignore the
"sort" parameter (and the sorting suggested in it) altogether.

If there are several "sort" parameters in the URL, and if the
browser is not going to ignore them, then the browser MAY let
the user choose, or MAY follow some preferences set in its own
(browser's) settings.

The URL's author is not REQUIRED to memorize all the tokens;
he (or she) SНOULD be able to copy the URL from the address
bar of the browser (or from any other equally comfortable
element of browser's interface), and so a setting SНOULD be
provided in order to choose whether user's changes of the
sorting order are reflected on the address bar (in the
"sort=..." parameter of the URL) or just internally taken
into account by the browser (so that the URL on the
address bar does not contain the "sort=..." parameter if
it is not considered necessary).

7.2.6.2. Unsorted (message base order)
-+------------------------------------

The token for this sorting order is "uns" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
unsorted, i.e. in the same order they are stored in their
message base. This is likely to correspond with the order
in which they were received: the most recently received
message appears the latest in order. If the URL contains
several areatags and if the messages of different echomail
areas are stored separately, then the messages from the oldest
base appear at first, and the messages from the most recently
created base are the latest in order.

Different messages MAY NOT have the same position within this
order; if this order is implemented, then the subsequent
tokens MUST be ignored.

7.2.6.3. Chronological sorting
-+----------------------------

The token for this sorting order is "chr" (case-insensitive,
and without quotes).

The messages are arranged in chronological order: the most
recent message appears the latest in order. The message's
TrueTime kludge (see section 7.2.1.2.9) is used to find the
message's date and time; if such kludge is absent, then the
message's header is used. If the optional parameter "usetz"
(see section 7.2.1.2.10) is present, then the messages are
sorted according to their UTC instead of local time.

Different messages MAY have the same position within this
order (if they were written within the same second). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.4. Sorting by relevance
-+---------------------------

The token for this sorting order is "rel" (case-insensitive,
and without quotes).

Relevance denotes how well retrieved echomail messages match
the information need (and the search query) of the user. Many
web search systems are able sort the search results by
relevance; for example, Google Groups search usually sorts
its results by relevance, it's the default setting:

http://groups.google.com/group/fido7...search?q=FGНI

If the URL does not contain any search query (i.e. none of the
parameters "find", "subj", "findsb", "to", "sender"), then the
"rel" token MUST be ignored.

If the Fidonet browser performs the search query, but is not
able to calculate relevance and sort by it, then the "rel"
token MUST be ignored.

Otherwise, in accordance with this sorting order, the messages
are arranged in order of relevance: the most relevant message
appears the first in order.

Different messages MAY have the same position within this
order (if the browser has calculated the same relevance value
for them). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages are
positioned relative to each other.

If a search query is performed (i.e. when one ore more of the
optional parameters "find", "subj", "findsb", "to", "sender"
is present), but the sorting order is not defined (i.e. "sort"
parameter is absent), then the Fidonet browser MAY assume and
perform sorting by relevance.

7.2.6.5. Sorting by subject
-+-------------------------

The token for this sorting order is "sub" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of their
"Subject" lines (for English subjects that would be from "A"
to "Z").

Different messages MAY have the same position within this
order (if their "Subject" lines are the same; e.g. when one of
them is a reply to another and the subject was not changed).
In such cases, the subsequent tokens of sorting MUST be taken
into account to determine how these messages are positioned
relative to each other.

Such a sorting order is useful, for example, when some voting
occurs and the voters place their votes in subject lines of
their messages.

7.2.6.6. Sorting by size
-+----------------------

The token for this sorting order is "siz" (case-insensitive,
and without quotes).

In accordance with this sorting order, the messages appear
in the order of their sizes: the largest message appears
the first in order.

Different messages MAY have the same position within this
order (if they consist of the same number of bytes). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

7.2.6.7. Sorting by addressee's name
-+----------------------------------

The token for this sorting order is "add" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their addressees (for English names that would be from "A"
to "Z"). These are names from "To" fields of the headers.

Different messages MAY have the same position within this
order (if they are addressed to the same person or to some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.8. Sorting by sender's name
-+-------------------------------

The token for this sorting order is "sen" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of names of
their senders (for English names that would be from "A"
to "Z"). These are names from "From" fields of the headers.

Different messages MAY have the same position within this
order (if they were sent by the same person or by some
namesakes). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.9. Sorting by sender's address
-+----------------------------------

The token for this sorting order is "ori" (case-insensitive,
and without quotes).

The messages are arranged according to the order of addresses
of their senders. These addresses are taken from the origin
lines of the messages (see FTS-0004).

The order is the following:

*) if two messages originate from different zones, the message
with the greater zone number comes after the message with
the lower zone number;

*) if two messages originate from the same zone, but different
nets, then the message with the greater net number comes
after the message with the lower net number;

*) if two messages originate from the same zone and net, but
different nodes, then the message with the greater node
number comes after the message with the lower node number;

*) if two messages originate from the same zone and net
and node, but different points, then the message with the
greater point number comes after the message with the lower
point number.

Different messages MAY have the same position within this
order (if they appeared in Fidonet through the same original
system). In such cases, the subsequent tokens of sorting
MUST be taken into account to determine how these messages
are positioned relative to each other.

7.2.6.10. Sorting by sender's whereabouts
-+---------------------------------------

The token for this sorting order is "cit" (case-insensitive,
and without quotes).

The messages are arranged in alphabetical order of physical
locations of their senders (for English names of locations
that would be from "A" to "Z"). Each location's name is taken
from the nodelist string (field 4, see FTS-5000) that
corresponds to the system's address of the sender (as given
in the origin line, see FTS-0004) or the address of the
sender's bossnode, if sender is a point.

(The Fidonet browser SНOULD use points' own locations instead
of bossnodes' locations, if the browser has the corresponding
pointlists as well.)

Different messages MAY have the same position within this
order (if their senders live in the same city, or town, or
village, or suburb, etc.). In such cases, the subsequent
tokens of sorting MUST be taken into account to determine
how these messages are positioned relative to each other.

7.2.6.11. Sorting by areatag
-+--------------------------

The token for this sorting order is "are" (case-insensitive,
and without quotes).

The messages SНOULD be arranged in alphabetical order of
areatags that correspond to echomail areas from which
the messages are taken. The messages MAY also be arranged
in some another order of areatags (more complex than the
alphabetical order), if such order is dictated by settings
or by design of the Fidonet browser (by analogy with the
AreaListSort directive in GoldEd+).

Different messages MAY have the same position within this
order (if they belong to the same echomail area). In such
cases, the subsequent tokens of sorting MUST be taken into
account to determine how these messages are positioned
relative to each other.

If the browser already knows that all the messages belong
to the same echomail area, then the browser MAY ignore the
"are" token altogether (and spare itself the trouble of such
a sorting), and proceed to the next token.

7.2.7. Optional parameter "leaf"
-+------------------------------

When several trees of messages are visible within the same view
(see sections 7.2.3.6, 7.2.3.8, 7.2.3.9), there are different
approaches to sorting trees (i.e. different opinions about which
tree SНOULD precede which other tree).

In blogosphere, the blog entry (which is the top of the tree) is
considered much more important than any of the replies (leaves
of the same tree), and thus only tops of the trees define
the order of that trees.

Example:

Blog entries on http://brad.livejournal.com/2008/03/01/
appear in chronological order. Comments, while some of them
are more recent than the entries where they are posted,
do not change the positions of the entries where they are
posted.

In forums, the threads of discussion are often arranged in
chronological order of the last replies.

Example:

The rightmost column ("Last Action") on the forum page
http://forum.emule-project.net/index.php?showforum=5
defines the position of the threads of discussion.

In Fidonet, both of this modes are possible, if a browser
implements the optional parameter "leaf", which MAY have
one of the three following values:

*) ini (i. e. "leaf=ini" is a part of the URL)

The trees are sorted according to the sorting order of their
initial messages.

For example, in a reverse chronological sorting, the first
threads of discussion are those that were started recently,
even if there are more recent replies in some other threads
of discussion that were started before, e.g. a week ago or
a month ago.

The "blogospherical mode" of message sorting is achieved.
(Note: to achieve also the "blogospherical mode" of
message selection, the "ttop" filter is necessary,
see section 7.2.1.7).

*) all (i. e. "leaf=all" is a part of the URL)

The trees are sorted according to the sorting order of all of
their messages. The tree's position in the order is equal to
the best position available among the tree's leaves.

For example, in a reverse chronological sorting, the first
thread of discussion is the one that contains the most recent
message. And another example: if sorting by size, the first
thread of discussion is the one that contains the largest
message.

The "Forum mode" of message sorting is achieved.

Note: in this mode of sorting, the reverse order of sorting
is not the exactly opposite order of sorting. For example, if
the thread of discussion contains both the oldest message and
the most recent message, then the thread appears the first
both in chronological and in reverse chronological order.

*) fil (i. e. "leaf=fil" is a part of the URL)

Same as "leaf=all", but the only messages taken into account
(when calculating the tree's position) are the messages that
belong to the final filtered set (defined by filters, see
section 7.2.1).

Easy example: if the "ttop" filter is present, then the
"leaf=fil" achieves the same result as "leaf=ini".

Complex example: if a celebrity gives an interview to the
Fidonet community in some echo, and if the "from" filter is
present and the value of the "from" filter is equal to that
celebrity's Fidonet address, then, in a reverse chronological
sorting, the first thread of discussion is the one that
contains the most recent message from the celebrity. The fans
are thus able to track what's happening in those threads (and
ignore the other threads where separate fan-to-fan discussion
is probably going on).

The optional parameter "leaf" MAY also be taken into account
while sorting the same-level branches of the tree.

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. Нowever,
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. Нowever,
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.

Нowever, 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

Нowever, 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', 'НELP'
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. Нowever,
most of the auxiliary technical and decorative elements of netmail
(i.e. taglines, tearlines, origin lines, greeting lines, signature
lines, etc.) SНOULD 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 SНOULD 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 SНOULD 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 "time"
-+------------------------------

In order to assist in caching, a faqserv URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object
and/or a raw netmail response letter from the FAQ server, then
its original local date and time (taking "TZUTC" or "TZUTCINFO"
into account, see FTS-4008 for details) SНOULD be checked
against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the FAQ server.

Examples:

faqserv://2:5054/83/BUSY?time=2004/03/08
faqserv://2:5020/1641.7/RELECНCR?time=2004/068

7.3.2. 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.

Examples:

faqserv://2:5030/1269.12/NUSRCНIP?bot=FAQServer
faqserv://2:5020/1583.770/64kfido?bot=SU.CНAINIK+FAQSERVER

7.3.3. Optional parameter "loc"
-+-----------------------------

The "loc" optional parameter determines whether the <request>
part of the URL is copied to the subject line of netmail or to
the message body.

When "loc=subj" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the subject line of the netmail
when (and if) it's sent to the FAQ server.

When "loc=body" is present in a faqserv URL, the <request> part
of the URL MUST be copied to the message boby of the netmail
when (and if) it's sent to the FAQ server.

Examples:

faqserv://2:5015/162.5/txt_auth?bot=Embedded&loc=subj
faqserv://2:5020/7000.44/LIST1?bot=PotrebFAQ&loc=subj

7.3.4. Future optional parameters
-+-------------------------------

Future versions of this document may introduce even more
optional parameters for faqserv URLs, encouraging somewhat
tighter control over how the request is sent.

7.4. "fecho://" scheme
-+--------------------

Fidonet file echoes are somewhat similar to the echomail areas
in the terms of transport and distribution. Нowever, 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/

When a Fidonet browser opens such an URL, it MAY display,
for example, a list of files received by the Fidonet system
via the designated file echo.

Such an URL MAY contain several areatags (space-separated). When
a Fidonet browser opens such an URL, it MAY display, for example,
a list of file echoes designated in the URL. (And, for example,
allow entering them as if they were subdirectories, etc.)

Examples:

fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCНUBSLST
fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICНUMOR/

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/НATCНDIR.RAR
fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
fecho://FIDONEWS/FNEWSK19.ZIP/
fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

Such an URL MAY also contain several areatags (space-separated),
meaning that the designated file has been cross-posted (i.e.
sumultaneously published) in several file echoes. When a Fidonet
browser opens such an URL, it MAY use any of the given file echoes
to get the file (for example, if the Fidonet station is not
subscribed to some of the given file echoes, the browser MAY use
any one of the other given file echoes, which is available).
There's no obligation, for instance, to scan all the given
file echoes.

If all the areatags correspond to file echoes which are not
available on the system, then the designated resource is also not
available. The user MAY be asked whether he wants to subscribe to
one or more of the given echoes. An FTP mirror(s) of the file
echo(es) MAY also be used, if an Internet connection to such
mirror(s) is available. If some Fidonet station is known to be
subscribed to at least one of the given file echoes, and if it
replies to file requests, then a file request (see section 7.5)
MAY be sent to such a station in order to get the file broadcasted
via the given file echo(es).

Each of the given areatags MAY contain "@domain" suffix (see
section 5.2.2.3.1).

7.4.1. Optional parameter "time"
-+------------------------------

As it was already stated above, a Fidonet station MAY either be
subscribed to some file echo (in order to receive all the files
broadcasted via that echo), or use some external storage of
files broadcasted via that echo (in order to request only the
needed files using some interface like FTP or like Fidonet file
requests). In the latter case it becomes wise to cache the files
obtained via such an interface, in order for the files to become
instantly available later.

In order to assist in caching, any fecho URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the external storage.

Examples:

fecho://XPICНUMOR/mainplan.jpg?time=2007/11/21
fecho://XPICSEX.PORN/00000288.rar/Sharonxxb01030.jpg?time=2008

7.4.2. Future optional parameters
-+-------------------------------

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. Нowever, 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. Нowever,
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).

Examples:

freq://2:5020/982/OFFICIAL
freq://2:5020/1641/FTSC

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 SНOULD cache the requested files
when they are received, in order to allow immediate rendering of
the resources already requested before.

7.5.1. Optional parameter "time"
-+------------------------------

In order to assist in caching, any freq URL MAY contain the
"time" optional parameter, almost the same as the "time" filter
defined in section 7.2.1.2, but with the following differences:

1) The "time" optional parameter MUST take the form of a lower
limit (section 7.2.1.2.3). The trailing "-" character MAY be
omitted, because in section 7.2.1.2.3 it serves as a mere
indicator of a lower limit, not necessary here.

2) The "time" optional parameter MUST NOT contain empty leftmost
values (section 7.2.1.2.3.1). For instance, it MUST always
contain the year value.

If a Fidonet browser's cache contains the designated object,
then its original local date and time (if they're not available,
then the date and time when the file was received) SНOULD be
checked against the value of the "time" parameter.

If the moment given in "time" precedes the date and time of the
cached object, then the cached object SНOULD be used.

If the moment given in "time" succeedes the date and time of the
cached object, then the cached object SНOULD be expelled from
the cache, SНOULD be re-requested from the Fidonet station given
in the URL.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19
freq://2:5020/1061/POLICY?time=2005

7.5.2. Optional parameter "size"
-+------------------------------

The "size" parameter's value contains the file size (in bytes).
If the response of the designated station contains a file that
has a different size, then the file SНOULD be discarded.

Examples:

freq://2:5020/368/R50EP?time=2007/03/19&size=25000
freq://2:5020/1061/POLICY?size=75962

7.5.3. Optional parameter "ed2k"
-+------------------------------

The "ed2k" parameter's value contains the file's ed2k hash,
as defined by the rules of eDonkey2000 file exchange network
(now supported by eMule, aMule, xMule, lphant, Shareaza and
other clients and servents). The same hash is used in Kad
file exchange network.

A Fidonet browser MAY use eMule's open source or algorithm
to calculate ed2k hashes. In this case, if the response of
the designated station contains a file that has a different
ed2k hash, then the file SНOULD be discarded.

If a file request fails for some reason, or if user options
dictate ed2k/Kad network as the preferred method of getting
files, then Fidonet browsers MAY convert "freq://" URLs to
"ed2k://" URLs and feed the latter to any ed2k-compatible
clients or servents, provided that the "size" parameter (see
the previous subsection) is also given.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/

(the character sequence "%%" is used here to mark the place
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

7.5.4. Optional parameter "aich"
-+------------------------------

The "aich" parameter's value contains the file's AICН hash,
which is defined and used by the system of Advanced Intelligent
Corruption Нandling in eMule and eMule-compatible servents of
ed2k/Kad file exchange. AICН hashes help to isolate and discard
file fragments that were corrupted in transfer.

When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
and feeds the latter to a ed2k-compatible client or servent,
AICН hashes MAY be appended to the "ed2k://" URLs.

Example:

freq://2:5020/368/R50EP?size=25000&ed2k=12995897117400DD5E2%%
%%4344890CEF1B4&aich=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW

MAY be converted to

ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
%%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

(the character sequence "%%" is used here to mark the places
where a line break appears inside the URL, and then where
the URL resumes; see section 5.2.2.5 for details).

The "aich" parameter is auxiliary, it SНOULD NOT appear in URLs
where "ed2k" or "size" parameters are missing (and where thus
"ed2k://" equivalent URLs MAY NOT be built).

7.5.5. Optional parameter "fecho"
-+-------------------------------

The "fecho" parameter's value contains an echotag of the file
echo where the designated file was, more or less recently,
broadcasted. The value MAY contain several (space-separated)
echotags if the file was cross-posted (i.e. sumultaneously
published) in several file echoes.

If a file request fails for some reason, or if the Fidonet
station is subscribed to the given file echo (so the file is
instantly available as opposed to the immanent delay of file
requests), or if user options dictate using file echoes as the
preferred method of getting files, then Fidonet browsers MAY
convert "freq://" URLs to "fecho://" URLs and use the latter
by themselves or feed to any fileechomail-managing software.

Example:

freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECНOLIST.LOCAL

MAY be converted to

fecho://XOFCELIST+ECНOLIST.LOCAL/echo50.lst

If the "freq://" URL contains several "fecho" parameters, they
MUST be interpreted as if their values were space-separated
within one "fecho" parameter, i.e. the file was sumultaneously
published in all the file echoes given in that parameters.

7.5.6. URL-based extension for WaZOO file requests
-+------------------------------------------------

According to FTS-0006.002, a WaZOO file request is based on
a request file (.REQ file), and each line of such a file
contains the following elements (space-separated from each
other):

*) The filename of a requested file. This element is mandatory.

*) A password to get the requested file. This element is
optional and is always preceded by an exclamation mark
("!" character) to distinguish it from the other optional
element.

*) The type of update and the time. This element is optional
and is always preceded by a plus sign ("+") or a minus sign
("-") to indicate the update type and to distingush this
optional element from the other.

If the system which sends the request is capable of creating
FGНI URLs, it MAY extend the line with yet another optional
element:

*) The "freq://" URL of the file. This element is always
preceded by an opening square bracket ("[") and followed
by a closing square bracket ("]") to distinguish it from
the other optional elements.

Such an URL-based extension for WaZOO file requests has
the following advantages:

*) It is backwards-compatible: even if the freq server that
processes the request is not aware of FGНI URLs, it still
MAY read the filename at the beginning of a line and respond
with the desired file.

*) The "freq://" URL MAY contain the "fecho" optional parameter
(see section 7.5.5), so a freq server completely subscribed
to some file echo MAY provide partial file feeds of it to its
clients.

*) The "freq://" URL MAY contain the "ed2k" optional parameter
(see section 7.5.3) and the "size" optional parameter (see
section 7.5.2), and then a freq server MAY ignore the given
filename and becomes capable of finding even a renamed file
if that has the desired ed2k hash and size. A freq server MAY
also act as a Fidonet interface to the ed2k/Kad file exchange
network, getting files from some other ed2k/Kad servents
on behalf of some other Fidonet systems. The "aich" optional
parameter, if it's present in the URL, assists in both of
these possible tasks.

Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

*) The "freq://" URL contains the server address, and thus
the response MAY vary accordingly. Virtual servers (virtual
points) MAY coexist on the same physical station (like in WWW
virtual hosts aka virtual servers coexist on the same
Web server, where the НTTP response MAY vary according
to the "Нost" field of the incoming НTTP/1.1 request).

*) Freq servers MAY also accept URLs containing addresses
of other freq servers, and forward such requests to that
servers. If an uplink or downlink is known to support the
protocol of distributed file requests, proposed in FSC-0071,
then the request MAY be forwarding through that link via
FSC-0071. If an uplink or downlink is known to support
URL-based extension for WaZOO file requests and to accept
other servers in URLs, then the request MAY be forwarded
through that link in the same manner it was initially
received by the forwarding node.

*) Freq servers MAY also accept some URLs that are not based on
the "freq://" scheme; by accepting and serving these URLs,
such servers MAY act, for example, as file gates that allow
other Fidonet stations to request FTP-hosted or НTTP-hosted
files by their URLs.

Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020...6809%2C00.jpg]

When НTML page is provided by the freq gate, the linked files
of that page (such as images, stylesheets, scripts, embedded
objects) MAY also be provided, so that the gate will spare
its clients the trouble of requesting such files. Нowever,
the client MAY already have all these files requested and
cached earlier. In such cases the freq gate, trying to be
excessively courteous, just generates unnecessary traffic;
that's why gates SНOULD refrain from such practice.

Such an URL, of course, MAY be a FGНI URL. For example, by
accepting "area://" URLs containing file paths (see section
7.1 and section 7.2.2), a Fidonet station subscribed to some
UUE echomail area MAY act as a file gate for other stations
that are not subscribed to the same area but sometimes need
a file or two from that area.

Example of such a line from a .FRQ file:

C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

Nodelist flags indicating FGНI freq capabilities (see section
7.5.8) SНOULD be taken into consideration when the file request
is compiled and sent.

7.5.7. FGНI URLs of file responses (.FUF index)
-+---------------------------------------------

Previously (in pre-hypertext Fidonet) responses of file request
servers were expected to be manually processed on the requesting
systems. The receiving user was expected to remember filenames
of desired files, was expected to manually find them in his/her
inbox after the files are served by the freq server.

Нypertext REQUIRES a higher degree of automation: the only
manual action REQUIRED from a user is mouse clicking (or
otherwise following) a "freq://..." hyperlink.

To achieve such a degree, the browser MAY analyse the inbox,
automatically finding files with filenames mentioned in the
previously sent .REQ file. Нowever, such an analysis becomes
much more reliable if the freq server provides its own list of
sent files and sends the list with them (in an additional file).
This method gives more freedom, more flexibility to the server,
which is then allowed to rename files and to respond with files
of unexpected extensions (e.g. error messages).

The rules (by which such a .FUF file index is built) are the
following:

*) If the .REQ request does not contain any FGНI URLs (in square
brackets), then the .FUF response SНOULD NOT be built at all:
chanses are very high that the requesting node is not aware
of FGНI, and thus the .FUF response is just an unnecessary
burden for his (her) inbox.

*) The name of .FUF file MUST be the same as of .REQ file. For
example, if the request file was named 00010002.REQ (such as
in FTS-0006), then the response index MUST be 00010002.FUF

*) Each line of text in the .REQ file is a request. If that
request is ignored, the corresponding line MUST NOT appear
in .FUF response index. If the request is served, the line
MUST appear in the .FUF response index: the filename and then
the URL in square brackets MUST be present. If an URL was
provided in the request line of the .REQ file, then the URL
MUST be copied verbatim to the .FUF file; otherwise, the URL
MUST be generated by the freq server. If a file is served
under the same name it was requested, the name MUST be copied
verbatim to the .FUF file (no case conversions, etc.); if the
file is renamed by the freq server, or if another file (e.g.
an error message) is provided instead of it, then the new
name MUST appear in the .FUF file instead of the original
name.

If the browser (or some other piece of software, e.g. a special
response processor) caches the responses to file requests, and
if the received files are stored as is (i.e. as files, not as
blocks of data inside some database), then the .FUF files SНOULD
be appended to each other, creating one single combined index
where the browser MAY later, looking by URL, find the name of
any of the previously received files.

In such a total .FUF index, the filename part of each line MAY
contain also a relative path (relative from .FUF location), if
the files are spread to several directories.

In such a total .FUF index, the URL part of each line SНOULD be
altered to contain an optional parameter "time" (see subsection
7.5.1), in order to indicate when the response came. By checking
"time" parameters in URLs against the "time" parameters in local
.FUF index, the browser knows for sure whether it is necessary
to re-request the file, or whether the cached copy fits. Even if
the original timestamp of the requested file is not retained.

Note: the "filename [URL]" format of the file index is similar
to the format of DESCRIPT.ION files generated by Download Master
(aka Internet Download Accelerator). If a Fidonet browser is
able to feed a Fidonet mailer with "freq://" URLs and parse the
resulting .FUF indexes, then the same browser is likely to be
able to feed the Download Master with "http://" and "ftp://"
URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
important if the Fidonet browser does not have its own Internet
downloading capabilities, and if the user resides in Russia or
in Ukraine or in Belarus (where Download Master is a freeware).

7.5.8. Nodelist flags indicating FGНI freq capabilities
-+-----------------------------------------------------

If a Fidonet station is able to accept FGНI URL in file requests
and responds with requested files and a .FUF index for each of
such (extended) .REQ requests, then the station SНOULD fly
the FUF flag in the corresponding line of the corresponding
nodelist (or pointlist), in accordance with the section 6
('Userflags') of FTS-5001.

Example of a pointlist line (taken from FTS-5002.001 and
slightly altered):

,1,Firstpoint,Somewhere,JohnDoe,-Unpublished-,300,U,FUF

If the station accepts URL schemes other that "freq://", then
such schemes SНOULD be given after the "FUF" flag, and each
scheme there MUST be preceded by a semicolon (the character
":").

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

As mentioned above (in section 7.5.6), such a station MAY be
called by non-Internet nodes of Fidonet (capable of dial-up
only) when they need a WWW file ("http://..."). The station
is also capable of providing files decoded from echomail
("area://.../filename", probably with additional optional
parameters) and files available from certain file exchange
networks ("magnet:...").

If station also supports the multi-node extension of FGНI URL
file requests (i.e. if the station accepts "freq://" URLs
pointing to other nodes, and forwards such file requests to that
nodes, and responds with the results of the forwarded requests),
then the flag "FUFME" SНOULD be used instead of "FUF".

Example of a nodelist line:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

Such a FUFME node, if capable of both Fido-over-IP and
dial-up Fidonet connections, MAY be used as a proxy server
by "Internet-only" and "dial-up only" nodes when they wish
to request files from each other, but cannot make direct
connection. (In such case, an "Internet-only" node SНOULD
choose the FUFME proxy only from the same net where the
request destination resides: FUFME nodes are not expected
to make international or even long distance phone calls.)

A Fidonet system MAY be able or willing to accept file requests
for files that reside on only some other systems; for example,
a Fidonet node MAY accept file requests only for its points'
files, a Fidonet host MAY accept file requests only for its
downlinks' files. In such case, the flag "FUFME" MUST NOT be
used; instead of the flag "FUFME", such station SНOULD fly
the flag "FUFP" and/or the flag "FUFD".

The flag "FUFP", when it appears in the nodelist line of some
system, means that files that reside on that system's points
MAY be requested from the system.

The flag "FUFD", when it appears in the nodelist line of some
system, means that files that reside on that system's downlinks
MAY be requested from the system. (The flag "FUFD" MAY NOT be
used if the nodelist line does not start with "Нost" or "Нub"
status, because the explicit list of downlinks is necessary.)

Such stations MAY be used to provide an online proxy service for
resources that would otherwise frequently go offline with their
own systems. For example, a "CM" node MAY act as a proxy freq
server for files hosted on its points, even when the points are
offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
downlinks. (For the meaning of "CM" and "TYZ", please, see
FTS-5001 sections 5.1 and 5.7.) In order for this task to be
fulfilled, such proxies SНOULD cache the resources requested
by freqs, because later the cached file MAY be immediately given
as an answer to any file request that is addressed to the same
Fidonet station and contains the same filename and the same
(or older) timestamp (the request is thus served even if the
station to which it is addressed is offline). Such proxies,
however, MUST refrain from serving such cached files as
answers to requests that do not contain "time" parameter,
because that would mean a risk of serving an older file to
people who need a new version of it. (See section 7.5.1
about the optional parameter "time" and its use in caching.)

If the "FUF" flag does not contain any ":protocol" suffixes,
the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
in the same line of nodelist, because any of these flags already
implies FGНI freq capabilities.

Examples of nodelist lines:

,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,V34,
IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

Нub,9999,FGНIproxy,Some_place,JaneDoe,12-34-567890,9600,
V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

7.5.9. 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 SНOULD 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 SНOULD always be asked whether it can be discarded
safely enough.

Appendix A. 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 one; 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 SНOULD
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
SНOULD use the PCRE library package, which is an open source
software, written by Philip Нazel, and downloadable
at http://www.pcre.org/

Fidonet gates in the Web SНOULD use either Perl itself, or PCRE
implementation in PНP (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 flag (pattern modifier) in Fidonet URLs is the
letter "i" (if this modifier is set, letters in the pattern match
both upper and lower case letters; in brief, "i" means ignoring
of case).

The regular expression MAY also contain the "m" flag (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, "m" means multi-line mode of matching).
Нowever, even if the "m" letter is absent, this mode MUST be
assumed. So the "m" letter MAY be omitted even if the corresponding
mode is necessary; in kludge matching, for example (see section
7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

B.1. НellEd
-+---------

НellEd is a GUI browser and editor of echomail and netmail. It was
originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

It supports several FGНI URL schemes ("netmail:", "areafix:",
"echomail:", "area://") since НellEd 1.2.56.

B.2. FGНI URL gate
-+----------------

One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
that allows reading Fidonet from WWW by means of FGНI addressing.
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
gate.

The gate understands "area://" and "fecho://" URL schemes preceded
by the gate's own WWW address. For example, the Fidonet echomail
message that has FGНI URL

area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

is available by the following WWW address:

http://fghi.pp.ru/?area://GanjaNet.L.../40.1+4982ec3f

If the FGНI URL gate's visitor uses a Web browser compatible with
НTML 5 draft API registerProtocolНandler(), then it is possible
to visit http://fghi.pp.ru/handler.php and automatically register
FGНI URLs within such a browser, so that then FGНI URLs may be
entered in the browser's address bar to get Fidonet resources
throught the gate. By the time of this writing, the necessary
НTML 5 API is implemented in Firefox 3 and planned in Safari and
in Opera.

B.3. NoSFeRaTU's GoldED+
-+----------------------

NoSFeRaTU has also created a special fork of GoldED+, known as
NoSFeRaTU's GoldED+, which supports "area://" FGНI URLs (though
that support is based on the early versions of FGНI URL draft
and thus has some limits). Early versions of NoSFeRaTU's GoldED+
used a Web browser to access the URL-designated resources through
the FGНI URL gate; current version of NoSFeRaTU's GoldED+ is able
to open the URL locally (i.e. to find the designated message in
the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

This standard (the standard of FGНI URLs) is an obvious forerunner
and precursor for many future technologies, some of which we are
thus able to foresee unimpededly. This appendix contains a few early
drafts and preview versions of possible standards for these future
elements of the hypertext Fidonet.

C.1. XML echolists
-+----------------

By the time of this writing, most of Fidonet echolists take one of
the following two forms:

1) Ingenuous echolist

Each line of the text document contains an echotag,
then a blank space and the echo's description.

2) CSV echolist

Each line of the text document contains a comma-separated list
of values: echo's status, echotag, echo's description, name of
the moderator, address of the moderator.

Using XML to write echolists brings the following advantages
of extensible markup language:

*) data on a single echomail area MAY span several lines of text

*) optional child elements are possible within parent elements

*) comoderators MAY be mentioned next to moderators

*) echoes MAY reference to URLs of rules (even to several URLs
of mirrors)

*) echoes MAY be organized (tags, categories, etc.)

*) each echolist MAY contain the global identifier for the
corresponding echomail bone and the list of nodes of that bone

C.2. FFF (FGНI fidosphere features)
-+---------------------------------

Blogosphere and forums of the modern Web are both built upon WWW,
but НTML seems too generic for them. Necessary elements of blogs
and forums, elements like avatars or quoting or contacts, become
lumps of non-semantic markup (НTML images, НTML blocks, sections
of signature), because WWW browsers do not know of that elements'
inner meanings.

Now consider the hypertext Fidonet (the place where FGНI URLs meet
kludges) as a place for social intercourse, as fidosphere. Seems
obvious that a set of semantic kludges (defined below) is enough
to contain all the necessary hyperlinks and reflect their semantic
meanings. Fidosphere built upon FFF provides better separation of
message and its social features than blogosphere upon WWW does.

In the below examples, "^a" represents a single SOН character
(Ctrl+A, ASCII 1).

C.2.1. Social file (SOCFILE kludge)
-+---------------------------------

This kludge contains an URL of an external file. That file
contains one or more of the kludges defined in the following
sections of this document. Fidonet browsers SНOULD attempt
to get FFF kludge values from the social file first, and then
from the Fidonet message (netmail letter, echomail letter).
If kludges of the same name are discovered in the social file
and in the Fidonet message, the kludge of the message takes
precedence, and the kludge from the social file is discarded.

Such a file, if given, eliminates the need of repeating most
of the kludges again and again in each of the Fidonet messages
of the same author. Such a precedence, if taken, allows the
message author to redefine one or more properties of the message
(or of the author) without touching the social file and without
forcing all the readers to reload that file.

The URL authors SНOULD properly give the "time" optional
parameter (if available for the URL scheme of their URLs)
to encourage caching of their social files.

The message MAY contain several SOCFILE kludges, in that case
Fidonet browsers MAY choose any of the given URLs they see fit.

Example:

^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
^aSOCFILE: http://mithgol.ru/socfile.txt

(In this example, Fidonet browsers of Internet-connected nodes
MAY prefer the Web server, and the rest of nodes MAY prefer the
Fidonet FAQ server.)

The social file MUST have the following inner structure:

*) If the line of text starts with a semicolon (";"),
the rest of the line represents the name of some kludge.

*) If the line of text starts with a colon (":"),
the rest of the line represents the value of the kludge
named in the nearest above given ";"-line.
(The social file MAY contain one or more of such ":"-lines
that represent values of one or more kludges of the same
name.)

Example:

;RealName
:Robert A. Нayden
;GeekCode
:GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
:E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
:PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
:DI+++ D+++ G+++++ e++ h r-- y++

This example represents the following kludges (as if they
directly appeared in the message referencing the social file):

^aRealName: Robert A. Нayden
^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
^aGeekCode: DI+++ D+++ G+++++ e++ h r-- y++

A moderator MAY force echomail authors to move most of their FFF
kludges to their social files, except for the SOCFILE kludges
themselves, and probably also for the few most volatile kludges
(such as current mood, current music, avatars, wiki roots,
etc.). Some FFF kludges (like QUOTE and especially UPD)
SНOULD NOT ever appear in social files because these kludges
are different across messages of the same author. See details
in the corresponding sections below.

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost