Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1066 [1079] +1078 Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:19 To : All Subj : [1/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 1 of 11 of file FidoURL.txt textbegin.all ********************************************************************** FGHI FIDONET GLOBAL HYPERTEXT INTERCHANGE ********************************************************************** Status: draft Revision: 0.4 Title: FGHI URL, the set of Uniform Resource Locators for Fidonet objects and services Author: Mithgol the Webmaster (Sergey Sokoloff, 2:5063/88) Special thanks to: Shannar (Boris Kassal, 2:463/587) Trooper (Alexey Bezugly, 2:5030/1520.9) NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) Revision Date: 13 Oct 2007 -+-------------------------------------------------------------------- Contents: 1. Status of this document 2. Introduction 3. Key words to indicate requirement levels 4. Changelog of this document 5. General Fidonet URL syntax 5.1. The main parts of URLs 5.1.1. Conformance note 5.1.2. Delimiter guidelines 5.2. URL character encoding 5.2.1. Encoding of original characters 5.2.2. Encoding of octets 5.2.2.1. No corresponding graphic 7-bit character 5.2.2.2. Unsafe characters 5.2.2.3. Reserved characters 5.2.2.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 "subj" 6.1.4. Optional parameter "from" 6.1.5. Optional parameter "body" 6.2. "areafix:" scheme 6.2.1. Optional parameter "uplink" 6.2.2. Optional parameters "unsubscribe" and "leave" 6.2.3. Future optional parameters 6.2.4. Relative "areafix:" URLs 6.3. "echomail:" scheme 6.3.1. Optional parameter "to" 6.3.2. Optional parameter "subject" 6.3.3. Optional parameter "subj" 6.3.4. Optional parameter "from" 6.3.5. Optional parameter "body" 7. Fidonet URL schemes designating objects 7.1. The 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.4. Filters of "find" type 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. Filters of "geomark" type 7.2.1.5.6. Filters of "geofrom" type 7.2.1.6. 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. Regular expressions 7.2.4. Controlling the visibility of kludges and hidden lines 7.2.4.1. Optional parameter "kl" 7.3. "faqserv://" scheme 7.3.1. Optional parameter "bot" 7.3.2. Future optional parameters 7.4. "fecho://" scheme 7.5. "freq://" scheme 7.5.1. Future optional parameters -+-------------------------------------------------------------------- 1. Status of this document -+------------------------ This document is a draft of a Fidonet Standards Proposal (FSP). This document specifies an optional Fidonet standard that can be used both in the Fidonet community and in the Web, and requests discussion and suggestions for improvements. Implementation of the protocols defined in this document is not mandatory, but all implementations of these protocols are expected to adhere to this standard. Distribution of this document is unlimited, provided that its text is not altered without notice. 2. Introduction -+------------- This document specifies several Fidonet schemes of Uniform Resource Locators (URL), providing both syntax and semantics of formalized information for location and access of resources and services via Fidonet. It is designed to conform with the specifications of RFC 1738, so hyperlinks specified according to this document could be used both in Fidonet (echomail, netmail) and in the traditional HTML hypertext environment of the Web and Internet e-mail. Besides its independent significance, this document will serve as the first and the most basic part of FGHI (pronounced 'fig-high', stands for 'Fidonet Global Hypertext Interchange') -- that is future hypertext automation of some currently manual Fidonet operations, delivery and browsing of HTML-alike illustrated hypermedia over the traditional set of echomail and netmail plain-text connections, and probably some other elements of hypertext-over-Fido networking. 3. Key words to indicate requirement levels -+----------------------------------------- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in FTA-1006 (based on RFC 2119). 4. Changelog of this document -+--------------------------- In version 0.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 (section 7.2.3), 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 subsection 7.2.3 (Regular expressions) *) added subsection 7.2.4 (Controlling the visibility of kludges and hidden lines) *) edited subsection 5.2.2.2, the word "Origin" in not unsafe now *) edited the subsection 7.5.1 to reflect the fact that requests may be delayed 5. General Fidonet URL syntax -+--------------------------- Just as there are many different types of Fido objects and services, there are several URL schemes for describing the location of such resources. The generic syntax for URLs provides a framework for new schemes to be established using protocols other than those defined in this document. URLs are used to 'locate' resources, by providing an abstract identification of the resource location. Having located a resource, a Fidonet system may perform a variety of operations on the resource (as might be characterized by such words as 'access', 'subscribe', 'unsubscribe', 'send', 'request', 'show attributes'). 5.1. The main parts of URLs -+------------------------- In general, Fidonet URLs are written as follows: : Any URL contains the name of the scheme being used () followed by a colon and then a string (the ) 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 and . The scheme-specific part of any URL MAY contain other colons. The colon delimiter between and MAY be immediately followed by an optional double slash ("//"). Fidonet programs interpreting URLs MUST treat the delimiter "://" as equivalent to the simple colon before . 5.1.1. Conformance note -+--------------------- This subsection is informative. The Fidonet URL schemes defined in this document consist of lower case letters "a"--"z" only. However, digits, and the characters plus ("+"), period ("."), and hyphen ("-") MUST also be allowed in scheme names, so that Internet schemes conforming with the specifications of RFC 1738 are correctly dealt with. 5.1.2. Delimiter guidelines -+------------------------- In current Internet practice they distinguish between delimiters ":" and "://". The delimiter "://" is often used after scheme names that designate objects and resources ("http://", "ftp://", "gopher://", "nntp://", "ed2k://", "file://", etc.). The delimiter ":" is often used after scheme names that designate actions (e.g. "mailto:", "skype:"). The same difference exists between Fidonet resources (objects) and actions. That's why, though these delimiters MUST always be interpreted as equivalent, it is still RECOMMENDED that ":" SHOULD be used after schemes that designate actions ("netmail:", "echomail:", "areafix:") and "://" SHOULD be used after schemes that designate resources ("area://", "freq://", "fecho://", "faqserv://", etc.). 5.2. URL character encoding -+------------------------- URLs are sequences of characters (i.e., letters, digits, and/or special characters). URLs may be represented in a variety of ways: e.g., ink on paper, or a sequence of octets in a coded character set. The interpretation of URL depends only on the identity of the characters used. It is useful to distinguish between a "character" (distinguishable semantic entity) and an "octet" (an 8-bit byte). In most URL schemes, the character sequences in different parts of a URL are used to represent sequences of octets used in Fidonet services. For example, in the "netmail:" scheme, the Fidonet address, netmail subject and addressee name are such sequences of octets, represented by parts of the URL. That sequences of octets, in turn, represent the original characters (of subject line, or of sysop's name, etc.); each original character is represented by one or more octets. So there are always two mappings, one from URL characters to octets, and the second from octets to original characters: URL character sequence<->octet sequence<->original character sequence 5.2.1. Encoding of original characters -+------------------------------------ The following paragraph is informative. The sequence of octets defined by a component of the URL is subsequently used to represent a sequence of original characters. That process could have a very volatile nature. Being an international network, Fidonet always needs to deal with hundreds of national characters, with dozens of available encoding traditions and character sets. There is a number of FSC (Fidonet Standard Proposal documents) suggesting several kludge-based methods to define which character set is used. However, it is not wise to implement any equivalents to kludges as a required part of every Fidonet URL; and it could be hard to mantain complete lists of all possible character sets inside all programs interpreting Fidonet URLs. (Remember, it should be also made possible for Fidonet URLs to appear and be well interpreted in traditional HTML hypertext environment of the Web, Internet e-mail, instant messaging, etc.) That's why only one encoding, with large enough character set, has to be chosen. The following paragraphs of this subsection are normative. The sequence of octets used in Fidonet URLs MUST always contain UTF-8 encoded representation of original characters. ISO/IEC 10646-1 defines a multi-octet character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. And UTF-8, one of a few so-called UCS transformation formats (UTF), preserves the 7-bit ASCII range, thus providing some compatibility with file systems, parsers and other software elements that rely on 7-bit ASCII values but are transparent to other values. UTF-8 is defined in RFC 2279. Its description can also be found in Unicode Technical Report #4 and in the Unicode Standard, version 2.0. textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... 203. I will not employ an evil wizard if he has a sleazy mustache. --- Orcs are near, All! My Golded 1.1.5-b20060515 is gleaming!.. * Origin: I have a strange feeling, as if I already had a deja vu (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1067 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:25 To : All Subj : [2/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 2 of 11 of file FidoURL.txt textbegin.section 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. 5.2.2.2. Unsafe characters -+------------------------ Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The octet 20 hexadecimal MUST always be encoded. The characters "<" and ">" are unsafe because they are used as the delimiters around tags in HTML hypertext and XML data. The octets 3C and 3E hexadecimal MUST always be encoded. The quote mark (""") is used to delimit URLs in some systems, including valid XHTML and XML. The octet 22 hexadecimal MUST always be encoded. The character "#" is unsafe because it is used in World Wide Web and in other systems to delimit a URL from a fragment or anchor identifier that might follow it. The octet 23 hexadecimal MUST always be encoded. The character "%" is unsafe because it is used for encodings of other characters. The octet 25 hexadecimal MUST always be encoded. The character sequence of triple minus ("-" repeated thrice) has a special meaning in Fidonet and can accidentally start a tearline in some cases (e.g. when a line is wrapped). At least one of the three corresponding octets (2D 2D 2D hexadecimal) MUST be encoded if they follow each other in a sequence. Other characters were declared unsafe in RFC 1738 because some gateways and other transport agents were known to sometimes modify such characters. These characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`". The corresponding octets (7B 7D 7C 5C 5E 7E 5B 5D 60 hexadecimal) MUST always be encoded for the sake of Internet compatibility. All unsafe characters MUST always be encoded within a URL. For example, the character "#" MUST be encoded within URLs even in software programs that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another program that does use them, it will not be necessary to change the URL encoding. 5.2.2.3. Reserved characters -+-------------------------- Many URL schemes reserve certain characters for a special meaning: appearance of that characters in the scheme-specific part of the URL (in 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 FTN domain suffix (see subsection 5.2.2.3.1 for details). The delimiters themselves MUST NOT be encoded. If the character "@" appears inside the areatag itself (i.e. not between the areatag and its suffix), it MUST be encoded, though in any other part of an URL 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 :/. (see FSP-1004 for details). *) In some other schemes the character "/" is reserved to be used in the file path (//.../), 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 "@" 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 "@" suffix after the areatag, and thus distinguish between different areas. The suffix contains the domain name of the FTN of the designated echo area and the preceding "@" symbol. The same rule applies to areatags of file echoes. Examples: area://jabber@fidonet area://jabber@othernet areafix:sysop.talks@fidonet areafix:sysop.talks@othernet fecho://common.files@fidonet fecho://common.files@othernet Domain suffixes are intentionally OPTIONAL, because FTNs generally have their own means to ensure that the names of echomail areas are unique. Some FTNs, for example, use their domain names as prefixes or suffixes for echomail area names (i.e. othernet.areaname, or areaname.othernet), thus eliminating the need of a special URL element, that otherwise would be needed for the same purpose. The character "@" is a reserved character. When it is used as the delimiter between an areatag and its FTN domain name, the character "@" MUST NOT be encoded. 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. 5.2.2.4.1. Specificity note -+------------------------- The rule of equivalence between "+" and "%20" does not apply outside of the scheme-specific part of URL; the plus sign has no special meaning in scheme name, since white spaces are not allowed in scheme names. 5.2.2.4.2. Internet practice note -+------------------------------- The same shortening already happens in Internet. Open http://www.google.ru/search?q=Fidonet+URL URL, and you'll get the Google search for "Fidonet URL" (not "Fidonet+URL"); http://www.google.ru/search?hl=ru&q=Fidonet%2BURL is needed if you're looking for "Fidonet+URL". This practice is not documented in RFC 1738. It is, however, documented in RFC 1630. 5.2.2.5. URLs that span several lines of text in Fidonet -+------------------------------------------------------ Some Fidonet mail editors and other units of software do not permit lines of text to be longer than some limit, e.g. longer than 78 or 80 characters (or a lesser limit, especially inside quotes). If text is longer than limit, it spans several lines (usually a line break is inserted instead of a white space; however, if more than 80 successive characters do not contain white spaces, the line MAY be broken anyway. Or less than 80: the limit MAY vary.) Sometimes it MAY become necessary for a long enough URL to span several lines as well. To distinguish between URLs that span several lines and URLs that just end (by chance) before some end of line, a special mark is needed. Two successive "%" characters MUST NOT appear in URLs (because "%" MUST be followed by two hexadecimal digits), and they are also rare in ordinary text. That's why "%%" character sequence MUST be used before and after a line break in URL, to mark that the line break does not end the URL. If an URL parser encounters "%%" character sequence in the URL it parses, then the parser MUST skip the "%%" sequence, and all characters after it and before the line break, and the line break, and all characters after the line break and before the next "%%" sequence, and that "%%" sequence. Then the URL continues. Quote decoration MAY be encountered after the line break and before the "%%" sequence marking the place where the URL resumes. Fidonet mail editors MAY rearrange the "%%" sequences and line breaks when quoting the quotes. Example: MtW>> To track Fidonet software development in Russian, MtW>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% MtW>> %%Soft+Ru.FIPS/ is often used. MtW>>>>> To track Fidonet software development in Russian, MtW>>>>> a newsreel like area://Ru.FTN.Develop+Ru.FTN.W%% MtW>>>>> %%inSoft+Ru.FIPS/ is often used. The URL used in this example: area://Ru.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/ (the meaning of area:// URLs is explained in section 7.2) Frame decoration MAY be encountered after the line break and before the "%%" sequence marking the place where the URL resumes, or before the line break and after the "%%" sequence marking the place where the URL pauses. Example: +==========================================================+ + + + To track Fidonet software development in Russian, + + a newsreel like area://Ru.FTN.Develop+Ru.FTN.Win%% + + %%Soft+Ru.FIPS/ is often used. + + + +==========================================================+ Any other decoration is also possible, so the URL parser MUST expect it. For example, the URL parser MUST allow more than one line break between the URL-pausing "%%" and the next "%%", because additional line breaks MAY be introduced by quoting. Example: *********************************************************** *********************************************************** ** ** ** ATTENTION! Grab the N5019 pointlist at fecho://p%% ** ** %%ntlist/pnt5019.zip ** ** ** *********************************************************** *********************************************************** MtW> ****************************************************** MtW> ***** MtW> ****************************************************** MtW> ***** MtW> ** MtW> ** MtW> ** ATTENTION! Grab the N5019 pointlist at fecho://p%% MtW> ** MtW> ** %%ntlist/pnt5019.zip MtW> ** MtW> ** MtW> ** MtW> ****************************************************** MtW> ***** MtW> ****************************************************** MtW> ***** The URL used in this example: fecho://pntlist/pnt5019.zip (the meaning of fecho:// URLs is explained in section 7.4) textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... Never judge an iBook by its cover. (Bugzilla Quip System) --- Come with me in the twilight of a summer night for a while... .hack//SIGN * Origin: Be careful, the paranoid ones are always wathing you!.. (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1068 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:27 To : All Subj : [3/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 3 of 11 of file FidoURL.txt textbegin.section To avoid the ambiguity of "%%%", an URL MUST NOT be broken immediately after or immediately before any of "%" characters that belong to the URL. Good example: fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D%% %%1%82.txt Examples of mistakes: fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%% %%%82.txt fecho://example/%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%%% %%D1%82.txt The URL parser MUST be allowed to find where an URL starts. In order to fulfil this expectation, an URL MUST NOT be broken before the first colon (not only immediately before the first colon, but anywhere in the scheme name as well), unless the URL is written somewhere in the place where an URL is always expected (for example, in 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. Example: ed2k://|file|fidopoyka_24_09_06(DivX5_512x384).avi|871219%% %%20|8A706F58C5C7CF6EBA28561A53D60E70|/ Though other schemes generally have other sets of reserved and unsafe characters (for example, in ed2k:// URLs the character "|" is not treated as unsafe, and in Skype URLs like "skype:+79184436168" the character "+" is not reserved), the character "%" is widely used in "%xx" hexadecimal encoding of octets. This means that "%%" sequence is always unsafe in such URLs, and thus always MAY be used as our 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: where is either ":" or "://". The 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: &&&& ... & However, the optional part MAY have the "&" character on URL's end as follows: &&&& ... && (in this case the last "&" character MUST be ignored). Each of these settings is expected to appear in "parameter=value" form: = If the value part is omitted, then the corresponding parameter is assigned an empty value. In this case the "=" character MAY also be omitted. Example of such an optional part of URL: subj=Test&path=&subscribe&to=Test+Robot In this example, parameters "path" and "subscribe" become empty, the parameter "subj" becomes equal to "Test" value, and the parameter "to" becomes equal to "Test Robot" value (because "+" represents the white space, see the corresponding section above). Parameters specified in the optional part of URL are also optional by nature. If a certain parameter does not appear in the given URL at all, it takes a default value; and default values for most of optional parameters are defined below, where the URL schemes are enumerated. The "parameter=value" pairs MAY have an arbitrary order of appearance in an optional part of URL. For example, this optional part of URL: to=Test+Robot&path=&subj=Test&subscribe is equivalent to the previous example. 5.3.1. Dealing with inappropriate reserved characters -+--------------------------------------------------- The reserved character "?" MUST be used only once in a URL; if there are many "?" in some URL, then the first appearance of "?" SHOULD be treated as the delimiter between required and optional parts of that URL, and the remaining "?" MAY be treated as if they were properly encoded ("%3F" character triplets), or even ignored. The reserved character "=" MUST be used only once in a parameter setting; if there are many "=" characters in some setting, then the first appearance of "=" SHOULD be treated as the delimiter between that parameter's name and the parameter's value; and the remaining "=" characters, encountered before the next "&" (or before URL's ending, if it's the rightmost "parameter=value" pair) MAY be treated as if they were properly encoded octets of that parameter's value ("%3D" triplets), or even ignored. "The first appearance" means the leftmost one, because it is natural to parse the scheme-specific part of URL in left-to-right order. The programs interpreting Fidonet URL MAY also stop the whole interpreting and ignore the rest of URL after the position where an inappropriate reserved character is first encountered. This behaviour is especially RECOMMENDED for the programs trying to isolate URLs from some plain text, where the white spaces and/or other delimiters before and after URLs tend to be sometimes omitted by chance. 6. Fidonet URL schemes designating actions -+---------------------------------------- The URL schemes enumerated below designate resources that are most often used in typical actions involving netmail or echomail composed and sent. According to the above section of delimiter guidelines, the ":" character (and not the "://" character triplet) SHOULD be used as the delimiter after 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, :/.@ (see FSP-1004 for details). The character "/" has its literal meaning for this scheme. The netmail URLs take the form: netmail::/.@? However, some parts of address (":", "@" and/or ".") MAY be omitted (see FSP-1004 for details). Examples: netmail:2:5030/1520.9 (point address) netmail:2:5063/88 (node address) netmail:182:5043/1@forestnet (node address outside of Fido) When a "netmail:" hyperlink is used (clicked, followed), a netmail composer software MAY be launched. With this possibility in mind, several optional parameters are designed for the "netmail:" URL scheme. 6.1.1. Optional parameter "to" -+---------------------------- The "to" optional parameter is used to designate the name of netmail addressee. Its default value MAY be "Sysop" or "SysOp". The default value MAY also be determined by some user setting of the netmail composer used to process the "netmail:" URL. Examples: netmail:2:5063/88?to=Mithgol+the+Webmaster netmail:2:5030/1520.9?to=Trooper netmail:2:50/13?to=Alex%20Kocharin 6.1.2. Optional parameter "subject" -+--------------------------------- The "subject" optional parameter is used to designate the subject line of the netmail message composed. Its default value is empty; the default value MAY also be determined by some user setting of the netmail composer used to process the "netmail:" URL. Examples: netmail:2:5063/88?subject=Is+the+hypertext+Fidonet+ready%3F netmail:2:5030/830.17?subject=Yet+another+GoldEd%2b+feature netmail:2:5030/84?to=R50EC&subject=%D0%AD%D1%85%D0%B8 6.1.3. Optional parameter "subj" -+------------------------------ The "subj" optional parameter is used as a shorter equivalent to the "subject" parameter. If the optional parameter "subject" is not present in a given URL, the value of "subj" parameter MUST be taken instead the value of "subject", provided that "subj" is present. Example: netmail:2:5063/88?subj=Long+subject+may+avoid+line+wrapping+limits+:-) 6.1.4. Optional parameter "from" -+------------------------------ The "from" optional parameter is used to designate the name of the netmail letter's author. Its default value is usually defined within the netmail composer settings. Examples: netmail:2:5030/84?to=R50EC&from=Moderator&subject=New+echo+rules netmail:2:5024/1024?from=Moderator&subject=%5B%21%5D+read+only 6.1.5. Optional parameter "body" -+------------------------------ The "body" optional parameter is used to designate the body part of the netmail message composed. (Its default value is empty.) The netmail composer MAY wrap the value of "body" parameter in elements of some user-defined message template (user-defined signature, greeting, etc.) Examples: netmail:2:5063/88?subj=About+FGHI&body=Fidonet+2.0+approached netmail:2:50/0?subj=Complaint&body=That+sysop+is+so+annoying! netmail:2:5030/1520.9?body=HellEd+needs+enormously+large+DLLs 6.2. "areafix:" scheme -+-------------------- Areafixing letters is a special sort of netmail. Areafixing letter commands an uplink node (to which the letter is addressed and sent directly) to change some of its echomail subscription options. For example, the downlink (who writes the letter) may request itself to be subscribed and/or unsubscribed from certain echomail areas, order the rescan of message base, change packer/unpacker settings, view the list of echoes available, etc. An echomail area is a shared base of messages that have common areatag (area identifier) and are distributed through Fidonet via hierarchical and/or p2p-alike connections between individual Fidonet systems (nodes and points). See echomail specifications in FTS-0004. Areafixing letters usually follow a very strict scheme: they must have the downlink's password in subject line (in order for request to be properly authentified), and the name of a certain areafixing robot (e.g. "AreaFix", or "AreaMgr", or "AreaLink") must be given as the addressee name. All of these requirements are confidential by nature, and thus the above described "netmail:" scheme can not be used to design hyperlinks that invite to subscribe or to leave certain Fidonet echomail areas. A separate URL scheme is needed. The "areafix:" scheme is used to designate a Fidonet areafixing action that involves some echomail area, or several areas. The character "/" has its literal meaning for this scheme. The areafix URLs takes the form: areafix:? When "areafix:" hyperlink is used (clicked, followed), it SHOULD launch a netmail composer (or subscription manager) software that automatically composes the proper areafixing letter (addressed to an uplink node and ordering subscription to the given echomail area). However, it is RECOMMENDED that the software asks its user to confirm the ready subscription order or cancel it before that letter is sent. Examples: ...if you're a developer, subscribe via areafix:SU.FidoTech and enjoy there an endless stream of FAQs... ...join today's Fidonet life discussions, use the hyperlink leading to areafix:Ru.Fidonet.Today The 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). Examples: areafix:Ru.FTN.Develop+Ru.FTN.WinSoft areafix:Ru.Computer.Humor%20Ru.Hutor.Filtered areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... 154. I will instruct my Legions of Terror in proper search techniques. --- Orcs are near! My Golded 1.1.5-b20060515 is gleaming!.. * Origin: Be careful, the paranoid ones are always wathing you!.. (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1069 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:29 To : All Subj : [4/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 4 of 11 of file FidoURL.txt textbegin.section If the of "areafix:" URL is not empty, then each of the optional parameters affects each of the designated areas. Any of the given areatags MAY contain "@domain" suffix (see subsection 5.2.2.3.1). 6.2.1. Optional parameter "uplink" -+-------------------------------- Fidonet software usually has its own means to determine which uplink has the requested echomail area and would receive the areafixing netmail letter. 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, :/.@ However, some parts of address (":", "@" and/or ".") MAY be omitted (see FSP-1004 for details). The point number is often omitted in the "uplink" parameter values, because Fidonet points almost never become uplinks. Examples: ...get the echo about embedded systems directly from its moderator, use areafix:Ru.Embedded?uplink=2:5029/32 ...those Titanic echoes never were on the backbone, use areafix:Titanic.PVT?uplink=2:5020/830 and subscribe to one from the primary hub... The "uplink" parameter has no default value; the default behaviour of the subscription management software has to be determined by the network topology of uplink-downlink relations. For example, if an areatag contains "@domain" suffix (see subsection 5.2.2.3.1), then the subscription manager 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 and MAY take, for example, the first of them it has an established link with. If the of an areafix URL contains several "uplink" parameters, they SHOULD be treated as alternatives, and the user SHOULD be asked which uplink (or list of uplinks) is more desired. 6.2.2. Optional parameters "unsubscribe" and "leave" -+-------------------------------------------------- If the "unsubscribe" optional parameter and/or its shorter synonym parameter "leave" appear in the areafix URL, then unsubscription from the given echomail area MUST be ordered instead of subscribing to that area. The value of these parameters is ignored; only their presence or absence determines the behaviour of the subscription manager. It is RECOMMENDED to assign an empty value to them, and to omit the "=" character, thus keeping areafix URL resonably short. Examples: areafix:Ru.PHP?unsubscribe areafix:Ru.List.Citycat.Culture.Music.Announce.FantasyNews?leave 6.2.3. Future optional parameters -+------------------------------- Future versions of this document may introduce even more optional parameters for the areafix URLs, encouraging somewhat tighter control over rescan parameters, packer/unpacker settings and formats, etc. Programs interpreting areafix URLs SHOULD NOT be sure whether it is safe to ignore any of the unknown parameters. Some of future extensions may dramatically change the URL's meaning, as "unsubscribe" is already able to change it to the opposite. If an unknown parameter is encountered in the areafix URL, the user SHOULD always be asked whether it can be discarded safely enough. 6.2.4. Relative "areafix:" URLs -+----------------------------- If an areafix URL is published in the same echomail area that is involved in the designated action, then the MAY be omitted. Examples: ...if you don't like this area, areafix:?unsubscribe from it! ...if you feel that some echomail messages is missing, then your current uplink is not reliable. You'd better subscribe using areafix:?uplink=2:5063/88 If such a relative "areafix:" URL is encountered outside of Fido echomail, then the URL is not valid. 6.3. "echomail:" scheme -+--------------------- Echomail is an important and powerful force in Fidonet. Echomail is, by definition, a broadcast medium. See echomail specifications in FTS-0004. An echomail area is a shared base of messages that have common areatag (area identifier) and are distributed through Fidonet via hierarchical and/or p2p-alike connections between individual Fidonet systems (nodes and points). The "echomail:" scheme is used to designate a Fidonet echomail area as a location where echomail can be sent to. The character "/" has its literal meaning for this scheme. The echomail URLs take the form: echomail:? Examples: echomail:Ru.FTN.Develop echomail:Ru.FTN.WinSoft echomail:FTSC_Public When an "echomail:" hyperlink is used (clicked, followed), an echomail message composer SHOULD be launched. The 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. Examples: echomail:Ru.FTN.Develop+Ru.FTN.WinSoft echomail:Ru.Computer.Humor%20Ru.Hutor.Filtered echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT If the of "echomail:" URL is not empty, then its parameters designate some properties of the message to be posted. If cross-posting is triggered, the message is posted to all of the given areas after it is composed by the user. The optional parameters contain just the initial values for these properties of the message; the user is free to edit them when the message is edited in the echomail composer. 6.3.1. Optional parameter "to" -+---------------------------- The "to" optional parameter is used to designate the name of echomail addressee. Its default value SHOULD be "All", meaning all of the area audience. The default value MAY also be given by some user setting of the echomail composer used to process the "echomail:" URL. Examples: echomail:Ru.FTN.Develop?to=Mithgol+the+Webmaster echomail:Ru.FTN.WinSoft?to=Trooper echomail:Ru.Fidonet.Today?to=Alex%20Kocharin 6.3.2. Optional parameter "subject" -+--------------------------------- The "subject" optional parameter is used to designate the subject line of the echomail message composed. Its default value is empty; the default value MAY also be determined by some user setting of the echomail composer used to process the "echomail:" URL. Examples: echomail:SU.Chainik?subject=How+do+I+set+up+a+tosser%3F echomail:Ru.GoldEd?subject=GoldEd%2b+changelog echomail:R50.Bone?to=R50BM&subject=%D0%AD%D1%85%D0%B8%3F 6.3.3. Optional parameter "subj" -+------------------------------ The "subj" optional parameter is used as a shorter equivalent to the "subject" parameter. If the optional parameter "subject" is not present in a given URL, the value of "subj" parameter MUST be taken instead the value of "subject", provided that "subj" is present. Example: echomail:FTSC_Public?subj=Long+subject+may+avoid+line+wrapping+limits 6.3.4. Optional parameter "from" -+------------------------------ The "from" optional parameter is used to designate the name of the echomail letter's author. Its default value is usually defined within the echomail composer settings. Examples: echomail:Ru.Moderator?to=R50EC&from=Moderator+of+XXX.chat echomail:Ru.Fidonet.Yo?from=Moderator&subject=*+*+*+Rules 6.3.5. Optional parameter "body" -+------------------------------ The "body" optional parameter is used to designate the body part of the echomail message composed. (Its default value is empty.) The echomail composer MAY wrap the value of "body" parameter in elements of some user-defined message template (user-defined signature, greeting, etc.) Examples: echomail:Ru.FTN.Develop?subj=FGHI&body=Fidonet+2.0+approached echomail:400.Link?subj=Interface&body=A+much+better+option%3F echomail:GSS.ParToss?body=Will+it+ever+toss+JAM%3F&subj=Hopes 7. Fidonet URL schemes designating objects -+---------------------------------------- The URL schemes enumerated below designate named objects that can be accessed, read, browsed, etc. According to the above section of delimiter guidelines, the "://" character triplet (and not the ":" character) SHOULD be used as the delimiter after part of such URLs. 7.1. The 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 of their URL always ends with "/", and so URLs are written as follows: :///? The character "/" always has its reserved meaning in part of URL; this character plays the role of delimiter between parts of the path. The part of URL takes one of the following forms: If 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: ://? / The named object itself is a container (e.g. packed archive). The URL designates the root directory of that container. / The is a container (e.g. a packed archive), and its root directory contains ; the URL designates that . If is a directory (i.e. not a file), the is equivalent to its following form, // // The inside is either a container itself (e.g. a packed archive file) or a subdirectory inside container. The URL designates the contents of container or directory. (If is a container with subdirectories, the URL designate the contents of its root directory.) ///...// or ///.../// The 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 . The URL designates either the object itself (if trailing slash is missing and is not a subdirectory) or its contents (if is a subdirectory, that directory's contents is designated; otherwise, / means the root directory of ). 7.1.1. The leading slash and the trailing slash -+--------------------------------------------- The leading slash of is a mere delimiter between and . If the part of a URL is empty, its leading slash MUST be ignored by the program interpreting the URL. If the part of a URL is empty, its leading slash MAY be omitted by the author of that URL, thus the following URLs are equivalent: :///? ://? However, the trailing slash of 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 MUST NOT be ignored. textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... 219. I will be selective in the hiring of assassins. --- Orcs are near! My Golded 1.1.5-b20060515 is gleaming!.. * Origin: And the Soviets ÄÄ waist-deep in the snow ÄÄ marched in (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1070 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:32 To : All Subj : [5/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 5 of 11 of file FidoURL.txt textbegin.section 7.1.2. Dealing with unknown containers -+------------------------------------ Sometimes an 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:///? The character "/" has its literal meaning in the of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (/), playing the role of delimiter between parts of the path. If an contains the character "/" in its literal meaning, the character MUST be encoded. If is empty, the 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 is empty and 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 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 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, of "area://" URL MAY contain several areatags (separated by spaces). In this case the initial message set MUST consist of all the messages from all of the echomail areas labeled by given areatags. Examples: area://CU.Art+CU.Price+CU.Price.Talk+CU.Soft+CU.SysOp+CU.Talk area://Ru.HTML.Chainik%20Ru.HTML.Profy area://IC+ENet.SysOp%20FTSC_Public Any of the areatags MAY contain "@domain" suffix (see subsection 5.2.2.3.1). If an areatag corresponds to an echomail area which is not available on the system, then the initial message set is not complete, and the Fidonet browser SHOULD display some warning about it. For example, the warning MAY contain an URL like areafix:areatag and the user MAY be asked whether he wants to subscribe and rescan the missing echomail area from the uplink. A warning is especially RECOMMENDED when all of the given areatags correspond to the missing echoes. Any of areafix:areatag URLs in such a warning, if present, MUST preserve "@domain" suffixes given in the "area://" URL for missing areas. (If is empty and does not contain message filters, then the area URL designates an area as a whole. Examples: area://Ru.FTN.Develop area://Ru.FTN.Winsoft/ area://FTSC_Public? area://Ru.Fidonet.Today/? In this case, if the area is not available on the system, the browser MAY redirect its user to some external echomail storage, such as WebBBS or Usenet mirror.) The final message set, determined by the URL, MUST also be formed if 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 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 of an area URL, then area://? 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 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 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: = 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. Examples: area://Ru.Fidonet.Today/?msgid=2:5063/88%2043a94313 area://R50.SysOp+R50.Bone?msgid=2:5063/88+44585f4d A message from the initial message set appears in the filtered set (defined by a "msgid" filter) if and only if the message contains the MSGID kludge equal to the value of the filter. Most likely, the filtered set contains only one message. It MAY contain several messages, because though FTS-0009 states that two messages from a given system MAY NOT have the same serial number within a three years, the message base itself MAY span more than three years. In this case, the URL's author SHOULD apply other filters (a filter of "time" type, for example) to ensure the desired period of time. Example: area://R50.Bone/?msgid=2:50/13+46c01f2e&time=2007 (The meaning of "time" filters is described below.) Note that the "msgid" filter MAY designate such a message that is not present in the initial message set. In this case the filtered set is empty. A Fidonet browser MAY collect such events as minor warnings and MAY implement some user interface for the user to ask uplink(s) for a rescan of the area(s), or to query some external archive of Fidonet echomail messages in search for the desired messages, or to try some other means of getting the desired messages. If there are several "msgid" filters in , 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: //T:: Example: area://Ru.FTN.Develop/?time=2007/08/18T15:56:54 The 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 value MUST always be two digits: 01 for January, 02 for February, ..., 11 for November, 12 for December. The value MUST always be two digits: 01 for the first day of the month, 02 for the second, etc. The value MUST always be two digits, from "00" to "23". The value MUST always be two digits, from "00" to "59". The 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. textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... 66. My security keypad will actually be a fingerprint scanner. --- Orcs are near! My Golded 1.1.5-b20060515 is gleaming!.. * Origin: Be careful, the paranoid ones are always wathing you!.. (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1071 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:34 To : All Subj : [6/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 6 of 11 of file FidoURL.txt textbegin.section 7.2.1.2.1.1. Empty values -+----------------------- Any of the six values (year, month, day, hour, minute and/or second) MAY be empty in this form of the filter; it means that the corresponding part of the DateTime of the message is not checked. The adjacent separators ("/", "T", ":") MAY also be skipped; however, to maintain some difference between the appearance of two-digit values of , , , and , 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 value is not empty, the preceding colons (":") MUST be present. Example: area://Ru.FTN.Develop/?time=::54 If the value is not empty, the preceding colon (":") MUST be present. Example: area://Ru.FTN.Develop/?time=:56 If the value is not empty, then either the succeeding colon (":") or the preceding time separator ("T") MUST be present. Examples: area://Ru.FTN.Develop/?time=T15 area://Ru.FTN.Develop/?time=15: If the value is not empty, then either the preceding slashes ("/") or the succeeding time separator ("T") MUST be present. Examples: area://Ru.FTN.Develop/?time=18T area://Ru.FTN.Develop/?time=2007//18 If the value is not empty, then either the preceding slash ("/") or the succeeding slash MUST be present. Examples: area://Ru.FTN.Develop/?time=2007/08 area://Ru.FTN.Develop/?time=08/ 7.2.1.2.2. Upper limit -+-------------------- This variant of a "time" filter's value has the following form: -//T:: (Notice the "-" character before the values.) Example: area://Ru.FTN.Develop/?time=-2007/08/18T15:56:54 The number of digits and the meaning of the six values are the same as for the single moment (see section 7.2.1.2.1). A message from the initial message set appears in the filtered set (defined by the given upper limit) if and only if the message's date and time value is not greater than the date and time value given by the filter. All the six values of message's date and time (year, month, day, hour, minute and second) are checked in the following order: 1) Message's year is compared with filter's year. If message's year is greater than filter's year, the message MUST NOT appear in the filtered set. If message's year is lesser than filter's year, the message MUST appear in the filtered set. If message's year is equal to the filter's year, proceed to the next step. 2) Message's month is compared with filter's month. If message's month is greater than filter's month, the message MUST NOT appear in the filtered set. If message's month is lesser than filter's month, the message MUST appear in the filtered set. If message's month is equal to the filter's month, proceed to the next step. 3) Message's day is compared with filter's day. If message's day is greater than filter's day, the message MUST NOT appear in the filtered set. If message's day is lesser than filter's day, the message MUST appear in the filtered set. If message's day is equal to the filter's day, proceed to the next step. 4) Message's hour is compared with filter's hour. If message's hour is greater than filter's hour, the message MUST NOT appear in the filtered set. If message's hour is lesser than filter's hour, the message MUST appear in the filtered set. If message's hour is equal to the filter's hour, proceed to the next step. 5) Message's minute is compared with filter's minute. If message's minute is greater than filter's minute, the message MUST NOT appear in the filtered set. If message's minute is lesser than filter's minute, the message MUST appear in the filtered set. If message's minute is equal to the filter's minute, proceed to the next step. 6) Message's second is compared with filter's second. If message's second is greater than filter's second, the message MUST NOT appear in the filtered set. If message's second is lesser or equal to the filter's second, the message MUST appear in the filtered set. The first step of the check, as well as several next steps, MAY be skipped if the corresponding leftmost values are empty (see the next subsection). Unlike in the single moment form, the values of the upper limit form of a "time" filter MAY NOT be empty in arbitrary order; however, the leftmost values MAY be emptied from left to right, and the rightmost values MAY be emptied from right to left. 7.2.1.2.2.1. Empty leftmost values -+-------------------------------- The 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 value is empty, the 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 and values are empty, the 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 and and values are empty, the 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 and and and values are empty, the value MAY also be empty, and in that case the fifth step of the above checking MUST also be skipped, as if message's minute and filter's minute were equal. To find out whether a separator ("/", or "T", or ":") MAY be skipped, consult the subsection 7.2.1.2.1.1: the rules on that matter are the same here. Example: area://Ru.FTN.Develop/?time=-18T15:56:54 This URL designates the messages that were written (in Ru.FTN.Develop echomail area) either before the 18th day of any month in any year, or not after 15:56:54 of the 18th day. 7.2.1.2.2.2. Empty rightmost values -+--------------------------------- The value MAY be empty, and in that case the value is assumed to be 60. If the value is empty, the value MAY also be empty, and in that case the : value is assumed to be 59:60. If the and values are empty, the value MAY also be empty, and in that case the :: value is assumed to be 23:59:60. If the and and values are empty, the value MAY also be empty, and in that case the T:: value is assumed to be 31T23:59:60. If the and and and values are empty, the value MAY also be empty, and in that case the /T:: 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. Example: area://Ru.FTN.Develop/?time=-05/31 This URL designates the messages that were written (in Ru.FTN.Develop echomail area) before the summer in any year. It is equivalent to the following form: area://Ru.FTN.Develop/?time=-05/31T23:59:60 7.2.1.2.3. Lower limit -+-------------------- This variant of a "time" filter's value has the following form: //T::- (Notice the "-" character after the values.) Example: area://Ru.FTN.Develop/?time=2007/08/18T15:56:54- The number of digits and the meaning of the six values are the same as for the single moment (see section 7.2.1.2.1). A message from the initial message set appears in the filtered set (defined by the given lower limit) if and only if the message's date and time value is not lesser than the date and time value given by the filter. All the six values of message's date and time (year, month, day, hour, minute and second) are checked in the following order: 1) Message's year is compared with filter's year. If message's year is greater than filter's year, the message MUST appear in the filtered set. If message's year is lesser than filter's year, the message MUST NOT appear in the filtered set. If message's year is equal to the filter's year, proceed to the next step. 2) Message's month is compared with filter's month. If message's month is greater than filter's month, the message MUST appear in the filtered set. If message's month is lesser than filter's month, the message MUST NOT appear in the filtered set. If message's month is equal to the filter's month, proceed to the next step. 3) Message's day is compared with filter's day. If message's day is greater than filter's day, the message MUST appear in the filtered set. If message's day is lesser than filter's day, the message MUST NOT appear in the filtered set. If message's day is equal to the filter's day, proceed to the next step. 4) Message's hour is compared with filter's hour. If message's hour is greater than filter's hour, the message MUST appear in the filtered set. If message's hour is lesser than filter's hour, the message MUST NOT appear in the filtered set. If message's hour is equal to the filter's hour, proceed to the next step. 5) Message's minute is compared with filter's minute. If message's minute is greater than filter's minute, the message MUST appear in the filtered set. If message's minute is lesser than filter's minute, the message MUST NOT appear in the filtered set. If message's minute is equal to the filter's minute, proceed to the next step. 6) Message's second is compared with filter's second. If message's second is lesser than filter's second, the message MUST NOT appear in the filtered set. If message's second is greater or equal to the filter's second, the message MUST appear in the filtered set. The first step of the check, as well as several next steps, MAY be skipped if the corresponding leftmost values are empty (see the next subsection). Unlike in the single moment form, the values of the lower limit form of a "time" filter MAY NOT be empty in arbitrary order; however, the leftmost values MAY be emptied from left to right, and the rightmost values MAY be emptied from right to left. textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... 2. My ventilation ducts will be too small to crawl through. --- Come with me in the twilight of a summer night for a while... .hack//SIGN * Origin: Be careful, the paranoid ones are always wathing you!.. (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1072 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:36 To : All Subj : [7/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 7 of 11 of file FidoURL.txt textbegin.section 7.2.1.2.3.1. Empty leftmost values -+-------------------------------- The 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 value is empty, the 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 and values are empty, the 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 and and values are empty, the 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 and and and values are empty, the value MAY also be empty, and in that case the fifth step of the above checking MUST also be skipped, as if message's minute and filter's minute were equal. To find out whether a separator ("/", or "T", or ":") MAY be skipped, consult the subsection 7.2.1.2.1.1: the rules on that matter are the same here. Example: area://Ru.FTN.Develop/?time=18T15:56:54- This URL designates the messages that were written (in Ru.FTN.Develop echomail area) either after the 18th day of any month in any year, or not before 15:56:54 of the 18th day. 7.2.1.2.3.2. Empty rightmost values -+--------------------------------- The value MAY be empty, and in that case the value is assumed to be 00. If the value is empty, the value MAY also be empty, and in that case the : value is assumed to be 00:00. If the and values are empty, the value MAY also be empty, and in that case the :: value is assumed to be 00:00:00. If the and and values are empty, the value MAY also be empty, and in that case the T:: value is assumed to be 01T00:00:00. If the and and and values are empty, the value MAY also be empty, and in that case the /T:: 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. Example: area://Ru.FTN.Develop/?time=09/01- This URL designates the messages that were written (in Ru.FTN.Develop echomail area) after the summer in any year. It is equivalent to the following form: area://Ru.FTN.Develop/?time=09/01T00:00:00- 7.2.1.2.4. Interval of time -+------------------------- This variant of a "time" filter's value combines the previous two variants: - In details it looks like this: //T::-%% %%//T:: (the character sequence "%%" is used here to mark the place where a line break appears inside the URL, and then where the URL resumes; see section 5.2.2.5 for details). A message from the initial message set appears in the filtered set (defined by the given interval of time) if and only if the message's date and time value conforms to both of the given limits, as described in sections 7.2.1.2.2 and 7.2.1.2.3. 7.2.1.2.4.1. Empty rightmost values -+--------------------------------- The righmost values for each of the combined limits MAY be empty in right-to-left order (, or and , or and and , and so on). To find out whether a separator ("/", or "T", or ":") MAY be skipped as well, consult the subsection 7.2.1.2.1.1: the rules on that matter are the same here. The empty rightmost values of the lower limit are assumed to be the lowest possible (see section 7.2.1.2.3.2). The empty rightmost values of the upper limit are assumed to be the highest possible (see section 7.2.1.2.2.2). Example: area://Ru.FTN.Develop/?time=2007/06-2007/08 This URL designates the messages that were written (in Ru.FTN.Develop echomail area) in the summer of 2007. It is equivalent to the following form: area://Ru.FTN.Develop/?time=2007/06/01T00:00:00-2007/%% %%08/31T23:59:60 (the character sequence "%%" is used here to mark the place where a line break appears inside the URL, and then where the URL resumes; see section 5.2.2.5 for details). 7.2.1.2.4.2. Empty leftmost values -+-------------------------------- The number of empty leftmost values in the part of the filter's value MUST NOT be greater than the number of of empty leftmost values in the part. If such a value is empty in both parts (in and in ), then the corresponding value of the message is not checked (see section 7.2.1.2.2.1 and section 7.2.1.2.3.1). Example: area://Ru.FTN.Develop/?time=00:00:00-11:59:60 This URL designates the messages that were written (in Ru.FTN.Develop echomail area) before the noon of any day. ( and and values are empty in both part of the filter's value.) If such a value is empty in the only, then the value MUST be assumed to be equal to the corresponding value of the part. For example, the following URL: area://Ru.FTN.Develop/?time=2007/08/18-26T is equivalent to: area://Ru.FTN.Develop/?time=2007/08/18-2007/08/26 The leftmost values and the rightmost values MAY be empty simultaneously; however, some non-empty values (just one, or more) MUST appear in each part (in and in ) in this form of the filter. (In the previous example, and and is empty in both parts as the rightmost, and and is empty in as the leftmost.) To find out whether a separator ("/", or "T", or ":") MAY be skipped, consult the subsection 7.2.1.2.1.1: the rules on that matter are the same here. 7.2.1.2.5. Complex filter -+----------------------- This variant of a "time" filter's value is a space-separated list of two or more of the above variants: single moments, and/or upper limits, and/or lower limits, and/or intervals of time. A message from the initial message set appears in the filtered set (defined by the given complex) if and only if it appears in at least one of the individual filtered sets defined by the space-separated subfilters. In other words, the filtered set of a complex "time" filter is a union of sets defined by its subfilters. Example: area://Ru.FTN.Develop/?time=2004-2005+2006%202007- is equivalent to: area://Ru.FTN.Develop/?time=2004- 7.2.1.2.6. The type-total set for "time" filters -+---------------------------------------------- The type-total set for "time" filters is the intersection of the filtered sets defined by "time" filters. Example: area://Ru.FTN.Develop/?time=2004-2006&time=2005-2007 is equivalent to: area://Ru.FTN.Develop/?time=2005-2006 7.2.1.2.7. Ordinal day number in the year -+--------------------------------------- In each of the above forms of the "time" filter, if both and values are not empty, the 3-digit ordinal day number in the year MAY replace "/" 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 / 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 "/" non-empty values with a slash between them. Example: area://Ru.FTN.Develop/?time=2007/238 is equivalent to: area://Ru.FTN.Develop/?time=2007/08/26 Such an URL form MAY come in handy for devices and/or software units that are not intelligent enough to handle the entire calendar with its twelve months. 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 and/or and/or and/or and/or and/or value is expected. The URL-parsing software MUST substitute the corresponding component of the current date or time for the original "now" value. For example, if the URL is parsed at the very noon, then area://Ru.FTN.Develop/?time=2007/08/26TnOw:NoW is equivalent to: area://Ru.FTN.Develop/?time=2007/08/26T12:00 The ordinal day number in the year (see section 7.2.1.2.7) MAY NOT be substituted by "now"; use "now/now" instead, in order to substitute the current month and day pair. If "now" value is substituted for and/or and/or , then each of the slashes ("/") used as separators MUST NOT be omitted from the date. (This is REQUIRED to distinguish the appearance of dirrerent elements of the date, because just one slash, like in "now/", is not enough to judge whether it is year value or month value.) Example: area://Ru.FTN.Develop/?time=now/06-08/ This URL designates all the messages in Ru.FTN.Develop echomail area that were written (or will be written) in summer of this year. 7.2.1.2.9. TrueTime kludge -+------------------------ Kludges (also known as klugde lines or control paragraphs) are special lines embedded in the text body of a Fidonet message. Sometimes kludges are used to support some new addressing and other control information, sometimes they contain pieces of auxiliary information about the message's author (location, ICQ UIN, Jabber ID, real name, current music, mood, etc.) See technical details in FTS-4000. And to support the new addressing (to support using "time" filters in FGHI URLs), a new klugde is introduced. Its line has the following format: TrueTime: //T// Here is a single SOH character (Ctrl+A, ASCII 1); the values and and and and and 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 and and and and and 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. textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... Lest the dead who is forsaken may not be happy now (C) E. A. Poe --- Come with me in the twilight of a summer night for a while... .hack//SIGN * Origin: And the Soviets ÄÄ waist-deep in the snow ÄÄ marched in (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1073 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:38 To : All Subj : [8/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 8 of 11 of file FidoURL.txt textbegin.section 7.2.1.2.10. Optional parameter "usetz" -+------------------------------------ Current practice in FidoNet is to transmit message times in local time, and this document assumes that the value of a "time" filter is checked against the local time of the messages. This is the default behaviour. 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). Example: area://Ru.FTN.Develop/?time=2007/241&usetz If the "usetz" optional parameter is present in the URL, then "now" values (see section 7.2.1.2.8) MUST be substituted in current UTC. 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" parameter uses standard Fidonet addressing notation, :/.@ (see FSP-1004 for details). If several "from" filters are present in the 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.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" contains a regular expression; a message from the initial message set appears in the filtered set (defined by the given regular expression) if and only if that message matches the given expression. (See section 7.2.3 for the details about regular expressions.) Examples: encoded: ...&find=/\bFido(net)%3f\b/i regex: /\bFido(net)?\b/i matches: Fido matches: FIDOnet matches: FidoNet does not match: Fidonet-alike does not match: Fidobrowser does not match: fidoshnik does not match: triffidos encoded: ...&find=/(P(2P)%7b1,4%7d%7cfile\s%2bexchange)/ regex: /(P(2P){1,4}|file\s+exchange)/ matches: P2P matches: P2P2P2P matches: P2P2P2P2P matches: file exchange matches: file exchange does not match: P2P2P2P2PP2P2P2P2P does not match: P2P2P2P2P2P does not match: fileexchange does not match: file_exchange does not match: p2p does not match: FiLe ExChanGe Fidonet messages are able to contain kludges (see technical details in FTS-4000). Consequently, it is possible for an URL to designate a set of messages tagged by a certain kludge type or certain kludge values. The corresponding regular expression starts with ^\x1 or ^\01 symbols, which mean the begginning of line immediately followed by the SOH (Ctrl+A, ASCII 1) symbol. The expression always uses the multi-line mode of matching (see section 7.2.3), thus the "^" construct matches at the beginning of each kludge. Examples: encoded: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i regex: /^\01Real\s*name:\s+(?!\s).*/i Matches all messages with non-empty realname kludges. Useful for moderators who check how the subscribers identify themselves. encoded: ...&find=/%5E\x1Category:\s.*(music%7cweather)/i regex: /^\x1Category:\s.*(music|weather)/i matches kludge: Category: music matches kludge: Category: hardcore music matches kludge: Category: weather matches kludge: Category: real life, bad weather, bad mood Matches all messages that belong to at least one of the given categories. Useful to collect a single-theme subset of messages from a blog or any other information channel with a wide set of themes. If there's a need for some URL to contain several regular expressions and to designate Fidonet messages that match at least one of those regular expressions, then the URL's author MUST unite those expressions as alternative branches of one single pattern (expression1|expression2|...) as shown in the above category-related example. If there's a need for some URL to contain several regular expressions and to designate Fidonet messages that match every of those regular expressions, then the URL's author MUST use several "find" parameters in that URL. Because it is REQUIRED to accomplish the above described behaviour, the type-total set for "find" filters is the intersection of the filtered sets defined by "find" filters. Examples: find=/%5E\01Location:\s*Moscow/i&find=/%5E(%3f!\x1).*Kremlin/i Regular expression 1: /^\01Location:\s*Moscow/i Regular expression 2: /^(?!\x1).*Kremlin/i Find messages with kludge "Location: Moscow" (or even "Location:Moscow" without a space) that contain the word "Kremlin" outside of kludge lines. find=/%5E\x1Category:\s/i&find=/%5E\01Now\s%2bplaying:\s/i Regular expression 1: /^\x1Category:\s/i Regular expression 2: /^\01Now\s+playing:\s/i Find messages that contain both kludges "Category: " and "Now playing: " with training spaces after colon. 7.2.1.5. Geographically referenced echomail -+----------------------------------------- An echomail message MAY bear some spatial reference to a point or an area on the Earth surface. The message's origin (a node or a point of Fidonet) also exists somewhere on Earth. Both of these facts MAY be used to pick echomail messages related to some area on the surface of the Earth, effectively turning an echomail message base to a kind of GIS spatial database. 7.2.1.5.1. GEO kludge -+------------------- Kludges (also known as klugde lines or control paragraphs) are special lines embedded in the text body of a Fidonet message. Sometimes kludges are used to support some new addressing and other control information, sometimes they contain pieces of auxiliary information about the message's author (location, ICQ UIN, Jabber ID, real name, current music, mood, etc.) See technical details in FTS-4000. And to support the new addressing (to support using "BBOX" filters in FGHI URLs, see the corresponding section below), a new klugde is introduced. Its line has the following format: GEO: ; Here is a single SOH character (Ctrl+A, ASCII 1). The 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 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). 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: GEOBOX: ,,, Here is a single SOH character (Ctrl+A, ASCII 1). The and values correspond to the bounding lines of longitude; the and 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 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). Example: ^aGEOKML: http://Mithgol.Ru/Earth/shubino.kmz Here "^a" is a single SOH character (Ctrl+A, ASCII 1). textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... 213. I will not wear long, heavy cloaks. --- Just as the clouds have gone to sleep, Angels can be seen in heaven's keep * Origin: I have a strange feeling, as if I already had a deja vu (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1074 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:40 To : All Subj : [9/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 9 of 11 of file FidoURL.txt textbegin.section 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 probably not alphanumeric, so it MUST be avoided, and the boundary between the integral and the fractional parts of a decimal numeral is not marked in the degree values of the following flags. The LONE or LONW flag represents the location east or west of the prime meridian, respectively. The longitude value immediately follows the flag; the decimal dot is assumed after the third digit; the value MUST be preceded by some zero-padding if the integral part of the longitude is actually lesser than three digits. Example: LONE03805 (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 immediately follows the flag; the decimal dot is assumed after the second digit; the value MUST be preceded by a zero if the integral part of the latitude is actually lesser than two digits. Example: LATN4457 (This flag means 44.57 degrees to the north of the equator.) The constraints enumerated in section 7.2.1.5.4 are all in effect: the Greenwich meridian MUST be used, the WGS84 geoid SHOULD be used, the decimal degree values MUST be used. Example of a nodelist line: ,88,FGHI_Global_Headlight_Ignited,Gelendzhik, Sergey_Sokoloff,00-00-000000,300,IBN:1978, INA:Fidonet.Mithgol.Ru,U,TSU,LATN4457,LONE03805 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. 7.2.1.5.5. Filters of "geomark" type -+---------------------------------- The "geomark" filter's value contains the four coourdinate constraints in ,,, order, which is compatible with the same order that BBOX information has by default in 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. Example: area://CU.Talk/?geomark=37.9,44.4,38,44.9 A message from the initial message set appears in the filtered set (defined by the given coordinates) if and only if at least one (i.e. one or more) of the following requirements are met: 1) One (or more) of the message's GEO kludges corresponds to a place on the Earth (to a dot on the map) that belongs to the region defined by the filter's value. 2) One (or more) of the message's GEOBOX kludges corresponds to an area on the Earth (to a rectangle on a cylindrical map projection, e.g. on a Mercator map) that intersects with the region defined by the filter's value. 3) One (or more) of the message's GEOKML kludges contains an URL that correspond to a KML or KMZ document that in turn contain one or more elements (placemarks, polygons, paths, map overlays, photo overlays, etc.) that belong to (or intersect with) the region defined by the filter's value. The third of these requirements fails if the KML or KMZ is not immediately available (e.g. an Internet URL for a Fido node currently offline or without an Internet link at all, or a Fidonet URL corresponding to a resource imbued with lag, like faqserv:// or freq:// to another node, or like area:// or fecho:// to an area that weren't subscribed to) and/or if the URL parser software in not intelligent enough to analyze the KML elements in order to pick their coordinates. Echomail authors 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 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.6. Filters of "geofrom" type -+---------------------------------- The "geofrom" filter's value contains the four coourdinate constraints in ,,, order, which is compatible with the same order that BBOX information has by default in 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. Example: area://CU.Fido/?geofrom=37.5,44.1,37.8,44.4 A message from the initial message set appears in the filtered set (defined by the given coordinates) if and only if at least one (i.e. one or more) of the following requirements are met: 1) 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. 2) 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 second 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) to ensure that their echomail messages are correctly processed by filters of "geofrom" type. If several "geofrom" filters are present in the 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. Future message filters -+----------------------------- Future versions of this document MAY introduce additional message filters. For example, hypertext messages could be filtered on the basis of meta information in their 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 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 of an area URL is not empty, then its 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 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 . 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 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. 7.2.3. Regular expressions -+------------------------ It is possible for an optional parameter of an area URL to contain a regular expression. In section 7.2.1.4 a regex is used to specify the designated message(s); in section 7.2.4.1 a regex defines whether a kludge is visible. The language of regular expressions has several dirrerent dialects. Perl Compatible Regular Expressions (PCRE) are chosen here as the RECOMMENDED; that's because PCRE engine has a rich set of features, and because the engine is already embedded in ECMAScript-compatible browsers of the modern Web. The language of regular expressions is far beyond the scope of this document. The article http://en.wikipedia.org/wiki/PCRE (in Wikipedia) and the external links referenced there are probably the best to start learning how to write PCRE regexes. Some Fidonet browsers have their own JavaScript engines, that SHOULD conform to the requirements of the ECMA-262 standard, third edition, section 15.10. (The form and functionality of its regular expressions is modelled after the regular expression facility in the Perl 5 programming language.) Any other Fidonet browsers SHOULD use the PCRE library package, which is an open source software, written by Philip Hazel, and downloadable at http://www.pcre.org/ Fidonet gates in the Web SHOULD use either Perl itself, or PCRE implementation in PHP (preg_grep() function, for example), or any other suitable PCRE-compatible implementation. A regular expression in a Fidonet URL MUST always take the form /pattern/flags The only possible 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). textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... Software is like sex: it's better when it's free. (Linus Torvalds) --- Orcs are near, All! My Golded 1.1.5-b20060515 is gleaming!.. * Origin: And the Soviets ÄÄ waist-deep in the snow ÄÄ marched in (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1075 [1079] Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:42 To : All Subj : [10/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 10 of 11 of file FidoURL.txt textbegin.section 7.2.4. Controlling the visibility of kludges and hidden lines -+----------------------------------------------------------- This section is informative. Its subsection is normative. Kludges (also known as klugde lines or as control paragraphs) are special lines embedded in the text body of a Fidonet message. Sometimes kludges are used to support new addressing and other control information, sometimes they contain pieces of auxiliary information about the message's author (location, ICQ UIN, Jabber ID, real name, current music, current mood, etc.) See technical details in FTS-4000. It is said in FTS-4000 that the contents of kludges are intended for the programs processing the message (or the copies of the message) and not for presentation on the user interface level. Fidonet messages usually contain some other special lines of the same nature, intended for the programs processing the message, and usually hidden from the user. However, that hidden lines do not start from SOH (Ctrl+A, ASCII 1) symbol, and thus are not kludges. Seen-by stamps, for example, are hidden lines. Users are generally able to specify (in user settings or just by hotkeys) which kludges and hidden lines are hidden and which are visible in their Fidonet browsers. For example, moderators use hidden lines to control the expansion of their echoes. Many of the non-standard kludges (e.g. location, ICQ UIN, Jabber ID, real name, current music, current mood, etc.) are intended to be read by humans, but are designed as kludges so that thay can be easily hidden by readers annoyed by excessive headers. If an author of some "area://" URL feels that some kludge and/or some hidden line of the designated message(s) contains relevant information, then the author MAY append an optional parameter to that URL, in order to overcome the user settings and to show the desired kludge or hidden line. 7.2.4.1. Optional parameter "kl" -+------------------------------ This subsection is normative. The value of the "kl" optional parameter contains a regular expression; if the rest of the URL designates message(s), then the Fidonet browser, when it shows the body (bodies) of that message(s) to its user, SHOULD NOT hide any of kludges or hidden lines that match the given expression. See section 7.2.3 for the details about regular expressions. When testing whether a kludge matches a regular expression, the SOH (Ctrl+A, ASCII 1) symbol MUST be omitted. For example, /^[PT]ID/ expression MUST match both "PID" and "TID" kludges, though there is SOH between the line beginning (^) and the first symbol of the kludge ([PT]) in both of the kludges. Consequently, "kl=" regular expressions differ with "find=" regular expressions for kludges (see subsection 7.2.1.4), and "kl=" expressions are shorter. Note: It is not necessary for a "kl=" expression to contain "/m" flag, because the "^" construct already matches at the beginning of each kludge. Examples: encoded: ...&kl=/%5ep/i regex: /^p/i matches: PATH: 5030/1543 966 5020/4441 5080/1003 5020/830 matches: PID: GED+W32 1.1.5-b20060515 encoded: ...&kl=/path/i regex: /path/i matches: PATH: 5030/1543 966 5020/4441 5080/1003 5020/830 matches: Now playing: Children of Dune - The Golden Path encoded: ...&kl=/.*/ regex: /.*/ what it means: The browser SHOULD show all of the kludges and hidden lines of the message(s). 7.3. "faqserv://" scheme -+---------------------- FAQ servers are Fidonet stations that accept special requests containing file names (or aliases) of certain texts. Such requests are sent via Fidonet netmail. The FAQ server processes the request and sends the requested text to the sender of request; the text is sent via Fidonet netmail in a single letter (as a whole) or in several letters (in sections). The faqserv URLs take the form: faqserv:////? The character "/" has its literal meaning in the of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (//), playing the role of delimiter between parts of the path. However, inside 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 part of a faqserv URL MUST be present. The standard Fidonet addressing notation, :/.@ (see FSP-1004 for details), is used in address. However, some parts of address (":", "@" and/or ".") MAY be omitted (again, see FSP-1004 for details). The part of a faqserv URL specifies the Fidonet address of the station (the FAQ server) which is implied to be queried. If the of a faqserv URL is not empty, then its 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 , 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 part of a faqserv URL, if present, MUST NOT be empty. If the part of a faqserv URL is not present at all, then the MUST also be empty and "/" MUST be omitted entirely, and the preceding "/" character MAY also be omitted. In this case the faqserv URL designates the FAQ server itself, as a Fidonet system. Such an URL MAY designate an action and not a resource; for example, it MAY designate adding the given FAQ server to some list or to a database of FAQ servers. Examples: faqserv://2:5043/17.100@fidonet/ faqserv://2:5054/80.999 However, such an action MUST NOT imply sending any requests to the designated server. Different FAQ servers use different names of the default request; it can be 'FILES', 'LIST', 'INDEX', 'HELP' or any other name. That's why a Uniform Resource Locator MUST NOT expect the URL processor to have any extra knowledge besides the data given in the URL itself. If a request is needed, than the corresponding part of a faqserv URL MUST be present and not empty, containing the request (see details below). If the 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 is empty), or just an object inside the response (if the is not empty). Examples: faqserv://2:5054/83/ELINE/blath/Feainnewedd (an object) faqserv://2:5054/83/TNT ( is empty) faqserv://2:5054/83/TNT_FAQ/ ( is empty) If the part of a faqserv URL is present, then receiving a message (or several messages) via netmail is implied. However, most of the auxiliary technical and decorative elements of netmail (i.e. taglines, tearlines, origin lines, greeting lines, signature lines, etc.) SHOULD be stripped from the response text when the netmail is received and the response is extracted from it. It is useful to remember that the response MAY span several messages, and sections of it SHOULD be stripped of all their wrappings before they are finally combined. If is possible for resources designated by faqserv URLs to appear as elements of complex data structures (e.g. as objects on pages of hypertext). Fidonet browsers SHOULD cache the extracted objects and/or raw netmail response letters to allow immediate rendering of the resources already requested before. 7.3.1. Optional parameter "bot" -+----------------------------- Sometimes the FAQ server station does not respond to the request that is not addressed to a certain name of the service robot. Such a behaviour is especially natural for stations where the same :/.@ address is shared by both human and automatic addressees, or where several bots exist (e.g. a FAQ robot and an areafixing robot). In such cases the "bot" optional parameter is appended to the faqserv URL. The value of the "bot" optional parameter specifies the name of the necessary addressee; it MUST be copied verbatim to the corresponding message field of the netmail request. 7.3.2. Future optional parameters -+------------------------------- Future versions of this document may introduce even more optional parameters for faqserv URLs, encouraging somewhat tighter control how the request is sent (e.g. whether the part of the URL is copied to the subject line of netmail or to the message body). 7.4. "fecho://" scheme -+-------------------- Fidonet file echoes are somewhat similar to the echomail areas in the terms of transport and distribution. However, files are broadcast there instead of messages. File echo is a shared base of files that have common areatag (file echo identifier) and are distributed through Fidonet via hierarchical and/or p2p-alike connections between individual Fidonet systems (nodes and points). The fecho URLs take the form: fecho:///? The character "/" has its literal meaning in the of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (/), playing the role of delimiter between parts of the path. If an contains the character "/" in its literal meaning, the character MUST be encoded. An MAY contain "@domain" suffix (see section 5.2.2.3.1). If the part is empty, the fecho URL designates the file echo as a whole. Examples: fecho://aftnbinkd fecho://XOFCELIST/ If the of a fecho URL is not empty, then its MUST also be non-empty by definition, and it specifies the name of a file that is available as a result of a broadcast though the given file echo. Examples: fecho://aftnmisc/HATCHDIR.RAR fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq fecho://FIDONEWS/FNEWSK19.ZIP/ fecho://aftnbinkd/BNDMAN.ZIP/man/gif/ If an corresponds to a file echo which is not available on the system, then the designated resource is not available. The user MAY be asked whether he wants to subscribe to that echo. An FTP mirror of the file echo MAY also be used, if an Internet connection to such a mirror is available. Future versions of this document MAY introduce some optional parameters for "fecho://" URLs, but Fidonet software MAY safely ignore any unknown parameters in "fecho://" URLs. 7.5. "freq://" scheme -+-------------------- It is possible for Fidonet stations to request files directly from each other; there is even a protocol of distributed file requests, proposed in FSC-0071. The freq URLs take the form: freq:///? The character "/" has its literal meaning in the of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (/), playing the role of delimiter between parts of the path. However, inside the 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 part of a freq URL MUST be present. The standard Fidonet addressing notation, :/.@ (see FSP-1004 for details), is used in address. However, some parts of address (":", "@" and/or ".") MAY be omitted (again, see FSP-1004 for details). The part of a freq URL specifies the Fidonet address of the station that will provide the requested file. If the is empty, the freq URL designates the station itself, as a Fidonet system able to provide files by request. If the of a faqserv URL is not empty, then its 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 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 part of the URL). If is possible for resources designated by freq URLs to appear as elements of complex data structures (e.g. as objects on pages of hypertext). Fidonet browsers SHOULD cache the requested files when they are received, in order to allow immediate rendering of the resources already requested before. textend.section With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... 182. I won't hold any sort of public celebration within my castle walls. --- Something is rotten in the state of Denmark. (Shakespeare, Hamlet, I, IV) * Origin: And the Soviets ÄÄ waist-deep in the snow ÄÄ marched in (2:5063/88) Ä Z2-M-FTSC_PUBLIC (2:244/1120) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FTSC_PUBLIC Ä Msg : #1076 [1079] -738 Uns By : Mithgol the Webmaster 2:5063/88 Son 14 Okt 07 00:44 To : All Subj : [11/11] FidoURL.txt ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * originally in FTSC_Public * also sent to GanjaNet.Local * also sent to Ru.Fido.WWW * also sent to Ru.FTN.Develop * also sent to SU.FidoTech * also sent to Titanic.Best textsection 11 of 11 of file FidoURL.txt textbegin.section 7.5.1. Future optional parameters -+------------------------------- Future versions of this document MAY introduce even more optional parameters for freq URLs, encouraging somewhat tighter control how the file is requested. For example, some Fidonet stations MAY deny or delay file requests that are sent in a certain inappropriate time of the day, or day of the week; so a parameter or two MAY appear to specify the time and the week day when the file request is relatively safe. Programs interpreting freq URLs SHOULD NOT be sure whether it is safe to ignore any of the unknown parameters. Some of future extensions may dramatically change the probability of the success of a file request, especially when such a parameter controls the file request time. If an unknown parameter is encountered in the freq URL, the user SHOULD always be asked whether it can be discarded safely enough. ********************************************************************** EOTD END OF THE DOCUMENT ********************************************************************** textend.all With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff] ... Tell a computer to WIN and you lose. (Bugzilla Quip System) --- Something is rotten in the state of Denmark. (Shakespeare, Hamlet, I, IV) * Origin: And the Soviets ÄÄ waist-deep in the snow ÄÄ marched in (2:5063/88)