= Сообщение: 1479 из 2448 =================================== RU.FTN.DEVELOP = От : FGHI Robot 2:50/88 15 Aug 18 04:22:46 Кому : All 15 Aug 18 04:22:46 Тема : FGHI URL (draft) FGHI : area://RU.FTN.DEVELOP?msgid=2:50/88+5b738069 = Кодировка сообщения определена как: ASCII ================================== ============================================================================== ********************************************************************** FGHI FIDONET GLOBAL HYPERTEXT INTERFACE ********************************************************************** Status: draft Revision: 0.5pre Title: FGHI 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. How 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. FGHI URLs of file responses (.FUF index) 7.5.8. Nodelist flags indicating FGHI freq capabilities 7.5.9. Future optional parameters Appendix A. Regular expressions Appendix B. Known implementations B.1. HellEd B.2. FGHI URL gate B.3. NoSFeRaTU's GoldED+ Appendix C. Foreseen future technologies C.1. XML echolists C.2. FFF (FGHI 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 HTML 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 FGHI (pronounced 'fig-high', stands for 'Fidonet Global Hypertext 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", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in FTA-1006 (based on RFC 2119).
4. Changelog of this document -+---------------------------
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 FGHI 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 FGHI URLs (section 7.5.6) *) added new freq server response (.FUF file), it contains FGHI 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 FGHI 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) *) FGHI now stands for Fidonet Global Hypertext Interface *) added Appendix B (list of known implementations of FGHI 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. Having located a resource, a Fidonet system may perform a variety of operations on the resource (as might be characterized by such words as 'access', 'subscribe', 'unsubscribe', 'send', 'request', 'show attributes').
5.1. The main parts of URLs -+-------------------------
In general, Fidonet URLs are written as follows:
<scheme>:<scheme-specific-part>
Any URL contains the name of the scheme being used (<scheme>) followed by a colon and then a string (the <scheme-specific-part>) whose interpretation depends on the scheme.
Scheme names consist of a sequence of characters. The lower case letters "a"--"z", digits, and the characters plus ("+"), period ("."), and hyphen ("-") are allowed. For the sake of resiliency, programs interpreting Fidonet URLs SHOULD treat upper case letters in scheme names as equivalent to the corresponding lower case letters (e.g., allow "AREA" scheme name as well as "area").
Only the first colon of the URL plays the role of delimiter between <scheme> and <scheme-specific-part>. The scheme-specific part of any URL MAY contain other colons.
The colon delimiter between <scheme> and <scheme-specific-part> MAY be immediately followed by an optional double slash ("//"). Fidonet programs interpreting URLs MUST treat the delimiter "://" as equivalent to the simple colon before <scheme-specific-part>.
5.1.1. Conformance note -+---------------------
This subsection is informative.
The Fidonet URL schemes defined in this document consist of lower case letters "a"--"z" only. However, digits, and the characters plus ("+"), period ("."), and hyphen ("-") MUST also be allowed in scheme names, so that Internet schemes conforming with the specifications of RFC 1738 are correctly dealt with.
In current Internet practice they distinguish between delimiters ":" and "://". The delimiter "://" is often used after scheme names that designate objects and resources ("http://", "ftp://", "gopher://", "nntp://", "ed2k://", "file://", etc.). The delimiter ":" is often used after scheme names that designate actions (e.g. "mailto:", "skype:").
The same difference exists between Fidonet resources (objects) and actions. That's why, though these delimiters MUST always be interpreted as equivalent, it is still RECOMMENDED that ":" SHOULD be used after schemes that designate actions ("netmail:", "echomail:", "areafix:") and "://" SHOULD be used after schemes that designate resources ("area://", "freq://", "fecho://", "faqserv://").
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. However, it is not wise to implement any equivalents to kludges as a required part of every Fidonet URL; and it could be hard to mantain complete lists of all possible character sets inside all programs interpreting Fidonet URLs. (Remember, it should be also made possible for Fidonet URLs to appear and be well interpreted in traditional HTML hypertext environment of the Web, Internet e-mail, instant messaging, etc.) That's why only one encoding, with large enough character set, has to be chosen.
The following paragraphs of this subsection are normative.
The sequence of octets used in Fidonet URLs MUST always contain UTF-8 encoded representation of original characters.
ISO/IEC 10646-1 defines a multi-octet character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. And UTF-8, one of a few so-called UCS transformation formats (UTF), preserves the 7-bit ASCII range, thus providing some compatibility with file systems, parsers and other software elements that rely on 7-bit ASCII values but are transparent to other values.
UTF-8 is defined in RFC 2279. Its description can also be found in Unicode Technical Report #4 and in the Unicode Standard, version 2.0.
5.2.2. Encoding of octets -+-----------------------
The character sequences in different parts of a URL are used to represent sequences of octets.
It is possible to represent an octet by the chararacter which has that octet as its code within the pure 7-bit ASCII character set. However, there are some exceptions (see below).
Alternatively, octets MAY be encoded by a character triplet consisting of the character "%" followed by the two hexadecimal digits (from "0123456789ABCDEF") which form the hexadecimal value of the octet. (The characters "abcdef" MAY also be used in hexadecimal encodings.)
Hexadecimal encoding of any octet MAY be used even when it is not REQUIRED or RECOMMENDED. However, it is RECOMMENDED to avoid unnecessary hexadecimal encoding, thus keeping URLs reasonably short.
It is either REQIRED or RECOMMENDED to use the hexadecimal encoding of octets if they have no corresponding graphic character within the 7-bit ASCII character set, or if the use of the corresponding character is unsafe, or if the corresponding character is reserved for some other interpretation within the particular URL scheme. These requirements and recommendations are detailed below.
5.2.2.1. No corresponding graphic 7-bit character -+-----------------------------------------------
URLs are written only with the graphic printable characters of the 7-bit ASCII coded character set.
The octets 80-FF hexadecimal do not belong to 7-bit ASCII, and the octets 00-1F and 7F hexadecimal represent control characters; these octets MUST be encoded.
The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The octet 20 hexadecimal MUST always be encoded.
The characters "<" and ">" are unsafe because they are used as the delimiters around tags in HTML hypertext and XML data. The octets 3C and 3E hexadecimal MUST always be encoded.
The quote mark (""") is used to delimit URLs in some systems, including valid XHTML and XML. The octet 22 hexadecimal MUST always be encoded.
The character "#" is unsafe because it is used in World Wide Web and in other systems to delimit a URL from a fragment or anchor identifier that might follow it. The octet 23 hexadecimal MUST always be encoded.
The character "%" is unsafe because it is used for encodings of other characters. The octet 25 hexadecimal MUST always be encoded.
The character sequence of triple minus ("-" repeated thrice) has a special meaning in Fidonet and can accidentally start a tearline in some cases (e.g. when a line is wrapped). At least one of the three corresponding octets (2D 2D 2D hexadecimal) MUST be encoded if they follow each other in a sequence.
Other characters were declared unsafe in RFC 1738 because some gateways and other transport agents were known to sometimes modify such characters. These characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`". The corresponding octets (7B 7D 7C 5C 5E 7E 5B 5D 60 hexadecimal) MUST always be encoded for the sake of Internet compatibility.
All unsafe characters MUST always be encoded within a URL. For example, the character "#" MUST be encoded within URLs even in software programs that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another program that does use them, it will not be necessary to change the URL encoding.
Many URL schemes reserve certain characters for a special meaning: appearance of that characters in the scheme-specific part of the URL (in <scheme-specific-part> after scheme name) has a designated semantics.
Usually a URL has the same interpretation when an octet is represented by a character and when it is encoded. However, this is not true for reserved characters: encoding a character that is reserved for a particular scheme may cause harm to the meaning of a URL, if the character is used according to its designated semantics. And vice versa.
The character "?" is used as the delimiter between required and optional parts of the URL. The delimiter itself MUST NOT be encoded. If the character "?" appears in any other part of a URL, it MUST be encoded, so it won't be confused with the delimiter.
The character "=" is used as the delimiter between parameter names and parameter values. The delimiters themselves MUST NOT be encoded. If the character "=" appears in any other part of a URL, it MUST be encoded, so it won't be confused with any of the delimiters.
The character "&" is used as the delimiter between "parameter=value" pairs. The delimiters themselves MUST NOT be encoded. If the character "&" appears in any other part of a URL, it MUST be encoded, so it won't be confused with any of the delimiters.
The character "@" is 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.
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. However, 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.
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 -+-------------------------------
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 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 ** ** ** *********************************************************** ***********************************************************
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 HREF="..." attribute of a LINK element in HTML echomail).
Fidonet URL parsers SHOULD allow the same "%%"-marked line breaks even in the URLs that are based on schemes not defined in FGHI 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.
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:
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:
(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 "?" SHOULD be treated as the delimiter between required and optional parts of that URL, and the remaining "?" MAY be treated as if they were properly encoded ("%3F" character triplets), or even ignored.
The reserved character "=" MUST be used only once in a parameter setting; if there are many "=" characters in some setting, then the first appearance of "=" SHOULD be treated as the delimiter between that parameter's name and the parameter's value; and the remaining "=" characters, encountered before the next "&" (or before URL's ending, if it's the rightmost "parameter=value" pair) MAY be treated as if they were properly encoded octets of that parameter's value ("%3D" triplets), or even ignored.
"The first appearance" means the leftmost one, because it is natural to parse the scheme-specific part of URL in left-to-right order.
The programs interpreting Fidonet URL MAY also stop the whole interpreting and ignore the rest of URL after the position where an inappropriate reserved character is first encountered. This behaviour is especially RECOMMENDED for the programs trying to isolate URLs from some plain text, where the white spaces and/or other delimiters before and after URLs tend to be sometimes omitted by chance.
The URL schemes enumerated below designate resources that are most often used in typical actions involving netmail or echomail composed and sent.
According to the above section of delimiter guidelines, the ":" character (and not the "://" character triplet) SHOULD be used as the delimiter after <scheme> part of such URLs.
6.1. "netmail:" scheme -+--------------------
The "netmail:" scheme is used to designate the Fidonet netmail address of an individual or service. It uses standard Fidonet addressing notation, <zone>:<net>/<node>.<point>@<domain> (see FSP-1004 for details).
The character "/" has its literal meaning for this scheme.
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.
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.
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.
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.
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.)
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 SHOULD launch a netmail composer (or subscription manager) software that automatically composes the proper areafixing letter (addressed to an uplink node and ordering subscription to the given echomail area). However, it is RECOMMENDED that the software asks its user to confirm the ready subscription order or cancel it before that letter is sent.
Examples:
...if you're a developer, subscribe via areafix:SU.FidoTech>https://fido.g0x.ru/?areafix:SU.FidoTech>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>https://fido.g0x.ru/?areafix:Ru.Fidonet.Today>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) SHOULD order subscription to all of the designated areas. However, 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 SHOULD be notified when an encountered "areafix:" URL is ignored or truncated).
Fidonet software usually has its own means to determine which uplink has the requested echomail area and would receive the areafixing netmail letter. However, if the system has several uplink nodes able to distribute the given echo, the "uplink" optional parameter MAY be used to recommend the preferred uplink node (provided that the author of the hyperlink has some reasons to recommend one uplink above all others).
The "uplink" parameter takes a value that uses standard Fidonet addressing notation, <zone>:<net>/<node>.<point>@<domain>
However, some parts of address ("<zone>:", "@<domain>" and/or ".<point>") MAY be omitted (see FSP-1004 for details). The point number is often omitted in the "uplink" parameter values, because Fidonet points almost never become uplinks.
Examples:
...get the echo about embedded systems directly from its moderator, use areafix:Ru.Embedded?uplink=2:5029/32>https://fido.g0x.ru/?areafix:Ru.Embedded?uplink=2:5029/32>areafix:Ru.Embedded?uplink=2:5029/32
...those Titanic echoes never were on the backbone, use areafix:Titanic.PVT?uplink=2:5020/830>https://fido.g0x.ru/?areafix:Titanic.PVT?uplink=2:5020/830>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 SHOULD 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. However, if the "uplink" optional parameter is present, the software MAY choose to cancel echomail subscription order formerly sent to the current uplink for the given echomail area, and then arrange for supply of the same echomail area from the preferred uplink provided by the value of the "uplink" parameter. (The user SHOULD be asked first whether such an action is appropriate.)
The "uplink" parameter MAY contain several adresses, separated by white spaces; in this case the subscription manager SHOULD 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. However, 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 SHOULD 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 SHOULD 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 SHOULD automatically take care of all the necessary settings (echoprocessor settings, mailer setting, cron-managed scripts creating poll-files, etc.).
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.
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. However, files are broadcast there instead of messages. File echo is a shared base of files that have common areatag (file echo identifier) and are distributed through Fidonet via hierarchical and/or p2p-alike connections between individual Fidonet systems (nodes and points).
The 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.
Future versions of this document may introduce even more optional parameters for the areafix URLs, encouraging somewhat tighter control over rescan parameters, packer/unpacker settings and formats, etc.
Programs interpreting areafix URLs SHOULD NOT be sure whether it is safe to ignore any of the unknown parameters. Some of future extensions may dramatically change the URL's meaning, as "leave" is already able to change it to the opposite.
If an unknown parameter is encountered in the areafix URL, the user SHOULD always be asked whether it can be discarded safely enough.
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>https://fido.g0x.ru/?areafix:?leave>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>https://fido.g0x.ru/?areafix:?uplink=2:5063/88>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">https://fido.g0x.ru/?areafix:?fecho">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.
When an "echomail:" hyperlink is used (clicked, followed), an echomail message composer SHOULD be launched.
The <areatag> part of "echomail:" URL MAY contain several areatags (separated by spaces). In this case an echomail composer SHOULD use its cross-posting abilities to post the desired message to all of the designated areas. However, 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 SHOULD be notified when an encountered "areafix:" URL is ignored or truncated), or if the echomail composer does not support cross-posting at all.
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.
The "to" optional parameter is used to designate the name of echomail addressee. Its default value SHOULD be "All", meaning all of the area audience. The default value MAY also be given by some user setting of the echomail composer used to process the "echomail:" URL.
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.
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.
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.)
The URL schemes enumerated below designate named objects that can be accessed, read, browsed, etc.
According to the above section of delimiter guidelines, the "://" character triplet (and not the ":" character) SHOULD be used as the delimiter after <scheme> part of such URLs.
7.1. The <object-path> part of URL. Possible forms of the path -+------------------------------------------------------------
Sometimes Fidonet is regarded as a text-only network. At least, Fidonet is notable for its very few means of transferring binary data. File echoes do not enjoy an audience comparable to that of traditional echo areas; file requests and attaches are almost never routed between nodes. In that somewhat harsh circumstances, however, several means of encoding and embedding the binary data inside text messages exist. Files (and sometimes whole directories of files) are packed to economize traffic; some of the resulting archives are encoded in text lines that are sent via text-only means of communication -- in echomail, in netmail.
That's why all the following Fidonet URL schemes must have some common method to designate, if necessary, an object inside packed (archive) files and/or embedded in some text. The <required-part> of their URL always ends with "/<object-path>", and so URLs are written as follows:
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>
However, the trailing slash of <object-path> has its own value, makes some real difference. For example, "example.zip" means the archive itself (a file that may be saved or sent, etc.), and "example.zip/" means the root directory of that archive (a container that may be browsed, updated, etc.)
The trailing slash of <object-path> MUST NOT be ignored.
7.1.2. Dealing with unknown containers -+------------------------------------
Sometimes an <object-path> designates an object inside such a container that certain Fidonet browsers are not able to open by themselves. This MAY happen when the archive format is unknown (or is known, but is newer than the supported one).
If the object is requested as a separate entity (for example, its URL is entered in the address line of a Fidonet browser, or the user follows a hyperlink specifying that URL), the browser MAY inform the user about the unknown container encountered, and suggest saving that container for possible manual analysis (after all, the user may have unpacker tools in his avail that are not yet integrated into a Fidonet browser, and may be willing to try them).
If the requested object is not a separate entity (for example, if it is just one of images on a hypertext page), if many such objects are requested at the same time and for the same purpose, then it would not be wise to flood the user with information about each of such obstacles concurrently encountered, and so the browser SHOULD follow its standard procedures prescribed for the state of error (display a "broken image" icon, or use an alternate object or an alternate text where it is provided).
7.2. "area://" scheme -+-------------------
Echomail is an important and powerful force in Fidonet. Echomail is, by definition, a broadcast medium. See echomail specifications in FTS-0004.
An echomail area is a shared base of messages that have common areatag (area identifier) and are distributed through Fidonet via hierarchical and/or p2p-alike connections between individual Fidonet systems (nodes and points).
Due to the immanent modularity of Fidonet software packages, echomail composer and echomail browser can be different programs (for example, the latter does not require read/write access to the area message base and is able to work through a read-only gate). The "echomail:" scheme (defined above) is designed to designate an action of a Fidonet echomail composer; the "area://" scheme, defined is this section, designates a resource that is located in an area message base. These schemes can be handled by different software modules, even if they were manufactured independently.
The area URLs take the form:
area://<areatag>/<object-path>?<optional-part>
The character "/" has its literal meaning in the <optional-part> of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (<areatag>/<object-path>), playing the role of delimiter between parts of the path. If an <areatag> contains the character "/" in its literal meaning, the character MUST be encoded.
If <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.
However, <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.
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 SHOULD display some warning about it. For example, the warning MAY contain an URL like areafix:areatag>https://fido.g0x.ru/?areafix:areatag>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>https://fido.g0x.ru/?areafix:areatag>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.
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. However, 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.) However, 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 HINT: 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.
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 SHOULD apply other filters (a filter of "time" type, for example) to ensure the desired period of time.
(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 MessageFixedHeader 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:
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 <Hour> 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.
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>, <Hour>, <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.
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.
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 <Hour> 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 <Hour> 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.
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.
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 <Hour> value MAY also be empty, and in that case the <Hour>:<Minute>:<Second> value is assumed to be 23:59:60.
If the <Second> and <Minute> and <Hour> values are empty, the <Day> value MAY also be empty, and in that case the <Day>T<Hour>:<Minute>:<Second> value is assumed to be 31T23:59:60.
If the <Second> and <Minute> and <Hour> and <Day> values are empty, the <Month> value MAY also be empty, and in that case the <Month>/<Day>T<Hour>:<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 SHOULD 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.
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:
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.
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 <Hour> 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 <Hour> 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.
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.
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 <Hour> value MAY also be empty, and in that case the <Hour>:<Minute>:<Second> value is assumed to be 00:00:00.
If the <Second> and <Minute> and <Hour> values are empty, the <Day> value MAY also be empty, and in that case the <Day>T<Hour>:<Minute>:<Second> value is assumed to be 01T00:00:00.
If the <Second> and <Minute> and <Hour> and <Day> values are empty, the <Month> value MAY also be empty, and in that case the <Month>/<Day>T<Hour>:<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 SHOULD 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.
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:
(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.
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 <Hour>, 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).
(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 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).
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.
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, <Hour> 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.
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.
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.
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 <Hour> 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
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.)
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 FGHI URLs), a new klugde is introduced. Its line has the following format:
Here <SOH> is a single SOH character (Ctrl+A, ASCII 1); the values <Year> and <Month> and <Day> and <Hour> 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 <Hour> 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 SHOULD 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.
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.
However, 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 SHOULD 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).
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 SHOULD 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 SHOULD 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). However, 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:
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 SOH (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.
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.
However, 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.
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 SHOULD find: Fido MAY find: Fidonet MAY find: bifidobacterium
If looking for word-combinations (phrases), then the plain text MUST include quotes (") around the phrase:
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,
(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 SHOULD use both "from" to obtain the messages from that BBS's address and "sender" to ensure the sender's username. Simultaneously.
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 FGHI URLs, see the corresponding section below), a new klugde is introduced. Its line has the following format:
<SOH>GEO: <Latitude>;<Longitude>
Here <SOH> is a single SOH 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, SHOULD be specified according to the new World Geodetic System (WGS84, see http://en.wikipedia.org/wiki/World_Geodetic_System 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
Here "^a" is a single SOH 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 SHOULD 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) SHOULD be used. Fidonet users SHOULD 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:
<SOH>GEOBOX: <West>,<South>,<East>,<North>
Here <SOH> is a single SOH 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
Here "^a" is a single SOH 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/documentation/kml_tags_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/documentation/kml_tags_21.html for details).
Here "^a" is a single SOH 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) SHOULD 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 SHOULD be used, the decimal degree values MUST be used.
Sysops and network coordinators SHOULD carefully avoid giving out the exact coordinates of Fidonet stations, due to the substantial loss of privacy it causes. The flags SHOULD 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. However, 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) SHOULD 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 SHOULD carefully avoid giving out the exact coordinates of himself (herself), since it MAY cause substantial loss of privacy. The kludge SHOULD 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 SHOULD 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:
<SOH>ORIGEO: <Latitude>;<Longitude>
Here <SOH> is a single SOH character (Ctrl+A, ASCII 1); the values of latitude and longitude MUST use the same prime meridian (Greenwich) and SHOULD 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/documentation/kml_tags_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.
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 SHOULD 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/documentation/kml_tags_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.
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 SHOULD 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 FGHI URLs, see the corresponding section below), a new klugde is introduced. Its line has the following format:
<SOH>TAG: <list of tags>
Here <SOH> is a single SOH character (Ctrl+A, ASCII 1).
The <list of tags> value contains tags, separated by the "|" character.
Example:
<SOH>TAG: SimpleX|new version|announcement
(This example contains three tags: "SimpleX", "new version", and "announcement".)
An echomail message MAY contain several TAG kludges.
Example:
<SOH>TAG: this is the first tag, it spans the whole line <SOH>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 HTML 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:
<SOH>TAG: вѣсть
The ampersand (the "&" character) is special and MUST be represented by "&" or "&" 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:
<SOH>TAG: more sort&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.)
(Here "%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 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: HellEd|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:
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-FGHI 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):
*) 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:
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:
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.San_Izone and Ru.San_Izone.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 SHOULD be able to command his browser to add the "ttop" filter to the URL (and to refresh the view), SHOULD 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 SHOULD 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 SHOULD 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 SHOULD be displayed, then the URL's author MUST refrain from using the "ttop" filter, and the optional parameter "view" SHOULD be used (see section 7.2.3): for example, "view=topl+totr".
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 HTML headers. Messages could also be searched for, using different methods than the regular expressions.
However, it is safe to discard unknown optional parameters of area URLs, though programs interpreting Fidonet URLs SHOULD probably warn their users if an unknown parameter is discarded and when such a warning is appropriate.
7.2.2. Encoded objects within echomail messages -+---------------------------------------------
It is possible for a Fidonet echomail message to contain one or more binary objects, encoded to appear in text-alike lines of characters. Possible methods of encoding include UUE, MIME (RFC 2045-2049), "data:" (RFC 2397), etc.
An echomail message MAY contain several objects, which MAY be encoded in different manner. On the other hand, an encoded object MAY span several Fidonet messages: for example, each of those Fidonet messages MAY bear a section or two of UUE, and the whole bunch of sections is needed to decode a file.
7.2.2.1. Names of encoded objects -+-------------------------------
This subsection is informative.
Most of encoded objects within echomail messages are named.
The name of a UUE-encoded object usually appears within "begin" and/or "section" line of UUE codes.
The name of a MIME-encoded object usually appears within either the "Content-type" header (in 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. How the designated object is determined -+----------------------------------------------
If the <object-path> of an area URL is not empty, then the URL designates either an encoded object as a whole or some inner part of such an object. Abstracting from this inner details, the whole object is called "the designated object" in this subsection.
If the <object-path> of an area URL is not empty, then its <object-name> MUST also be non-empty by definition, and it specifies the name of the designated object.
However, the echomail message base (of the 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.
How "the latest message" itself is defined is beyond the scope of this document. It MAY be the latest received, it MAY be the one with the most up-to-date creation date, etc.
The designated object is always determined as the latest one among those of the name given in <object-name>.
Fidonet browser software MUST ignore objects which have such encodings that browser can not decode; the designated object MUST always be the latest of only those ones of the given name that are able to be decoded from the echomail message base.
If one or several message 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.
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:
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:
However, 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
(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,
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. However, 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.
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. Here 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 SHOULD 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 SHOULD 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:
(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 SHOULD 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 SHOULD 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) SHOULD 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 SHOULD 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. He (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-FGHI 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 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-FGHI 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/
The list of messages SHOULD 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 SHOULD 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 SHOULD 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-FGHI 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.
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 SHOULD 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 SHOULD 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 SHOULD 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-FGHI world:
*) Visit the Keyhole BBS (Google Earth Community Forum):
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.
(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.)
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. However, the total number of all replies in a tree still MAY be displayed near the top of each tree.
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.
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 SHOULD be equally indented below the message to which this message is a reply.
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 SHOULD be equally indented below the message to which this message is a reply.
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.
However, 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 SHOULD appear highlighted (in order for the reader to be able to distinguish them from the other messages) and some navigation elements SHOULD 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-FGHI world:
*) Keyhole BBS (Google Earth Community Forum), if the 'Threaded' button (in the upper right corner) is not pressed: http://tinyurl.com/4l6e3g
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 SHOULD 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, SHOULD 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 SHOULD 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 SHOULD 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.
*) 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 SHOULD 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-FGHI 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 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.
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.
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-FGHI 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:
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 SHOULD 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. However, in such case the browser SHOULD 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-FGHI 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. However, that hidden lines do not start from SOH (Ctrl+A, ASCII 1) symbol, and thus are not kludges. Seen-by stamps, for example, are hidden lines.
Users are generally able to specify (in user settings or just by hotkeys) which kludges and hidden lines are hidden and which are visible in their Fidonet browsers. For example, moderators use hidden lines to control the expansion of their echoes. Many of the non-standard kludges (e.g. location, ICQ UIN, Jabber ID, real name, current music, current mood, etc.) are intended to be read by humans, but are designed as kludges so that thay can be easily hidden by readers annoyed by excessive headers.
If an author of some "area://" URL feels that some kludge and/or some hidden line of the designated message(s) contains relevant information, then the author MAY append an optional parameter to that URL, in order to overcome the user settings and to show the desired kludge or hidden line.
The value of the "kl" optional parameter contains a regular expression; if the rest of the URL designates message(s), then the Fidonet browser, when it shows the body (bodies) of that message(s) to its user, SHOULD NOT hide any of kludges or hidden lines that match the given expression.
See appendix A for the details about regular expressions.
When testing whether a kludge matches a regular expression, the SOH (Ctrl+A, ASCII 1) symbol MUST be omitted. For example, /^[PT]ID/ expression MUST match both "PID" and "TID" kludges, though there is SOH between the line beginning (^) and the first symbol of the kludge ([PT]) in both of the kludges.
Consequently, "kl=" regular expressions differ with "find=" regular expressions for kludges (see subsection 7.2.1.4), and "kl=" expressions are shorter.
Note: It is not necessary for a "kl=" expression to contain "/m" flag, because the "^" construct already matches at the beginning of each kludge.
encoded: ...&kl=/path/i regex: /path/i matches: PATH: 5030/1543 966 5020/4441 5080/1003 5020/830 matches: Now playing: Children of Dune - The Golden Path
encoded: ...&kl=/.*/ regex: /.*/ what it means: The browser SHOULD show all of the kludges and hidden lines of the message(s).
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 SHOULD 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 SHOULD 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/faqbrowse.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.
However, if the "full" optional parameter is present in the URL, the browser SHOULD 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. However, in some circumstances, the URL's author MAY wish to suggest one or more sorting orders that he (or she) sees fit.
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. Here 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 SHOULD 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 SHOULD 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:
(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 SHOULD 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) SHOULD 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 SHOULD 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.
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:
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 SHOULD 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 SHOULD 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.
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 SHOULD 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.
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 character "/" has its literal meaning in the <optional-part> of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (<server>/<request>/<object-path>), playing the role of delimiter between parts of the path. However, inside <server> part the character "/" again MUST have its literal meaning and MUST appear once (and only once!) as the delimiter between parts of the server address.
The <server> part of a faqserv URL MUST be present. The standard Fidonet addressing notation, <zone>:<net>/<node>.<point>@<domain> (see FSP-1004 for details), is used in <server> address. However, some parts of address ("<zone>:", "@<domain>" and/or ".<point>") MAY be omitted (again, see FSP-1004 for details). The <server> part of a faqserv URL specifies the Fidonet address of the station (the FAQ server) which is implied to be queried.
If the <object-path> of a faqserv URL is not empty, then its <object-name> MUST also be non-empty by definition, and it specifies the name of an object embedded in the netmail text of the response sent by that FAQ server. Either that object or some of its inner parts, according to <object-path>, is designated.
However, the netmail response messages MAY contain more than one object of the same name. In this case the designated object is the latest one among only those which are known how to decode them. See section 7.2.2.2 for the details of what object is considered the latest.
The <request> part of a faqserv URL, if present, MUST NOT be empty.
If the <request> part of a faqserv URL is not present at all, then the <object-path> MUST also be empty and "<request>/<object-path>" MUST be omitted entirely, and the preceding "/" character MAY also be omitted. In this case the faqserv URL designates the FAQ server itself, as a Fidonet system. Such an URL MAY designate an action and not a resource; for example, it MAY designate adding the given FAQ server to some list or to a database of FAQ servers.
However, such an action MUST NOT imply sending any requests to the designated server. Different FAQ servers use different names of the default request; it can be 'FILES', 'LIST', 'INDEX', 'HELP' or any other name. That's why a Uniform Resource Locator MUST NOT expect the URL processor to have any extra knowledge besides the data given in the URL itself. If a request is needed, than the corresponding part of a faqserv URL MUST be present and not empty, containing the request (see details below).
If the <request> part of a faqserv URL is present, it contains the request to be sent to the given server. The URL designates either the response as a whole (if the <object-path> is empty), or just an object inside the response (if the <object-path> is not empty).
If the <request> part of a faqserv URL is present, then receiving a message (or several messages) via netmail is implied. However, most of the auxiliary technical and decorative elements of netmail (i.e. taglines, tearlines, origin lines, greeting lines, signature lines, etc.) SHOULD be stripped from the response text when the netmail is received and the response is extracted from it. It is useful to remember that the response MAY span several messages, and sections of it SHOULD be stripped of all their wrappings before they are finally combined.
If is possible for resources designated by faqserv URLs to appear as elements of complex data structures (e.g. as objects on pages of hypertext). Fidonet browsers SHOULD cache the extracted objects and/or raw netmail response letters to allow immediate rendering of the resources already requested before.
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) SHOULD 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 SHOULD be used.
If the moment given in "time" succeedes the date and time of the cached object, then the cached object SHOULD be expelled from the cache, SHOULD be re-requested from the FAQ server.
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.
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.
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. However, files are broadcast there instead of messages. File echo is a shared base of files that have common areatag (file echo identifier) and are distributed through Fidonet via hierarchical and/or p2p-alike connections between individual Fidonet systems (nodes and points).
The fecho URLs take the form:
fecho://<areatag>/<object-path>?<optional-part>
The character "/" has its literal meaning in the <optional-part> of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (<areatag>/<object-path>), playing the role of delimiter between parts of the path. If an <areatag> contains the character "/" in its literal meaning, the character MUST be encoded.
If the <object-path> part is empty, the fecho URL designates the file echo as a whole.
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.)
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.
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).
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) SHOULD 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 SHOULD be used.
If the moment given in "time" succeedes the date and time of the cached object, then the cached object SHOULD be expelled from the cache, SHOULD be re-requested from the external storage.
Future versions of this document MAY introduce some optional parameters for "fecho://" URLs, but Fidonet software MAY safely ignore any unknown parameters in "fecho://" URLs.
7.5. "freq://" scheme -+--------------------
It is possible for Fidonet stations to request files directly from each other; there is even a protocol of distributed file requests, proposed in FSC-0071.
The freq URLs take the form:
freq://<server>/<object-path>?<optional-part>
The character "/" has its literal meaning in the <optional-part> of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (<server>/<object-path>), playing the role of delimiter between parts of the path. However, inside the <server> part the character "/" again MUST have its literal meaning and MUST appear once (and only once!) as the delimiter between parts of the server address.
The <server> part of a freq URL MUST be present. The standard Fidonet addressing notation, <zone>:<net>/<node>.<point>@<domain> (see FSP-1004 for details), is used in <server> address. However, some parts of address ("<zone>:", "@<domain>" and/or ".<point>") MAY be omitted (again, see FSP-1004 for details). The <server> part of a freq URL specifies the Fidonet address of the station that will provide the requested file.
If the <object-path> is empty, the freq URL designates the station itself, as a Fidonet system able to provide files by request.
If the <object-path> of a faqserv URL is not empty, then its <object-name> MUST also be non-empty by definition, and it specifies the name of a file that is requested from the remote Fidonet station specified by the <server> part of the URL. The URL designated either the file itself or one of inner part of the file (according to the structure of the <object-path> part of the URL).
If is possible for resources designated by freq URLs to appear as elements of complex data structures (e.g. as objects on pages of hypertext). Fidonet browsers SHOULD cache the requested files when they are received, in order to allow immediate rendering of the resources already requested before.
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) SHOULD 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 SHOULD be used.
If the moment given in "time" succeedes the date and time of the cached object, then the cached object SHOULD be expelled from the cache, SHOULD be re-requested from the Fidonet station given in the URL.
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 SHOULD be discarded.
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 SHOULD 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.
(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 "aich" parameter's value contains the file's AICH hash, which is defined and used by the system of Advanced Intelligent Corruption Handling in eMule and eMule-compatible servents of ed2k/Kad file exchange. AICH 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, AICH hashes MAY be appended to the "ed2k://" URLs.
(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 SHOULD NOT appear in URLs where "ed2k" or "size" parameters are missing (and where thus "ed2k://" equivalent URLs MAY NOT be built).
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.
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 FGHI 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 FGHI 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.
*) 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 HTTP response MAY vary according to the "Host" field of the incoming HTTP/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 HTTP-hosted files by their URLs.
When HTML 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. However, 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 SHOULD refrain from such practice.
Such an URL, of course, MAY be a FGHI 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.
Nodelist flags indicating FGHI freq capabilities (see section 7.5.8) SHOULD be taken into consideration when the file request is compiled and sent.
7.5.7. FGHI 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.
Hypertext 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. However, 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 FGHI URLs (in square brackets), then the .FUF response SHOULD NOT be built at all: chanses are very high that the requesting node is not aware of FGHI, 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 SHOULD 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 SHOULD 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).
If a Fidonet station is able to accept FGHI URL in file requests and responds with requested files and a .FUF index for each of such (extended) .REQ requests, then the station SHOULD 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):
If the station accepts URL schemes other that "freq://", then such schemes SHOULD be given after the "FUF" flag, and each scheme there MUST be preceded by a semicolon (the character ":").
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 FGHI 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" SHOULD be used instead of "FUF".
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 SHOULD 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 SHOULD 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 "Host" or "Hub" 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 SHOULD 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 FGHI freq capabilities.
Future versions of this document MAY introduce even more optional parameters for freq URLs, encouraging somewhat tighter control how the file is requested. For example, some Fidonet stations MAY deny or delay file requests that are sent in a certain inappropriate time of the day, or day of the week; so a parameter or two MAY appear to specify the time and the week day when the file request is relatively safe.
Programs interpreting freq URLs SHOULD NOT be sure whether it is safe to ignore any of the unknown parameters. Some of future extensions may dramatically change the probability of the success of a file request, especially when such a parameter controls the file request time.
If an unknown parameter is encountered in the freq URL, the user SHOULD always be asked whether it can be discarded safely enough.
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 SHOULD conform to the requirements of the ECMA-262 standard, third edition, section 15.10. (The form and functionality of its regular expressions is modelled after the regular expression facility in the Perl 5 programming language.) Any other Fidonet browsers SHOULD use the PCRE library package, which is an open source software, written by Philip Hazel, and downloadable at http://www.pcre.org/
Fidonet gates in the Web SHOULD use either Perl itself, or PCRE implementation in PHP (preg_grep() function, for example), or any other suitable PCRE-compatible implementation.
A regular expression in a Fidonet URL MUST always take the form
/pattern/flags
The only possible 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). However, 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. HellEd -+---------
HellEd 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 FGHI URL schemes ("netmail:", "areafix:", "echomail:", "area://") since HellEd 1.2.56.
B.2. FGHI URL gate -+----------------
One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service that allows reading Fidonet from WWW by means of FGHI 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 FGHI URL
If the FGHI URL gate's visitor uses a Web browser compatible with HTML 5 draft API registerProtocolHandler(), then it is possible to visit http://fghi.pp.ru/handler.php and automatically register FGHI URLs within such a browser, so that then FGHI 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 HTML 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://" FGHI URLs (though that support is based on the early versions of FGHI 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 FGHI 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 FGHI 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
Blogosphere and forums of the modern Web are both built upon WWW, but HTML seems too generic for them. Necessary elements of blogs and forums, elements like avatars or quoting or contacts, become lumps of non-semantic markup (HTML images, HTML blocks, sections of signature), because WWW browsers do not know of that elements' inner meanings.
Now consider the hypertext Fidonet (the place where FGHI 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 SOH 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 SHOULD 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 SHOULD 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.
(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.)
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) SHOULD 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 THE DOCUMENT ********************************************************************** --- Mithgol's NodePost * Origin: Make Fidonet great again (2:50/88)
