FidoURL.txt

**********************************************************************
FGHI                                FIDONET GLOBAL HYPERTEXT INTERFACE
**********************************************************************
Status:             draft
Revision:           0.5pre
Title:              FGHI URL, the set of Uniform Resource Locators
                    for Fidonet objects and services
Author:             Mithgol the Webmaster   (Sergey Sokoloff, 2:50/88)
Special thanks to:  Shannar                  (Boris Kassal, 2:463/587)
                    Trooper            (Alexey Bezugly, 2:5030/1520.9)
                    NoSFeRaTU          (Konstantin Kuzov, 2:5019/40.1)
                    Inity               (Tanya Matveeva,  2:5030/1400)
Revision Date:      8 Apr 2010
-+--------------------------------------------------------------------
Contents:
   1. Status of this document
   2. Introduction
   3. Key words to indicate requirement levels
   4. Changelog of this document
   5. General Fidonet URL syntax
      5.1. The main parts of URLs
         5.1.1. Conformance note
         5.1.2. Delimiter guidelines
      5.2. URL character encoding
         5.2.1. Encoding of original characters
         5.2.2. Encoding of octets
            5.2.2.1. No corresponding graphic 7-bit character
            5.2.2.2. Unsafe characters
            5.2.2.3. Reserved characters
               5.2.2.3.1 Using domain suffixes in areatags
            5.2.2.4. The plus ("+") and the encoding of white spaces
               5.2.2.4.1. Specificity note
               5.2.2.4.2. Internet practice note
            5.2.2.5. URLs that span several lines of text in Fidonet
      5.3. Parsing the scheme-specific part of URL
         5.3.1. Dealing with inappropriate reserved characters
   6. Fidonet URL schemes designating actions
      6.1. "netmail:" scheme
         6.1.1. Optional parameter "to"
         6.1.2. Optional parameter "subject"
         6.1.3. Optional parameter "from"
         6.1.4. Optional parameter "body"
      6.2. "areafix:" scheme
         6.2.1. Optional parameter "uplink"
         6.2.2. Optional parameter "leave"
         6.2.3. Optional parameter "fecho"
         6.2.4. Future optional parameters
         6.2.5. Relative "areafix:" URLs
      6.3. "echomail:" scheme
         6.3.1. Optional parameter "to"
         6.3.2. Optional parameter "subject"
         6.3.3. Optional parameter "from"
         6.3.4. Optional parameter "body"
   7. Fidonet URL schemes designating objects
      7.1. The <object-path> part of URL. Possible forms of the path
         7.1.1. The leading slash and the trailing slash
         7.1.2. Dealing with unknown containers
      7.2. "area://" scheme
         7.2.1. Message filters
            7.2.1.1. Filters of "msgid" type
            7.2.1.2. Filters of "time" type
               7.2.1.2.1. Single moment
                  7.2.1.2.1.1. Empty values
               7.2.1.2.2. Upper limit
                  7.2.1.2.2.1. Empty leftmost values
                  7.2.1.2.2.2. Empty rightmost values
               7.2.1.2.3. Lower limit
                  7.2.1.2.3.1. Empty leftmost values
                  7.2.1.2.3.2. Empty rightmost values
               7.2.1.2.4. Interval of time
                  7.2.1.2.4.1. Empty rightmost values
                  7.2.1.2.4.2. Empty leftmost values
               7.2.1.2.5. Complex filter
               7.2.1.2.6. The type-total set for "time" filters
               7.2.1.2.7. Ordinal day number in the year
               7.2.1.2.8. Using current date and time
               7.2.1.2.9. TrueTime kludge
               7.2.1.2.10. Optional parameter "usetz"
               7.2.1.2.11. Future variants of "time" filters
            7.2.1.3. Filters of "from" type
               7.2.1.3.1. Filters of "twit" type
            7.2.1.4. Filters of "find" type
               7.2.1.4.1. Similar filters:
                          "subj", "findsb", "to", "sender"
            7.2.1.5. Geographically referenced echomail
               7.2.1.5.1. GEO kludge
               7.2.1.5.2. GEOBOX kludge
               7.2.1.5.3. GEOKML kludge
               7.2.1.5.4. Coordinates in nodelists and pointlists
               7.2.1.5.5. ORIGEO kludge
               7.2.1.5.6. Filters of "geomark" type
               7.2.1.5.7. Filters of "geofrom" type
            7.2.1.6. Tagged echomail
               7.2.1.6.1. TAG kludge
               7.2.1.6.2. Filters of "tag" type
            7.2.1.7. Filters of "ttop" type
            7.2.1.8. Future message filters
         7.2.2. Encoded objects within echomail messages
            7.2.2.1. Names of encoded objects
            7.2.2.2. How the designated object is determined
               7.2.2.2.1. Possible applications
         7.2.3. View of the rendered messages
            7.2.3.1. Optional parameter "view"
            7.2.3.2. Single message
            7.2.3.3. List of messages
            7.2.3.4. Tree of replies
            7.2.3.5. Branch of replies
            7.2.3.6. List of trees
            7.2.3.7. Reel of messages
            7.2.3.8. Reel of the tops of the trees
            7.2.3.9. List of the tops of the trees
            7.2.3.10. Expanded tree
            7.2.3.11. Expanded branch
            7.2.3.12. Flat tree
            7.2.3.13. Flat branch
            7.2.3.14. Calendar
            7.2.3.15. Map of messages
            7.2.3.16. Map of senders
            7.2.3.17. Globe of messages
            7.2.3.18. Globe of senders
            7.2.3.19. List of encoded objects
            7.2.3.20. Echolist
         7.2.4. Controlling the visibility of kludges and hidden lines
            7.2.4.1. Optional parameter "kl"
         7.2.5. Optional parameter "full"
         7.2.6. Sorting order of messages
            7.2.6.1. Optional parameter "sort"
            7.2.6.2. Unsorted (message base order)
            7.2.6.3. Chronological sorting
            7.2.6.4. Sorting by relevance
            7.2.6.5. Sorting by subject
            7.2.6.6. Sorting by size
            7.2.6.7. Sorting by addressee's name
            7.2.6.8. Sorting by sender's name
            7.2.6.9. Sorting by sender's address
            7.2.6.10. Sorting by sender's whereabouts
            7.2.6.11. Sorting by areatag
         7.2.7. Optional parameter "leaf"
      7.3. "faqserv://" scheme
         7.3.1. Optional parameter "time"
         7.3.2. Optional parameter "bot"
         7.3.3. Optional parameter "loc"
         7.3.4. Future optional parameters
      7.4. "fecho://" scheme
         7.4.1. Optional parameter "time"
         7.4.2. Future optional parameters
      7.5. "freq://" scheme
         7.5.1. Optional parameter "time"
         7.5.2. Optional parameter "size"
         7.5.3. Optional parameter "ed2k"
         7.5.4. Optional parameter "aich"
         7.5.5. Optional parameter "fecho"
         7.5.6. URL-based extension for WaZOO file requests
         7.5.7. FGHI URLs of file responses (.FUF index)
         7.5.8. Nodelist flags indicating FGHI freq capabilities
         7.5.9. Future optional parameters
   Appendix A. Regular expressions
   Appendix B. Known implementations
      B.1. HellEd
      B.2. FGHI URL gate
      B.3. NoSFeRaTU's GoldED+
   Appendix C. Foreseen future technologies
      C.1. XML echolists
      C.2. FFF (FGHI fidosphere features)
         C.2.1. Social file (SOCFILE kludge)
-+--------------------------------------------------------------------

1. Status of this document
-+------------------------

  This document is a draft of a Fidonet Standards Proposal (FSP).

  This document specifies an optional Fidonet standard
  that can be used both in the Fidonet community and in the Web,
  and requests discussion and suggestions for improvements.

  Implementation of the protocols defined in this document is not
  mandatory, but all implementations of these protocols are expected
  to adhere to this standard.

  Distribution of this document is unlimited, 
  provided that its text is not altered without notice.

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

2. Introduction
-+-------------

  This document specifies several Fidonet schemes of Uniform Resource
  Locators (URL), providing both syntax and semantics of formalized
  information for location and access of resources and services
  via Fidonet.

  It is designed to conform with the specifications of RFC 1738, thus
  hyperlinks specified according to this document could be used both
  in Fidonet (echomail, netmail) and in the traditional HTML hypertext
  environment of the Web and Internet e-mail (where standards of URLs
  are mostly backwards-compatible with RFC 1738).

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

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

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

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

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

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

    This document defines seven new URL schemes:

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

    This document defines six new optional kludges:

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

    This document defines eight new optional nodelist flags:

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

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

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

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
  and "OPTIONAL" in this document are to be interpreted as described
  in FTA-1006 (based on RFC 2119).

4. Changelog of this document
-+---------------------------

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

  In version 0.5pre:                                     [8 Apr 2010]

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

  In version 0.4:                                        [13 Oct 2007]

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

  In version 0.3:                                        [10 Feb 2007]

  *) started this changelog
  *) added subsection 7.2.1.3 (Optional parameter "from")
  *) added subsection 7.2.1.4 (Optional parameter "find")
  *) edited the surrounding subsection 7.2 to reflect the fact that
     now several messages can be identified, not only a single message
  *) added special thanks to NoSFeRaTU
  *) edited subsection 5.2.2.4.2, RFC 1630 is mentioned
  *) edited the list of examples in section 5
  *) added appendix A (Regular expressions)
  *) added subsection 7.2.4 (Controlling the visibility of kludges
     and hidden lines)
  *) edited subsection 5.2.2.2, the word "Origin" in not unsafe now
  *) edited the subsection 7.5.1 to reflect the fact that requests
     may be delayed

5. General Fidonet URL syntax
-+---------------------------

  Just as there are many different types of Fido objects and services,
  there are several URL schemes for describing the location of such
  resources.

  The generic syntax for URLs provides a framework for new schemes
  to be established using protocols other than those defined in this
  document.

  URLs are used to 'locate' resources, by providing an abstract
  identification of the resource location.  Having located a resource,
  a Fidonet system may perform a variety of operations on the resource
  (as might be characterized by such words as 'access', 'subscribe',
  'unsubscribe', 'send', 'request', 'show attributes').

  5.1. The main parts of URLs
  -+-------------------------

    In general, Fidonet URLs are written as follows:

    <scheme>:<scheme-specific-part>

    Any URL contains the name of the scheme being used (<scheme>)
    followed by a colon and then a string (the <scheme-specific-part>)
    whose interpretation depends on the scheme.

    Scheme names consist of a sequence of characters. The lower case
    letters "a"--"z", digits, and the characters plus ("+"), period
    ("."), and hyphen ("-") are allowed. For the sake of resiliency,
    programs interpreting Fidonet URLs SHOULD treat upper case letters
    in scheme names as equivalent to the corresponding lower case
    letters (e.g., allow "AREA" scheme name as well as "area").

    Only the first colon of the URL plays the role of delimiter
    between <scheme> and <scheme-specific-part>. The scheme-specific
    part of any URL MAY contain other colons.

    The colon delimiter between <scheme> and <scheme-specific-part>
    MAY be immediately followed by an optional double slash ("//").
    Fidonet programs interpreting URLs MUST treat the delimiter "://"
    as equivalent to the simple colon before <scheme-specific-part>.

    5.1.1. Conformance note
    -+---------------------

      This subsection is informative.

      The Fidonet URL schemes defined in this document consist of
      lower case letters "a"--"z" only. However, digits, and the
      characters plus ("+"), period ("."), and hyphen ("-") MUST also
      be allowed in scheme names, so that Internet schemes conforming
      with the specifications of RFC 1738 are correctly dealt with.

    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://").

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

  5.2. URL character encoding
  -+-------------------------

    URLs are sequences of characters (i.e., letters, digits, and/or
    special characters). URLs may be represented in a variety of ways:
    e.g., ink on paper, or a sequence of octets in a coded character
    set. The interpretation of URL depends only on the identity of the
    characters used.

    It is useful to distinguish between a "character" (distinguishable
    semantic entity) and an "octet" (an 8-bit byte).

    In most URL schemes, the character sequences in different parts
    of a URL are used to represent sequences of octets used in Fidonet
    services. For example, in the "netmail:" scheme, the Fidonet
    address, netmail subject and addressee name are such sequences of
    octets, represented by parts of the URL. That sequences of octets,
    in turn, represent the original characters (of subject line, or of
    sysop's name, etc.); each original character is represented by one
    or more octets.

    So there are always two mappings, one from URL characters to
    octets, and the second from octets to original characters:

 URL character sequence<->octet sequence<->original character sequence

    5.2.1. Encoding of original characters
    -+------------------------------------

      The following paragraph is informative.

      The sequence of octets defined by a component of the URL
      is subsequently used to represent a sequence of original
      characters. That process could have a very volatile nature.
      Being an international network, Fidonet always needs to deal
      with hundreds of national characters, with dozens of available
      encoding traditions and character sets. There is a number of
      FSC (Fidonet Standard Proposal documents) suggesting several
      kludge-based methods to define which character set is used.
      However, it is not wise to implement any equivalents to kludges
      as a required part of every Fidonet URL; and it could be hard to
      mantain complete lists of all possible character sets inside all
      programs interpreting Fidonet URLs. (Remember, it should be also
      made possible for Fidonet URLs to appear and be well interpreted
      in traditional HTML hypertext environment of the Web, Internet
      e-mail, instant messaging, etc.) That's why only one encoding,
      with large enough character set, has to be chosen.

      The following paragraphs of this subsection are normative.

      The sequence of octets used in Fidonet URLs MUST always contain
      UTF-8 encoded representation of original characters.

      ISO/IEC 10646-1 defines a multi-octet character set called the
      Universal Character Set (UCS), which encompasses most of the
      world's writing systems. And UTF-8, one of a few so-called UCS
      transformation formats (UTF), preserves the 7-bit ASCII range,
      thus providing some compatibility with file systems, parsers and
      other software elements that rely on 7-bit ASCII values but are
      transparent to other values.

      UTF-8 is defined in RFC 2279. Its description can also be found
      in Unicode Technical Report #4 and in the Unicode Standard,
      version 2.0.

    5.2.2. Encoding of octets
    -+-----------------------

      The character sequences in different parts of a URL are used
      to represent sequences of octets.

      It is possible to represent an octet by the chararacter
      which has that octet as its code within the pure 7-bit ASCII
      character set. However, there are some exceptions (see below).

      Alternatively, octets MAY be encoded by a character triplet
      consisting of the character "%" followed by the two hexadecimal
      digits (from "0123456789ABCDEF") which form the hexadecimal
      value of the octet. (The characters "abcdef" MAY also be used in
      hexadecimal encodings.)
      
      Hexadecimal encoding of any octet MAY be used even when it is
      not REQUIRED or RECOMMENDED. However, it is RECOMMENDED to avoid
      unnecessary hexadecimal encoding, thus keeping URLs reasonably
      short.

      It is either REQIRED or RECOMMENDED to use the hexadecimal
      encoding of octets if they have no corresponding graphic
      character within the 7-bit ASCII character set, or if the use
      of the corresponding character is unsafe, or if the
      corresponding character is reserved for some other
      interpretation within the particular URL scheme. These
      requirements and recommendations are detailed below.

      5.2.2.1. No corresponding graphic 7-bit character
      -+-----------------------------------------------

        URLs are written only with the graphic printable characters
        of the 7-bit ASCII coded character set.

        The octets 80-FF hexadecimal do not belong to 7-bit ASCII,
        and the octets 00-1F and 7F hexadecimal represent control
        characters; these octets MUST be encoded.

      5.2.2.2. Unsafe characters
      -+------------------------

        Characters can be unsafe for a number of reasons.

        The space character is unsafe because significant spaces may
        disappear and insignificant spaces may be introduced when URLs
        are transcribed or typeset or subjected to the treatment of
        word-processing programs. The octet 20 hexadecimal MUST always
        be encoded.

        The characters "<" and ">" are unsafe because they are used
        as the delimiters around tags in HTML hypertext and XML data.
        The octets 3C and 3E hexadecimal MUST always be encoded.

        The quote mark (""") is used to delimit URLs in some systems,
        including valid XHTML and XML. The octet 22 hexadecimal
        MUST always be encoded.

        The character "#" is unsafe because it is used in World Wide
        Web and in other systems to delimit a URL from a fragment or
        anchor identifier that might follow it.
        The octet 23 hexadecimal MUST always be encoded.

        The character "%" is unsafe because it is used for encodings
        of other characters. The octet 25 hexadecimal MUST always be
        encoded.

        The character sequence of triple minus ("-" repeated thrice)
        has a special meaning in Fidonet and can accidentally start
        a tearline in some cases (e.g. when a line is wrapped).
        At least one of the three corresponding octets
        (2D 2D 2D hexadecimal) MUST be encoded if they follow
        each other in a sequence.

        Other characters were declared unsafe in RFC 1738 because some
        gateways and other transport agents were known to sometimes
        modify such characters. These characters are "{", "}", "|",
        "\", "^", "~", "[", "]", and "`". The corresponding octets
        (7B 7D 7C 5C 5E 7E 5B 5D 60 hexadecimal) MUST always be
        encoded for the sake of Internet compatibility.

        All unsafe characters MUST always be encoded within a URL.
        For example, the character "#" MUST be encoded within URLs
        even in software programs that do not normally deal with
        fragment or anchor identifiers, so that if the URL is copied
        into another program that does use them, it will not be
        necessary to change the URL encoding.

      5.2.2.3. Reserved characters
      -+--------------------------

        Many URL schemes reserve certain characters for a special
        meaning: appearance of that characters in the scheme-specific
        part of the URL (in <scheme-specific-part> after scheme name)
        has a designated semantics.

        Usually a URL has the same interpretation when an octet is
        represented by a character and when it is encoded. However,
        this is not true for reserved characters: encoding a character
        that is reserved for a particular scheme may cause harm to
        the meaning of a URL, if the character is used according
        to its designated semantics. And vice versa.

        The character "?" is used as the delimiter between required
        and optional parts of the URL. The delimiter itself MUST NOT
        be encoded. If the character "?" appears in any other part of
        a URL, it MUST be encoded, so it won't be confused with the
        delimiter.

        The character "=" is used as the delimiter between parameter
        names and parameter values. The delimiters themselves MUST NOT
        be encoded. If the character "=" appears in any other part
        of a URL, it MUST be encoded, so it won't be confused with
        any of the delimiters.

        The character "&" is used as the delimiter between
        "parameter=value" pairs. The delimiters themselves MUST NOT
        be encoded. If the character "&" appears in any other part
        of a URL, it MUST be encoded, so it won't be confused with
        any of the delimiters.

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

        The character "/" is scheme-specific:

        *) In some schemes ("netmail:", for example) the character "/"
           has its own (literal) meaning, as it is widely used
           in standard Fidonet addressing notation
           <zone>:<net>/<node>.<point> (see FSP-1004 for details).

        *) In some other schemes the character "/" is reserved
           to be used in the file path
           (<directory>/<directory>/...<directory>/<filename>),
           and its corresponding octet (2F hexadecimal)
           MUST be encoded if it does not delimit parts of the path.

        See the scheme-specific details below (in scheme sections).

        5.2.2.3.1 Using domain suffixes in areatags
        -+-----------------------------------------

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

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

          The same rule applies to areatags of file echoes.

          Examples:

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

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

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

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

          The character "@" is a reserved character. When it is used
          as the delimiter between an areatag and its FTN domain
          name, the character "@" MUST NOT be encoded. 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)

        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 own line break
        marker; this also means that the ambiguity of "%%%" MAY always
        be avoided as described above.

  5.3. Parsing the scheme-specific part of URL
  -+------------------------------------------

    As it was stated above, Fidonet URLs are written as follows:

    <scheme><scheme-delimiter><scheme-specific-part>

    where <scheme-delimiter> is either ":" or "://".

    The <scheme-specific-part> uses the reserved character "?"
    as the delimiter between required and optional part or URL:

    <scheme><scheme-delimiter><required-part>?<optional-part>

    The required part is REQUIRED. The optional part MAY be empty;
    if the optional part is empty, the "?" character before it MAY
    be omitted. If the optional part is empty and the "?" character
    is present, then the "?" character MUST be ignored.

    If the optional part is not empty, it consists of one or more
    "parameter=value" settings, delimited by the reserved "&"
    character as follows:

    <setting1>&<setting2>&<setting3>&<setting4>& ... &<settingN>

    However, the optional part MAY have the "&" character on URL's end
    as follows:

    <setting1>&<setting2>&<setting3>&<setting4>& ... &<settingN>&

    (in this case the last "&" character MUST be ignored).

    Each of these settings is expected to appear in "parameter=value"
    form:

    <parameter's name>=<parameter's value>

    If the value part is omitted, then the corresponding parameter
    is assigned an empty value. In this case the "=" character MAY
    also be omitted. Example of such an optional part of URL:

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

    In this example, parameters "path" and "subscribe" become empty,
    the parameter "subject" becomes equal to "Test" value, and the
    parameter "to" becomes equal to "Test Robot" value (because "+"
    represents the white space, see the corresponding section above).

    Parameters specified in the optional part of URL are also optional
    by nature. If a certain parameter does not appear in the given URL
    at all, it takes a default value; and if the default value for
    a parameter is not given in this standard, then it's defined
    either by user settings or by design of a Fidonet browser.

    The "parameter=value" pairs MAY have an arbitrary order
    of appearance in an optional part of URL.

    For example, this optional part of URL:

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

    is equivalent to the previous example.

    5.3.1. Dealing with inappropriate reserved characters
    -+---------------------------------------------------

      The reserved character "?" MUST be used only once in a URL; if
      there are many "?" in some URL, then the first appearance of "?"
      SHOULD be treated as the delimiter between required and optional
      parts of that URL, and the remaining "?" MAY be treated as if
      they were properly encoded ("%3F" character triplets), or even
      ignored.

      The reserved character "=" MUST be used only once in a parameter
      setting; if there are many "=" characters in some setting, then
      the first appearance of "=" SHOULD be treated as the delimiter
      between that parameter's name and the parameter's value; and
      the remaining "=" characters, encountered before the next "&"
      (or before URL's ending, if it's the rightmost "parameter=value"
      pair) MAY be treated as if they were properly encoded octets of
      that parameter's value ("%3D" triplets), or even ignored.

      "The first appearance" means the leftmost one, because
      it is natural to parse the scheme-specific part of URL
      in left-to-right order.

      The programs interpreting Fidonet URL MAY also stop the whole
      interpreting and ignore the rest of URL after the position where
      an inappropriate reserved character is first encountered. This
      behaviour is especially RECOMMENDED for the programs trying to
      isolate URLs from some plain text, where the white spaces and/or
      other delimiters before and after URLs tend to be sometimes
      omitted by chance.

6. Fidonet URL schemes designating actions
-+----------------------------------------

  The URL schemes enumerated below designate resources
  that are most often used in typical actions
  involving netmail or echomail composed and sent.

  According to the above section of delimiter guidelines,
  the ":" character (and not the "://" character triplet)
  SHOULD be used as the delimiter after <scheme> part of such URLs.

  6.1. "netmail:" scheme
  -+--------------------

    The "netmail:" scheme is used to designate the Fidonet netmail
    address of an individual or service. It uses standard Fidonet
    addressing notation, <zone>:<net>/<node>.<point>@<domain>
    (see FSP-1004 for details).

    The character "/" has its literal meaning for this scheme.

    The netmail URLs take the form:

    netmail:<zone>:<net>/<node>.<point>@<domain>?<optional-part>

    However, some parts of address ("<zone>:", "@<domain>"
    and/or ".<point>") MAY be omitted (see FSP-1004 for details).

    Examples:

       netmail:2:5030/1520.9                           (point address)
       netmail:2:5063/88                                (node address)
       netmail:182:5043/1@forestnet     (node address outside of Fido)

    When a "netmail:" hyperlink is used (clicked, followed), a netmail
    composer software MAY be launched. With this possibility in mind,
    several optional parameters are designed for the "netmail:"
    URL scheme.

    6.1.1. Optional parameter "to"
    -+----------------------------

      The "to" optional parameter is used to designate the name of
      netmail addressee. Its default value MAY be "Sysop" or "SysOp".
      The default value MAY also be determined by some user setting
      of the netmail composer used to process the "netmail:" URL.

      Examples:

         netmail:2:5063/88?to=Mithgol+the+Webmaster
         netmail:2:5030/1520.9?to=Trooper
         netmail:2:50/13?to=Alex%20Kocharin

    6.1.2. Optional parameter "subject"
    -+---------------------------------

      The "subject" optional parameter is used to designate
      the subject line of the netmail message composed. Its default
      value is empty; the default value MAY also be determined by
      some user setting of the netmail composer used to process
      the "netmail:" URL.

      Examples:

         netmail:2:5063/88?subject=Is+the+hypertext+Fidonet+ready%3F
         netmail:2:5030/830.17?subject=Yet+another+GoldEd%2b+feature
         netmail:2:5030/84?to=R50EC&subject=%D0%AD%D1%85%D0%B8

    6.1.3 Optional parameter "from"
    -+------------------------------

      The "from" optional parameter is used to designate the name of
      the netmail letter's author. Its default value is usually
      defined within the netmail composer settings.

      Examples:

      netmail:2:5030/84?to=R50EC&from=Moderator&subject=New+echo+rules
      netmail:2:5024/1024?from=Moderator&subject=%5B%21%5D+read+only

    6.1.4. Optional parameter "body"
    -+------------------------------

      The "body" optional parameter is used to designate the body part
      of the netmail message composed. (Its default value is empty.)
      The netmail composer MAY wrap the value of "body" parameter in
      elements of some user-defined message template (user-defined
      signature, greeting, etc.)

      Examples:

         netmail:2:5063/88?subject=About+FGHI&body=Fidonet+2.0+draft
         netmail:2:50/0?subject=Complaint&body=A+sysop+is+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:<areatag>?<optional-part>

    When "areafix:" hyperlink is used (clicked, followed), it SHOULD
    launch a netmail composer (or subscription manager) software that
    automatically composes the proper areafixing letter (addressed
    to an uplink node and ordering subscription to the given echomail
    area). However, it is RECOMMENDED that the software asks its user
    to confirm the ready subscription order or cancel it
    before that letter is sent.

    Examples:

       ...if you're a developer, subscribe via areafix:SU.FidoTech
       and enjoy there an endless stream of FAQs...

       ...join today's Fidonet life discussions, use the hyperlink
       leading to areafix:Ru.Fidonet.Today

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

    Examples:

       areafix:Ru.FTN.Develop+Ru.FTN.WinSoft
       areafix:Ru.Computer.Humor%20Ru.Hutor.Filtered
       areafix:Titanic.Best+Titanic.Forward%20Titanic.PVT

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

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

    6.2.1. Optional parameter "uplink"
    -+--------------------------------

      Fidonet software usually has its own means to determine which
      uplink has the requested echomail area and would receive the
      areafixing netmail letter. However, if the system has several
      uplink nodes able to distribute the given echo, the "uplink"
      optional parameter MAY be used to recommend the preferred uplink
      node (provided that the author of the hyperlink has some reasons
      to recommend one uplink above all others).

      The "uplink" parameter takes a value that uses standard Fidonet
      addressing notation, <zone>:<net>/<node>.<point>@<domain>

      However, some parts of address ("<zone>:", "@<domain>"
      and/or ".<point>") MAY be omitted (see FSP-1004 for details).
      The point number is often omitted in the "uplink" parameter
      values, because Fidonet points almost never become uplinks.

      Examples:

         ...get the echo about embedded systems directly from its
         moderator, use areafix:Ru.Embedded?uplink=2:5029/32

         ...those Titanic echoes never were on the backbone, use
         areafix:Titanic.PVT?uplink=2:5020/830 and subscribe to one
         from the primary hub...

      The "uplink" parameter has no default value; the default
      behaviour of the subscription management software has to be
      determined by the network topology of uplink-downlink relations.
      For example, if an areatag contains "@domain" suffix (see
      subsection 5.2.2.3.1), then the subscription manager SHOULD
      choose an uplink that belongs to the given FTN domain, or
      at least has some echomail areas from that domain.

      Generally the software has nothing to do if an areafix URL
      designates an already subscribed echomail area. However, if
      the "uplink" optional parameter is present, the software MAY
      choose to cancel echomail subscription order formerly sent to
      the current uplink for the given echomail area, and then arrange
      for supply of the same echomail area from the preferred uplink
      provided by the value of the "uplink" parameter. (The user
      SHOULD be asked first whether such an action is appropriate.)

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

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

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

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

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

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

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

      Examples:

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

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

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

      Fidonet file echoes are somewhat similar to the echomail areas
      in the terms of transport and distribution. However, files are
      broadcast there instead of messages. File echo is a shared base
      of files that have common areatag (file echo identifier) and are
      distributed through Fidonet via hierarchical and/or p2p-alike
      connections between individual Fidonet systems (nodes and points).

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

      Examples:

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

    6.2.4. Future optional parameters
    -+-------------------------------

      Future versions of this document may introduce even more
      optional parameters for the areafix URLs, encouraging somewhat
      tighter control over rescan parameters, packer/unpacker settings
      and formats, etc.

      Programs interpreting areafix URLs SHOULD NOT be sure whether
      it is safe to ignore any of the unknown parameters. Some of
      future extensions may dramatically change the URL's meaning,
      as "leave" is already able to change it to the opposite.

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

    6.2.5. Relative "areafix:" URLs
    -+-----------------------------

      If an areafix URL is published in the same echomail area that is
      involved in the designated action, then the <echomail-area-name>
      MAY be omitted.

      Examples:

         ...if you don't like this area, areafix:?leave it!

         ...if you feel that some echomail messages is missing, then
         your current uplink is not reliable. You'd better subscribe
         using areafix:?uplink=2:5063/88

      If an areafix URL is published in the echomail area that has the
      same name as the file echo involved in the designated action,
      then the name MAY also be omitted. For example, in "Evil.MP3"
      echomail area, "areafix:?fecho" means subscribing to "Evil.MP3"
      file echo.

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

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

  6.3. "echomail:" scheme
  -+---------------------

    Echomail is an important and powerful force in Fidonet. Echomail
    is, by definition, a broadcast medium. See echomail specifications
    in FTS-0004.

    An echomail area is a shared base of messages that have common
    areatag (area identifier) and are distributed through Fidonet
    via hierarchical and/or p2p-alike connections between individual
    Fidonet systems (nodes and points).

    The "echomail:" scheme is used to designate a Fidonet echomail
    area as a location where echomail can be sent to.

    The character "/" has its literal meaning for this scheme.

    The echomail URLs take the form:

    echomail:<areatag>?<optional-part>

    Examples:

       echomail:Ru.FTN.Develop
       echomail:Ru.FTN.WinSoft
       echomail:FTSC_Public

    When an "echomail:" hyperlink is used (clicked, followed),
    an echomail message composer SHOULD be launched.

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

    Examples:

       echomail:Ru.FTN.Develop+Ru.FTN.WinSoft
       echomail:Ru.Computer.Humor%20Ru.Hutor.Filtered
       echomail:Titanic.Best+Titanic.Forward%20Titanic.PVT

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

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

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

      The "to" optional parameter is used to designate the name of
      echomail addressee. Its default value 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 "from"
    -+------------------------------

      The "from" optional parameter is used to designate the name of
      the echomail letter's author. Its default value is usually
      defined within the echomail composer settings.

      Examples:

         echomail:Ru.Moderator?to=R50EC&from=Moderator+of+XXX.chat
         echomail:Ru.Fidonet.Yo?from=Moderator&subject=*+*+*+Rules

    6.3.4. Optional parameter "body"
    -+------------------------------

      The "body" optional parameter is used to designate the body part
      of the echomail message composed. (Its default value is empty.)
      The echomail composer MAY wrap the value of "body" parameter in
      elements of some user-defined message template (user-defined
      signature, greeting, etc.)

      Examples:

         echomail:Ru.FTN.Develop?subject=FGHI&body=Fidonet+2.0+draft
         echomail:400.Link?subject=Interface&body=A+better+option%3F
         echomail:GSS.ParToss?body=Will+it+toss+JAM%3F&subject=Hopes

7. Fidonet URL schemes designating objects
-+----------------------------------------

  The URL schemes enumerated below designate named objects
  that can be accessed, read, browsed, etc.

  According to the above section of delimiter guidelines,
  the "://" character triplet (and not the ":" character)
  SHOULD be used as the delimiter after <scheme> part of such URLs.

  7.1. The <object-path> part of URL. Possible forms of the path
  -+------------------------------------------------------------

    Sometimes Fidonet is regarded as a text-only network. At least,
    Fidonet is notable for its very few means of transferring binary
    data. File echoes do not enjoy an audience comparable to that
    of traditional echo areas; file requests and attaches are almost
    never routed between nodes. In that somewhat harsh circumstances,
    however, several means of encoding and embedding the binary data
    inside text messages exist. Files (and sometimes whole directories
    of files) are packed to economize traffic; some of the resulting
    archives are encoded in text lines that are sent via text-only
    means of communication -- in echomail, in netmail.

    That's why all the following Fidonet URL schemes must have some
    common method to designate, if necessary, an object inside packed
    (archive) files and/or embedded in some text. The <required-part>
    of their URL always ends with "/<object-path>", and so URLs are
    written as follows:

    <scheme>://<basic-required-part>/<object-path>?<optional-part>

    The character "/" always has its reserved meaning in <object-path>
    part of URL; this character plays the role of delimiter between
    parts of the path.

    The <object-path> part of URL takes one of the following forms:

    <object-name>

       If <object-path> contains just a name of some object, the URL
       designates that object. The object itself is embedded or is
       contained inside the resource specified by the rest of URL:

            <scheme>://<basic-required-part>?<optional-part>

    <object-name>/

        The named object itself is a container (e.g. packed archive).
        The URL designates the root directory of that container.

     <object-name>/<needed-object>

        The <object-name> is a container (e.g. a packed archive),
        and its root directory contains <needed-object>; the URL
        designates that <needed-object>. If <needed-object>
        is a directory (i.e. not a file), the <object-path>
        is equivalent to its following form,
        <object-name>/<needed-object>/

     <object-name>/<needed-object>/

        The <needed-object> inside <object-name> is either a container
        itself (e.g. a packed archive file) or a subdirectory inside
        <object-name> container. The URL designates the contents of
        <needed-object> container or directory. (If <needed-object>
        is a container with subdirectories, the URL designate the
        contents of its root directory.)

     <object-name>/<elem1>/<elem2>/.../<elemN>/<needed-object>
     or
     <object-name>/<elem1>/<elem2>/.../<elemN>/<needed-object>/

        The <object-name> contains a hierarchy as deep as N elements,
        they're either subdirectories or container objects (packed
        archive files, for example). It is necessary to enter those
        containers and browse into directories, one after another,
        in the given order. The innermost element contains the object
        <needed-object>. The URL designates either the object itself
        (if trailing slash is missing and <needed-object> is not
        a subdirectory) or its contents (if <needed-object> is
        a subdirectory, that directory's contents is designated;
        otherwise, <needed-object>/ means the root directory of
        <needed-object>).

    7.1.1. The leading slash and the trailing slash
    -+---------------------------------------------

      The leading slash of <object-path> is a mere delimiter between
      <basic-required-part> and <object-path>. If the <object-path>
      part of a URL is empty, its leading slash MUST be ignored by the
      program interpreting the URL. If the <object-path> part of a URL
      is empty, its leading slash MAY be omitted by the author of that
      URL, thus the following URLs are equivalent:

         <scheme>://<basic-required-part>/?<optional-part>

         <scheme>://<basic-required-part>?<optional-part>

      However, the trailing slash of <object-path> has its own value,
      makes some real difference. For example, "example.zip" means
      the archive itself (a file that may be saved or sent, etc.),
      and "example.zip/" means the root directory of that archive
      (a container that may be browsed, updated, etc.)

      The trailing slash of <object-path> MUST NOT be ignored.

    7.1.2. Dealing with unknown containers
    -+------------------------------------

      Sometimes an <object-path> designates an object inside
      such a container that certain Fidonet browsers are not able
      to open by themselves. This MAY happen when the archive format
      is unknown (or is known, but is newer than the supported one).

      If the object is requested as a separate entity (for example,
      its URL is entered in the address line of a Fidonet browser,
      or the user follows a hyperlink specifying that URL),
      the browser MAY inform the user about the unknown container
      encountered, and suggest saving that container for possible
      manual analysis (after all, the user may have unpacker tools
      in his avail that are not yet integrated into a Fidonet browser,
      and may be willing to try them).

      If the requested object is not a separate entity (for example,
      if it is just one of images on a hypertext page), if many such
      objects are requested at the same time and for the same purpose,
      then it would not be wise to flood the user with information
      about each of such obstacles concurrently encountered, and so
      the browser SHOULD follow its standard procedures prescribed for
      the state of error (display a "broken image" icon, or use
      an alternate object or an alternate text where it is provided).

  7.2. "area://" scheme
  -+-------------------
  
    Echomail is an important and powerful force in Fidonet. Echomail
    is, by definition, a broadcast medium. See echomail specifications
    in FTS-0004.

    An echomail area is a shared base of messages that have common
    areatag (area identifier) and are distributed through Fidonet
    via hierarchical and/or p2p-alike connections between individual
    Fidonet systems (nodes and points).

    Due to the immanent modularity of Fidonet software packages,
    echomail composer and echomail browser can be different programs
    (for example, the latter does not require read/write access to the
    area message base and is able to work through a read-only gate).
    The "echomail:" scheme (defined above) is designed to designate
    an action of a Fidonet echomail composer; the "area://" scheme,
    defined is this section, designates a resource that is located
    in an area message base. These schemes can be handled by different
    software modules, even if they were manufactured independently.

    The area URLs take the form:

    area://<areatag>/<object-path>?<optional-part>

    The character "/" has its literal meaning in the <optional-part>
    of URLs of this scheme. The character "/" has its reserved meaning
    in the required part of URL (<areatag>/<object-path>), playing
    the role of delimiter between parts of the path. If an <areatag>
    contains the character "/" in its literal meaning, the character
    MUST be encoded.

    If <areatag> is empty, the <object-path> MUST also be empty;
    such URL leads to the list of the available echomail areas,
    also known as the arealist.

    Examples:

       area://
       area:///
       area://?

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

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

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

    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 <object-path> is empty and <optional-part> does not contain
    message filters, then the area URL designates an area as a whole.

    Examples:

       area://Ru.FTN.Develop
       area://Ru.FTN.Winsoft/
       area://FTSC_Public?
       area://Ru.Fidonet.Today/?

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

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

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

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

      If at least one of the message filters is present in the
      <optional-part> of an area URL, then

         area://<areatag>?<optional-part>

      no longer designates the whole message base of the given area,
      but only a subset of its messages; the subset is defined
      by the given value of the message filter(s).

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

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

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

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

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

         <type of the filter>=<value>

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

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

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

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

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

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

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

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

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

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

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

        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 <optional-part>, then
        the type-total set for "msgid" type is formed as the union of
        their filtered sets.

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

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

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

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

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

          <Year>/<Month>/<Day>T<Hour>:<Minute>:<Second>

          Example:

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

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

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

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

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

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

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

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

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

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

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

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

            Example:

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

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

            Example:

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

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

            Examples:

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

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

            Examples:

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

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

            Examples:

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

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

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

          -<Year>/<Month>/<Day>T<Hour>:<Minute>:<Second>

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

          Example:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Example:

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

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

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

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

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

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

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

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

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

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

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

            Example:

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

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

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

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

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

          <Year>/<Month>/<Day>T<Hour>:<Minute>:<Second>-

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

          Example:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Example:

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

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

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

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

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

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

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

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

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

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

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

            Example:

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

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

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

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

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

          <LowerLimit>-<UpperLimit>

          In details it looks like this:

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

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

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

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

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

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

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

            Example:

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

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

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

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

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

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

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

            Example:

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

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

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

            For example, the following URL:

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

            is equivalent to:

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

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

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

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

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

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

          Example:

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

          is equivalent to:

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

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

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

          Example:

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

          is equivalent to:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          Example:

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

          is equivalent to:

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

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

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

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

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

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

          is equivalent to:

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

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

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

          Example:

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

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

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

          Kludges (also known as klugde lines or control paragraphs)
          are special lines embedded in the text body of a Fidonet
          message. Sometimes kludges are used to support some new
          addressing and other control information, sometimes they
          contain pieces of auxiliary information about the message's
          author (location, ICQ UIN, Jabber ID, real name, current
          music, mood, etc.) See technical details in FTS-4000.

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

          <SOH>TrueTime: <Year>/<Month>/<Day>T<Hour>/<Minute>/<Second>

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

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

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

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

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

        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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          For example, the following set of GoldEd+ directives:

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

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

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

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

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

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

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

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

        Examples of regular expressions:

           encoded:  ...&find=/\bFido(net)%3f\b/i
           regex:    /\bFido(net)?\b/i
           matches:  Fido
           matches:  FIDOnet
           matches:  FidoNet
           does not match:  Fidonet-alike
           does not match:  Fidobrowser
           does not match:  fidoshnik
           does not match:  triffidos

           encoded:  ...&find=/(P(2P)%7b1,4%7d%7cfile\s%2bexchange)/
           regex:    /(P(2P){1,4}|file\s+exchange)/
           matches:  P2P
           matches:  P2P2P2P
           matches:  P2P2P2P2P
           matches:  file exchange
           matches:  file      exchange
           does not match:  P2P2P2P2PP2P2P2P2P
           does not match:  P2P2P2P2P2P
           does not match:  fileexchange
           does not match:  file_exchange
           does not match:  p2p
           does not match:  FiLe ExChanGe

        Fidonet messages are able to contain kludges (see technical
        details in FTS-4000). Consequently, it is possible for an URL
        to designate a set of messages tagged by a certain kludge type
        or certain kludge values. The corresponding regular expression
        starts with ^\x1 or ^\01 symbols, which mean the begginning of
        line immediately followed by the SOH (Ctrl+A, ASCII 1) symbol.
        The expression always uses the multi-line mode of matching
        (see appendix A), thus the "^" construct matches at the
        beginning of each kludge.

        Examples of regular expressions:

           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.

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

        If there's a need for some URL to contain several regular
        expressions and to designate Fidonet messages that match
        at least one of those regular expressions, then the URL's
        author MUST unite those expressions as alternative branches
        of one single pattern (expression1|expression2|...) as shown
        in the above category-related example.

        If there's a need for some URL to contain several regular
        expressions and to designate Fidonet messages that match
        every of those regular expressions, then the URL's author MUST
        use several "find" parameters in that URL.

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

        Examples of regular expressions:

        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.

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

        Examples of plain text searches:

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

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

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

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

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

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

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

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

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

             area://Ru.Blog.Mithgol/?findsb=%22FGHI+URL%22

          MAY be redirected to

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

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

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

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

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

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

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

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

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

          Kludges (also known as klugde lines or control paragraphs)
          are special lines embedded in the text body of a Fidonet
          message. Sometimes kludges are used to support some new
          addressing and other control information, sometimes they
          contain pieces of auxiliary information about the message's
          author (location, ICQ UIN, Jabber ID, real name, current
          music, mood, etc.) See technical details in FTS-4000.

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

          <SOH>GEO: <Latitude>;<Longitude>

          Here <SOH> is a single SOH character (Ctrl+A, ASCII 1).

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

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

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

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

             decimal = degrees + minutes/60 + seconds/3600

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

          Example:

             ^aGEO: 44.57;38.05

             Here "^a" is a single SOH character (Ctrl+A, ASCII 1).

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

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

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

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

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

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

             <SOH>GEOBOX: <West>,<South>,<East>,<North>

          Here <SOH> is a single SOH character (Ctrl+A, ASCII 1).

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

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

          Example:

             ^aGEOBOX: 37.98,44.54,38.13,44.61

             Here "^a" is a single SOH character (Ctrl+A, ASCII 1).

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

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

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

          Example:

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

             Here "^a" is a single SOH character (Ctrl+A, ASCII 1).

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

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

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

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

          Example:

             LONE:38.05

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

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

          Example:

             LATN:44.57

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

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

          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,LATN:44.57,LONE:38.05

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

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

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

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

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

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

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

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

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

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

          <SOH>ORIGEO: <Latitude>;<Longitude>

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

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

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

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

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

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

            Example:

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

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

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

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

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

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

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

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

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

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

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

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

          Kludges (also known as klugde lines or control paragraphs)
          are special lines embedded in the text body of a Fidonet
          message. Sometimes kludges are used to support some new
          addressing and other control information, sometimes they
          contain pieces of auxiliary information about the message's
          author (location, ICQ UIN, Jabber ID, real name, current
          music, mood, etc.) See technical details in FTS-4000.

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

          <SOH>TAG: <list of tags>

          Here <SOH> is a single SOH character (Ctrl+A, ASCII 1).

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

          Example:

             <SOH>TAG: SimpleX|new version|announcement

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

          An echomail message MAY contain several TAG kludges.

          Example:

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

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

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

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

          Example:

             <SOH>TAG: &#1074;&#1123;&#1089;&#1090;&#1100;

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

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

          Example:

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

          The tag used in this example:

             more sort&more examples as "sort|more"

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

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

            Examples:

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

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

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

            Examples:

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

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

               URL:         ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C
               matches TAG: &#1074;&#1123;&#1089;&#1090;&#1100;

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

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

            Example:

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

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

               <SOH>TAG: SimpleX
               <SOH>TAG: announcement
               <SOH>TAG: changelog
               <SOH>TAG: software

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

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

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

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

        1) The message does not contain a REPLY kludge.

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        However, it is safe to discard unknown optional parameters of
        area URLs, though programs interpreting Fidonet URLs SHOULD
        probably warn their users if an unknown parameter is discarded
        and when such a warning is appropriate.

    7.2.2. Encoded objects within echomail messages
    -+---------------------------------------------

      It is possible for a Fidonet echomail message to contain one
      or more binary objects, encoded to appear in text-alike lines
      of characters. Possible methods of encoding include UUE, MIME
      (RFC 2045-2049), "data:" (RFC 2397), etc.

      An echomail message MAY contain several objects, which MAY be
      encoded in different manner. On the other hand, an encoded
      object MAY span several Fidonet messages: for example, each
      of those Fidonet messages MAY bear a section or two of UUE,
      and the whole bunch of sections is needed to decode a file.

      7.2.2.1. Names of encoded objects
      -+-------------------------------

        This subsection is informative.

        Most of encoded objects within echomail messages are named.

        The name of a UUE-encoded object usually appears within
        "begin" and/or "section" line of UUE codes.

        The name of a MIME-encoded object usually appears within
        either the "Content-type" header (in the "name" section of the
        header) or in the "Content-disposition" header (in the
        "filename" section of the header).

        RFC 2397 "data:" does not specify an object name; however, the
        hypertext object populated by that data MAY be named itself,
        via "id" or "name" attribute of its tag.

      7.2.2.2. How the designated object is determined
      -+----------------------------------------------

        If the <object-path> of an area URL is not empty, then the URL
        designates either an encoded object as a whole or some inner
        part of such an object. Abstracting from this inner details,
        the whole object is called "the designated object" in this
        subsection.

        If the <object-path> of an area URL is not empty, then its
        <object-name> MUST also be non-empty by definition, and it
        specifies the name of the designated object.

        However, the echomail message base (of the areas given in
        <areatag> section of the URL) MAY contain more than one object
        of the same name. It is therefore important to define what
        object is considered "the latest".

        Among those messages that contain objects of the same name
        (or just parts of those objects, e.g. UUE sections), there is
        the latest message. If that latest message contains only one
        of those objects (partly or as a whole), then that object is
        the latest one. If that latest message contains parts and/or
        whole encoded images of more than one object of the same name,
        then the object whose complete encoding or just the last
        section of encoding (last among its sections contained in this
        latest message) appears nearest to the bottom of that message
        (farthest from top) is the latest object.

        How "the latest message" itself is defined is beyond the scope
        of this document. It MAY be the latest received, it MAY be
        the one with the most up-to-date creation date, etc.

        The designated object is always determined as the latest one
        among those of the name given in <object-name>.

        Fidonet browser software MUST ignore objects which have such
        encodings that browser can not decode; the designated object
        MUST always be the latest of only those ones of the given name
        that are able to be decoded from the echomail message base.

        If one or several message filters are present in the optional
        part of the URL, then the designated object is the latest one
        among only those decodable objects of the same name whose
        complete encoding (or just a section of encoding) appears in
        one of the messages that belong to the final subset of the
        whole message base; what messages appear in that final message
        set is defined by the applied filter(s).

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

        7.2.2.2.1. Possible applications
        -+------------------------------

          This subsection is informative.

          As the <object-name> always designates the latest object of
          the same name, it is possible for "area://" URL to designate
          an object that is updated by means of Fidonet echomail area
          transport. Such objects MAY update daily (as in a weather
          forecast), weekly (as in a nodelist statistical report),
          etc. That's how Fidonet may easily serve dynamic up-to-date
          content. And if some URL is intended to point to an older
          static version instead of the up-to-date dynamic one, then
          a message filter (if it matches just a single message or
          a narrow enough subset of messages) is always able to ensure
          that. For example, "msgid" and/or "time" filter.

          If several nodes have write access to the same echo area,
          and it is not possible to rely just on the latest object of
          the same name, then "from" filter can be used to ensure
          that the trusted origin is chosen.

          As any Fidonet browser software MUST ignore objects which
          have such encodings that browser can not decode, it is made
          possible to include several alternative versions of the same
          object (encoded differently), even in the same one echomail
          letter, provided that the names of published object versions
          are all the same. The browser will happily pick the encoding
          it understands. For example, someone may post both UUE (for
          GoldEd+) and RFC 2397 (for Gecko) versions of the same icon.

          Examples:

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

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

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

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

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

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

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

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

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

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

             and succeeded by the line

                textend.all

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

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

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

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

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

             means the last rules posted in July 2008.

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

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

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

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

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

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

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

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

        For example, if the browser encounters the following URL:

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

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

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        Analogy in the pre-FGHI world:

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

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

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

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

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

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

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

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

        Analogy in the pre-FGHI world:

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

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

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

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

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

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

        Analogy in the pre-FGHI world:

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

        http://bbs.keyhole.com/ubb/postlist.php?Board=modEarthTourism

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

           The above example has an equivalent FGHI URL:

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

        *) Primitive guestbooks and web chats. For example,

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

        Analogies in the pre-FGHI world:

        *) LiveJournal uses a similar view mode when viewing comments
           to a blog entry; for example,
      http://news.livejournal.com/106909.html?nc=4999&page=68#comments

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

          http://bbs.keyhole.com/ubb/showflat.php?Cat=0&Number=1132665

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

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

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

        Analogies in the pre-FGHI world:

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

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

           http://tinyurl.com/34rnm8

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

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

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

        Analogy in the pre-FGHI world:

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

          http://bbs.keyhole.com/ubb/showflat.php?Cat=0&Number=1132665

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

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

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

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

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

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

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

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

        Analogies in the pre-FGHI world:

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

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

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

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

    7.2.4. Controlling the visibility of kludges and hidden lines
    -+-----------------------------------------------------------

      This section is informative. Its subsection is normative.

      Kludges (also known as klugde lines or as control paragraphs)
      are special lines embedded in the text body of a Fidonet
      message. Sometimes kludges are used to support new addressing
      and other control information, sometimes they contain pieces of
      auxiliary information about the message's author (location, ICQ
      UIN, Jabber ID, real name, current music, current mood, etc.)
      See technical details in FTS-4000.

      It is said in FTS-4000 that the contents of kludges are intended
      for the programs processing the message (or the copies of the
      message) and not for presentation on the user interface level.

      Fidonet messages usually contain some other special lines of the
      same nature, intended for the programs processing the message,
      and usually hidden from the user. However, that hidden lines
      do not start from SOH (Ctrl+A, ASCII 1) symbol, and thus are not
      kludges. Seen-by stamps, for example, are hidden lines.

      Users are generally able to specify (in user settings or just by
      hotkeys) which kludges and hidden lines are hidden and which are
      visible in their Fidonet browsers. For example, moderators use
      hidden lines to control the expansion of their echoes. Many of
      the non-standard kludges (e.g. location, ICQ UIN, Jabber ID,
      real name, current music, current mood, etc.) are intended to be
      read by humans, but are designed as kludges so that thay can be
      easily hidden by readers annoyed by excessive headers.

      If an author of some "area://" URL feels that some kludge and/or
      some hidden line of the designated message(s) contains relevant
      information, then the author MAY append an optional parameter
      to that URL, in order to overcome the user settings and to show
      the desired kludge or hidden line.

      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 appendix A for the details about regular expressions.

        When testing whether a kludge matches a regular expression,
        the SOH (Ctrl+A, ASCII 1) symbol MUST be omitted. For example,
        /^[PT]ID/ expression MUST match both "PID" and "TID" kludges,
        though there is SOH between the line beginning (^) and the
        first symbol of the kludge ([PT]) in both of the kludges.

        Consequently, "kl=" regular expressions differ with "find="
        regular expressions for kludges (see subsection 7.2.1.4),
        and "kl=" expressions are shorter.

        Note: It is not necessary for a "kl=" expression to contain
        "/m" flag, because the "^" construct already matches at the
        beginning of each kludge.

        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.2.5. Optional parameter "full"
    -+------------------------------

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        For example, if the browser encounters the following URL:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     http://groups.google.com/group/fido7.Ru.FTN.Develop/search?q=FGHI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        The order is the following:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Example:

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

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

      Example:

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

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

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

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

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

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

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

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

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

         The "Forum mode" of message sorting is achieved.

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

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

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

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

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

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

  7.3. "faqserv://" scheme
  -+----------------------

    FAQ servers are Fidonet stations that accept special requests
    containing file names (or aliases) of certain texts. Such requests
    are sent via Fidonet netmail. The FAQ server processes the request
    and sends the requested text to the sender of request; the text is
    sent via Fidonet netmail in a single letter (as a whole)
    or in several letters (in sections).

    The faqserv URLs take the form:

    faqserv://<server>/<request>/<object-path>?<optional-part>

    The character "/" has its literal meaning in the <optional-part>
    of URLs of this scheme. The character "/" has its reserved meaning
    in the required part of URL (<server>/<request>/<object-path>),
    playing the role of delimiter between parts of the path. However,
    inside <server> part the character "/" again MUST have its literal
    meaning and MUST appear once (and only once!) as the delimiter
    between parts of the server address.

    The <server> part of a faqserv URL MUST be present. The standard
    Fidonet addressing notation, <zone>:<net>/<node>.<point>@<domain>
    (see FSP-1004 for details), is used in <server> address. However,
    some parts of address ("<zone>:", "@<domain>" and/or ".<point>")
    MAY be omitted (again, see FSP-1004 for details). The <server>
    part of a faqserv URL specifies the Fidonet address of the station
    (the FAQ server) which is implied to be queried.

    If the <object-path> of a faqserv URL is not empty, then
    its <object-name> MUST also be non-empty by definition, and
    it specifies the name of an object embedded in the netmail text
    of the response sent by that FAQ server. Either that object
    or some of its inner parts, according to <object-path>, is
    designated.

    However, the netmail response messages MAY contain more than one
    object of the same name. In this case the designated object is
    the latest one among only those which are known how to decode
    them. See section 7.2.2.2 for the details of what object is
    considered the latest.

    The <request> part of a faqserv URL, if present, MUST NOT
    be empty.

    If the <request> part of a faqserv URL is not present at all, then
    the <object-path> MUST also be empty and "<request>/<object-path>"
    MUST be omitted entirely, and the preceding "/" character MAY also
    be omitted. In this case the faqserv URL designates the FAQ server
    itself, as a Fidonet system. Such an URL MAY designate an action
    and not a resource; for example, it MAY designate adding the given
    FAQ server to some list or to a database of FAQ servers.

    Examples:

       faqserv://2:5043/17.100@fidonet/
       faqserv://2:5054/80.999

    However, such an action MUST NOT imply sending any requests to
    the designated server. Different FAQ servers use different names
    of the default request; it can be 'FILES', 'LIST', 'INDEX', 'HELP'
    or any other name. That's why a Uniform Resource Locator MUST NOT
    expect the URL processor to have any extra knowledge besides the
    data given in the URL itself. If a request is needed, than the
    corresponding part of a faqserv URL MUST be present and not empty,
    containing the request (see details below).

    If the <request> part of a faqserv URL is present, it contains
    the request to be sent to the given server. The URL designates
    either the response as a whole (if the <object-path> is empty),
    or just an object inside the response (if the <object-path> is
    not empty).

    Examples:

       faqserv://2:5054/83/ELINE/blath/Feainnewedd         (an object)
       faqserv://2:5054/83/TNT                (<object-path> is empty)
       faqserv://2:5054/83/TNT_FAQ/           (<object-path> is empty)

    If the <request> part of a faqserv URL is present, then receiving
    a message (or several messages) via netmail is implied. However,
    most of the auxiliary technical and decorative elements of netmail
    (i.e. taglines, tearlines, origin lines, greeting lines, signature
    lines, etc.) SHOULD be stripped from the response text when the
    netmail is received and the response is extracted from it. It is
    useful to remember that the response MAY span several messages,
    and sections of it SHOULD be stripped of all their wrappings
    before they are finally combined.

    If is possible for resources designated by faqserv URLs to appear
    as elements of complex data structures (e.g. as objects on pages
    of hypertext). Fidonet browsers SHOULD cache the extracted objects
    and/or raw netmail response letters to allow immediate rendering
    of the resources already requested before.

    7.3.1. Optional parameter "time"
    -+------------------------------

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

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

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

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

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

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

      Examples:

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

    7.3.2. Optional parameter "bot"
    -+-----------------------------

      Sometimes the FAQ server station does not respond to the request
      that is not addressed to a certain name of the service robot.
      Such a behaviour is especially natural for stations where the
      same <zone>:<net>/<node>.<point>@<domain> address is shared by
      both human and automatic addressees, or where several bots exist
      (e.g. a FAQ robot and an areafixing robot).

      In such cases the "bot" optional parameter is appended to the
      faqserv URL. The value of the "bot" optional parameter specifies
      the name of the necessary addressee; it MUST be copied verbatim
      to the corresponding message field of the netmail request.

      Examples:

         faqserv://2:5030/1269.12/NUSRCHIP?bot=FAQServer
         faqserv://2:5020/1583.770/64kfido?bot=SU.CHAINIK+FAQSERVER

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

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

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

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

      Examples:

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

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

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

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

    Fidonet file echoes are somewhat similar to the echomail areas
    in the terms of transport and distribution. However, files are
    broadcast there instead of messages. File echo is a shared base
    of files that have common areatag (file echo identifier) and are
    distributed through Fidonet via hierarchical and/or p2p-alike
    connections between individual Fidonet systems (nodes and points).

    The fecho URLs take the form:

    fecho://<areatag>/<object-path>?<optional-part>

    The character "/" has its literal meaning in the <optional-part>
    of URLs of this scheme. The character "/" has its reserved meaning
    in the required part of URL (<areatag>/<object-path>), playing
    the role of delimiter between parts of the path. If an <areatag>
    contains the character "/" in its literal meaning, the character
    MUST be encoded.

    If the <object-path> part is empty, the fecho URL designates the
    file echo as a whole.

    Examples:

       fecho://aftnbinkd
       fecho://XOFCELIST/

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

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

    Examples:

       fecho://XOFCELIST+XOFCERULES%20XOFCFELST+XOFCHUBSLST
       fecho://XPICAERO+XPICART+XPICCARS+XPICCAT+XPICCOMP%20XPICHUMOR/

    If the <object-path> of a fecho URL is not empty, then
    its <object-name> MUST also be non-empty by definition,
    and it specifies the name of a file that is available
    as a result of a broadcast though the given file echo.

    Examples:

       fecho://aftnmisc/HATCHDIR.RAR
       fecho://aftnged/RUGEDFAQ.RAR/gedplus.faq
       fecho://FIDONEWS/FNEWSK19.ZIP/
       fecho://aftnbinkd/BNDMAN.ZIP/man/gif/

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

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

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

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

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

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

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

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

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

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

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

      Examples:

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

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

      Future versions of this document MAY introduce some optional
      parameters for "fecho://" URLs, but Fidonet software MAY safely
      ignore any unknown parameters in "fecho://" URLs.

  7.5. "freq://" scheme
  -+--------------------

    It is possible for Fidonet stations to request files directly
    from each other; there is even a protocol of distributed
    file requests, proposed in FSC-0071.

    The freq URLs take the form:

    freq://<server>/<object-path>?<optional-part>

    The character "/" has its literal meaning in the <optional-part>
    of URLs of this scheme. The character "/" has its reserved meaning
    in the required part of URL (<server>/<object-path>), playing
    the role of delimiter between parts of the path. However, inside
    the <server> part the character "/" again MUST have its literal
    meaning and MUST appear once (and only once!) as the delimiter
    between parts of the server address.

    The <server> part of a freq URL MUST be present. The standard
    Fidonet addressing notation, <zone>:<net>/<node>.<point>@<domain>
    (see FSP-1004 for details), is used in <server> address. However,
    some parts of address ("<zone>:", "@<domain>" and/or ".<point>")
    MAY be omitted (again, see FSP-1004 for details). The <server>
    part of a freq URL specifies the Fidonet address of the station
    that will provide the requested file.

    If the <object-path> is empty, the freq URL designates the station
    itself, as a Fidonet system able to provide files by request.

    If the <object-path> of a faqserv URL is not empty, then
    its <object-name> MUST also be non-empty by definition, and
    it specifies the name of a file that is requested from the remote
    Fidonet station specified by the <server> part of the URL. The URL
    designated either the file itself or one of inner part of the file
    (according to the structure of the <object-path> part of the URL).

    Examples:

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

    If is possible for resources designated by freq URLs to appear
    as elements of complex data structures (e.g. as objects on pages
    of hypertext). Fidonet browsers SHOULD cache the requested files
    when they are received, in order to allow immediate rendering of
    the resources already requested before.

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

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

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

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

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

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

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

      Examples:

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

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

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

      Examples:

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

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

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

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

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

      Example:

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

         MAY be converted to

         ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|/
         
      (the character sequence "%%" is used here to mark the place
      where a line break appears inside the URL, and then where
      the URL resumes; see section 5.2.2.5 for details).

    7.5.4. Optional parameter "aich"
    -+------------------------------

      The "aich" parameter's value contains the file's AICH hash,
      which is defined and used by the system of Advanced Intelligent
      Corruption Handling in eMule and eMule-compatible servents of
      ed2k/Kad file exchange. AICH hashes help to isolate and discard
      file fragments that were corrupted in transfer.

      When a Fidonet browser converts "freq://" URLs to "ed2k://" URLs
      and feeds the latter to a ed2k-compatible client or servent,
      AICH hashes MAY be appended to the "ed2k://" URLs.

      Example:

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

         MAY be converted to

         ed2k://|file|R50EP|25000|12995897117400DD5E24344890CEF1B4|h%%
         %%=Y273T53VY4IESJSQCMFO6X4PIGEWUEEW|/

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

      The "aich" parameter is auxiliary, it SHOULD NOT appear in URLs
      where "ed2k" or "size" parameters are missing (and where thus
      "ed2k://" equivalent URLs MAY NOT be built).

    7.5.5. Optional parameter "fecho"
    -+-------------------------------

      The "fecho" parameter's value contains an echotag of the file
      echo where the designated file was, more or less recently,
      broadcasted. The value MAY contain several (space-separated)
      echotags if the file was cross-posted (i.e. sumultaneously
      published) in several file echoes.

      If a file request fails for some reason, or if the Fidonet
      station is subscribed to the given file echo (so the file is
      instantly available as opposed to the immanent delay of file
      requests), or if user options dictate using file echoes as the
      preferred method of getting files, then Fidonet browsers MAY
      convert "freq://" URLs to "fecho://" URLs and use the latter
      by themselves or feed to any fileechomail-managing software.

      Example:

         freq://2:50/13/echo50.lst?fecho=XOFCELIST%20ECHOLIST.LOCAL

         MAY be converted to

         fecho://XOFCELIST+ECHOLIST.LOCAL/echo50.lst

      If the "freq://" URL contains several "fecho" parameters, they
      MUST be interpreted as if their values were space-separated
      within one "fecho" parameter, i.e. the file was sumultaneously
      published in all the file echoes given in that parameters.

    7.5.6. URL-based extension for WaZOO file requests
    -+------------------------------------------------

      According to FTS-0006.002, a WaZOO file request is based on
      a request file (.REQ file), and each line of such a file
      contains the following elements (space-separated from each
      other):

      *) The filename of a requested file. This element is mandatory.

      *) A password to get the requested file. This element is
         optional and is always preceded by an exclamation mark
         ("!" character) to distinguish it from the other optional
         element.

      *) The type of update and the time. This element is optional
         and is always preceded by a plus sign ("+") or a minus sign
         ("-") to indicate the update type and to distingush this
         optional element from the other.

      If the system which sends the request is capable of creating
      FGHI URLs, it MAY extend the line with yet another optional
      element:

      *) The "freq://" URL of the file. This element is always
         preceded by an opening square bracket ("[") and followed
         by a closing square bracket ("]") to distinguish it from
         the other optional elements.

      Such an URL-based extension for WaZOO file requests has
      the following advantages:

      *) It is backwards-compatible: even if the freq server that
         processes the request is not aware of FGHI URLs, it still
         MAY read the filename at the beginning of a line and respond
         with the desired file.

      *) The "freq://" URL MAY contain the "fecho" optional parameter
         (see section 7.5.5), so a freq server completely subscribed
         to some file echo MAY provide partial file feeds of it to its
         clients.

      *) The "freq://" URL MAY contain the "ed2k" optional parameter
         (see section 7.5.3) and the "size" optional parameter (see
         section 7.5.2), and then a freq server MAY ignore the given
         filename and becomes capable of finding even a renamed file
         if that has the desired ed2k hash and size. A freq server MAY
         also act as a Fidonet interface to the ed2k/Kad file exchange
         network, getting files from some other ed2k/Kad servents
         on behalf of some other Fidonet systems. The "aich" optional
         parameter, if it's present in the URL, assists in both of
         these possible tasks.

      Example of such a line from a .FRQ file:

IMAGINAT.MP3 [freq://2:9999/999/imaginat.mp3?size=6583780&ed2k=D2D625C

      and, on the same line (being continued):

DDC893B1ED2B12723A54E15BE&fecho=Local.MP3]

      *) The "freq://" URL contains the server address, and thus
         the response MAY vary accordingly. Virtual servers (virtual
         points) MAY coexist on the same physical station (like in WWW
         virtual hosts aka virtual servers coexist on the same
         Web server, where the HTTP response MAY vary according
         to the "Host" field of the incoming HTTP/1.1 request).

      *) Freq servers MAY also accept URLs containing addresses
         of other freq servers, and forward such requests to that
         servers. If an uplink or downlink is known to support the
         protocol of distributed file requests, proposed in FSC-0071,
         then the request MAY be forwarding through that link via
         FSC-0071. If an uplink or downlink is known to support
         URL-based extension for WaZOO file requests and to accept
         other servers in URLs, then the request MAY be forwarded
         through that link in the same manner it was initially
         received by the forwarding node.

      *) Freq servers MAY also accept some URLs that are not based on
         the "freq://" scheme; by accepting and serving these URLs,
         such servers MAY act, for example, as file gates that allow
         other Fidonet stations to request FTP-hosted or HTTP-hosted
         files by their URLs.

         Example of such a line from a .FRQ file:

MILITARY.JPG [http://www.rus-obr.ru/files/0%2C1020%2C1266809%2C00.jpg]

         When HTML page is provided by the freq gate, the linked files
         of that page (such as images, stylesheets, scripts, embedded
         objects) MAY also be provided, so that the gate will spare
         its clients the trouble of requesting such files. However,
         the client MAY already have all these files requested and
         cached earlier. In such cases the freq gate, trying to be
         excessively courteous, just generates unnecessary traffic;
         that's why gates SHOULD refrain from such practice.

         Such an URL, of course, MAY be a FGHI URL. For example, by
         accepting "area://" URLs containing file paths (see section
         7.1 and section 7.2.2), a Fidonet station subscribed to some
         UUE echomail area MAY act as a file gate for other stations
         that are not subscribed to the same area but sometimes need
         a file or two from that area.

         Example of such a line from a .FRQ file:

         C-DREAM.ZIP [area://Fido7.Sound.UUE/c-dream.zip?time=2004/04]

      Nodelist flags indicating FGHI freq capabilities (see section
      7.5.8) SHOULD be taken into consideration when the file request
      is compiled and sent.

    7.5.7. FGHI URLs of file responses (.FUF index)
    -+---------------------------------------------

      Previously (in pre-hypertext Fidonet) responses of file request
      servers were expected to be manually processed on the requesting
      systems. The receiving user was expected to remember filenames
      of desired files, was expected to manually find them in his/her
      inbox after the files are served by the freq server.

      Hypertext REQUIRES a higher degree of automation: the only
      manual action REQUIRED from a user is mouse clicking (or
      otherwise following) a "freq://..." hyperlink.

      To achieve such a degree, the browser MAY analyse the inbox,
      automatically finding files with filenames mentioned in the
      previously sent .REQ file. However, such an analysis becomes
      much more reliable if the freq server provides its own list of
      sent files and sends the list with them (in an additional file).
      This method gives more freedom, more flexibility to the server,
      which is then allowed to rename files and to respond with files
      of unexpected extensions (e.g. error messages).

      The rules (by which such a .FUF file index is built) are the
      following:

      *) If the .REQ request does not contain any FGHI URLs (in square
         brackets), then the .FUF response SHOULD NOT be built at all:
         chanses are very high that the requesting node is not aware
         of FGHI, and thus the .FUF response is just an unnecessary
         burden for his (her) inbox.

      *) The name of .FUF file MUST be the same as of .REQ file. For
         example, if the request file was named 00010002.REQ (such as
         in FTS-0006), then the response index MUST be 00010002.FUF

      *) Each line of text in the .REQ file is a request. If that
         request is ignored, the corresponding line MUST NOT appear
         in .FUF response index. If the request is served, the line
         MUST appear in the .FUF response index: the filename and then
         the URL in square brackets MUST be present. If an URL was
         provided in the request line of the .REQ file, then the URL
         MUST be copied verbatim to the .FUF file; otherwise, the URL
         MUST be generated by the freq server. If a file is served
         under the same name it was requested, the name MUST be copied
         verbatim to the .FUF file (no case conversions, etc.); if the
         file is renamed by the freq server, or if another file (e.g.
         an error message) is provided instead of it, then the new
         name MUST appear in the .FUF file instead of the original
         name.

      If the browser (or some other piece of software, e.g. a special
      response processor) caches the responses to file requests, and
      if the received files are stored as is (i.e. as files, not as
      blocks of data inside some database), then the .FUF files SHOULD
      be appended to each other, creating one single combined index
      where the browser MAY later, looking by URL, find the name of
      any of the previously received files.

      In such a total .FUF index, the filename part of each line MAY
      contain also a relative path (relative from .FUF location), if
      the files are spread to several directories.

      In such a total .FUF index, the URL part of each line SHOULD be
      altered to contain an optional parameter "time" (see subsection
      7.5.1), in order to indicate when the response came. By checking
      "time" parameters in URLs against the "time" parameters in local
      .FUF index, the browser knows for sure whether it is necessary
      to re-request the file, or whether the cached copy fits. Even if
      the original timestamp of the requested file is not retained.

      Note: the "filename [URL]" format of the file index is similar
      to the format of DESCRIPT.ION files generated by Download Master
      (aka Internet Download Accelerator). If a Fidonet browser is
      able to feed a Fidonet mailer with "freq://" URLs and parse the
      resulting .FUF indexes, then the same browser is likely to be
      able to feed the Download Master with "http://" and "ftp://"
      URLs and parse the resulting DESCRIPT.ION indexes. This MAY be
      important if the Fidonet browser does not have its own Internet
      downloading capabilities, and if the user resides in Russia or
      in Ukraine or in Belarus (where Download Master is a freeware).

    7.5.8. Nodelist flags indicating FGHI freq capabilities
    -+-----------------------------------------------------

      If a Fidonet station is able to accept FGHI URL in file requests
      and responds with requested files and a .FUF index for each of
      such (extended) .REQ requests, then the station SHOULD fly
      the FUF flag in the corresponding line of the corresponding
      nodelist (or pointlist), in accordance with the section 6
      ('Userflags') of FTS-5001.

      Example of a pointlist line (taken from FTS-5002.001 and
      slightly altered):

         ,1,First_point,Somewhere,John_Doe,-Unpublished-,300,U,FUF

      If the station accepts URL schemes other that "freq://", then
      such schemes SHOULD be given after the "FUF" flag, and each
      scheme there MUST be preceded by a semicolon (the character
      ":").

      Example of a nodelist line:

         ,9999,FGHI_proxy,Some_place,Jane_Doe,12-34-567890,9600,V34,
         IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:area:magnet

         As mentioned above (in section 7.5.6), such a station MAY be
         called by non-Internet nodes of Fidonet (capable of dial-up
         only) when they need a WWW file ("http://..."). The station
         is also capable of providing files decoded from echomail
         ("area://.../filename", probably with additional optional
         parameters) and files available from certain file exchange
         networks ("magnet:...").

      If station also supports the multi-node extension of FGHI URL
      file requests (i.e. if the station accepts "freq://" URLs
      pointing to other nodes, and forwards such file requests to that
      nodes, and responds with the results of the forwarded requests),
      then the flag "FUFME" SHOULD be used instead of "FUF".

      Example of a nodelist line:

         ,9999,FGHI_proxy,Some_place,Jane_Doe,12-34-567890,9600,V34,
         IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFME:http:area:magnet

         Such a FUFME node, if capable of both Fido-over-IP and
         dial-up Fidonet connections, MAY be used as a proxy server
         by "Internet-only" and "dial-up only" nodes when they wish
         to request files from each other, but cannot make direct
         connection. (In such case, an "Internet-only" node SHOULD
         choose the FUFME proxy only from the same net where the
         request destination resides: FUFME nodes are not expected
         to make international or even long distance phone calls.)

      A Fidonet system MAY be able or willing to accept file requests
      for files that reside on only some other systems; for example,
      a Fidonet node MAY accept file requests only for its points'
      files, a Fidonet host MAY accept file requests only for its
      downlinks' files. In such case, the flag "FUFME" MUST NOT be
      used; instead of the flag "FUFME", such station SHOULD fly
      the flag "FUFP" and/or the flag "FUFD".

      The flag "FUFP", when it appears in the nodelist line of some
      system, means that files that reside on that system's points
      MAY be requested from the system.

      The flag "FUFD", when it appears in the nodelist line of some
      system, means that files that reside on that system's downlinks
      MAY be requested from the system. (The flag "FUFD" MAY NOT be
      used if the nodelist line does not start with "Host" or "Hub"
      status, because the explicit list of downlinks is necessary.)

      Such stations MAY be used to provide an online proxy service for
      resources that would otherwise frequently go offline with their
      own systems. For example, a "CM" node MAY act as a proxy freq
      server for files hosted on its points, even when the points are
      offline, and a "CM" host or hub MAY act as a proxy for its "TYZ"
      downlinks. (For the meaning of "CM" and "TYZ", please, see
      FTS-5001 sections 5.1 and 5.7.) In order for this task to be
      fulfilled, such proxies SHOULD cache the resources requested
      by freqs, because later the cached file MAY be immediately given
      as an answer to any file request that is addressed to the same
      Fidonet station and contains the same filename and the same
      (or older) timestamp (the request is thus served even if the
      station to which it is addressed is offline). Such proxies,
      however, MUST refrain from serving such cached files as
      answers to requests that do not contain "time" parameter,
      because that would mean a risk of serving an older file to
      people who need a new version of it. (See section 7.5.1
      about the optional parameter "time" and its use in caching.)

      If the "FUF" flag does not contain any ":protocol" suffixes,
      the flag MUST NOT be flown when "FUFP" and/or "FUFD" is present
      in the same line of nodelist, because any of these flags already
      implies FGHI freq capabilities.

      Examples of nodelist lines:

         ,9999,FGHI_proxy,Some_place,Jane_Doe,12-34-567890,9600,V34,
         IBN,INA:Fidonet.Example.Org,CM,XW,U,FUF:http:ftp,FUFP

         Hub,9999,FGHI_proxy,Some_place,Jane_Doe,12-34-567890,9600,
         V34,IBN,INA:Fidonet.Example.Org,CM,XW,U,FUFD

    7.5.9. Future optional parameters
    -+-------------------------------

      Future versions of this document MAY introduce even more
      optional parameters for freq URLs, encouraging somewhat
      tighter control how the file is requested. For example, some
      Fidonet stations MAY deny or delay file requests that are sent
      in a certain inappropriate time of the day, or day of the week;
      so a parameter or two MAY appear to specify the time and the
      week day when the file request is relatively safe.

      Programs interpreting freq URLs SHOULD NOT be sure whether
      it is safe to ignore any of the unknown parameters. Some of
      future extensions may dramatically change the probability
      of the success of a file request, especially when such
      a parameter controls the file request time.

      If an unknown parameter is encountered in the freq URL,
      the user SHOULD always be asked whether it can be discarded
      safely enough.

Appendix A. Regular expressions
-+-----------------------------

  It is possible for an optional parameter of an area URL to contain
  a regular expression. In section 7.2.1.4 a regex is used to specify
  the designated message(s); in section 7.2.4.1 a regex defines
  whether a kludge is visible.

  The language of regular expressions has several dirrerent dialects.
  Perl Compatible Regular Expressions (PCRE) are chosen here as the
  RECOMMENDED one; that's because PCRE engine has a rich set of
  features, and because the engine is already embedded in ECMAScript-
  compatible browsers of the modern Web.

  The language of regular expressions is far beyond the scope of this
  document. The article http://en.wikipedia.org/wiki/PCRE (in
  Wikipedia) and the external links referenced there are probably
  the best to start learning how to write PCRE regexes.

  Some Fidonet browsers have their own JavaScript engines, that SHOULD
  conform to the requirements of the ECMA-262 standard, third edition,
  section 15.10. (The form and functionality of its regular
  expressions is modelled after the regular expression facility
  in the Perl 5 programming language.) Any other Fidonet browsers
  SHOULD use the PCRE library package, which is an open source
  software, written by Philip Hazel, and downloadable
  at http://www.pcre.org/

  Fidonet gates in the Web SHOULD use either Perl itself, or PCRE
  implementation in PHP (preg_grep() function, for example), or
  any other suitable PCRE-compatible implementation.

  A regular expression in a Fidonet URL MUST always take the form

                  /pattern/flags

  The only possible flag (pattern modifier) in Fidonet URLs is the
  letter "i" (if this modifier is set, letters in the pattern match
  both upper and lower case letters; in brief, "i" means ignoring
  of case).

  The regular expression MAY also contain the "m" flag (if this
  modifier is set, then the "start of line" and "end of line"
  constructs match immediately following or immediately before any
  newline in the subject string, respectively, as well as at the very
  start and end; in brief, "m" means multi-line mode of matching).
  However, even if the "m" letter is absent, this mode MUST be
  assumed. So the "m" letter MAY be omitted even if the corresponding
  mode is necessary; in kludge matching, for example (see section
  7.2.1.4).

Appendix B. Known implementations
-+-------------------------------

  By the time of this writing there are several implementation of the
  draft editions of this standard.

  B.1. HellEd
  -+---------

    HellEd is a GUI browser and editor of echomail and netmail. It was
    originally developed by Trooper (Alexey Bezugly, 2:5030/1520.9).

    It supports several FGHI URL schemes ("netmail:", "areafix:",
    "echomail:", "area://") since HellEd 1.2.56.

  B.2. FGHI URL gate
  -+----------------

    One of Fidonet nodes in Smolensk hosts a WWW gate (WebBBS) service
    that allows reading Fidonet from WWW by means of FGHI addressing.
    NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) is the sysop of that
    gate.

    The gate understands "area://" and "fecho://" URL schemes preceded
    by the gate's own WWW address. For example, the Fidonet echomail
    message that has FGHI URL

        area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

    is available by the following WWW address:

  http://fghi.pp.ru/?area://GanjaNet.Local/?msgid=2:5019/40.1+4982ec3f

    If the FGHI URL gate's visitor uses a Web browser compatible with
    HTML 5 draft API registerProtocolHandler(), then it is possible
    to visit http://fghi.pp.ru/handler.php and automatically register
    FGHI URLs within such a browser, so that then FGHI URLs may be
    entered in the browser's address bar to get Fidonet resources
    throught the gate. By the time of this writing, the necessary
    HTML 5 API is implemented in Firefox 3 and planned in Safari and
    in Opera.

  B.3. NoSFeRaTU's GoldED+
  -+----------------------

    NoSFeRaTU has also created a special fork of GoldED+, known as
    NoSFeRaTU's GoldED+, which supports "area://" FGHI URLs (though
    that support is based on the early versions of FGHI URL draft
    and thus has some limits). Early versions of NoSFeRaTU's GoldED+
    used a Web browser to access the URL-designated resources through
    the FGHI URL gate; current version of NoSFeRaTU's GoldED+ is able
    to open the URL locally (i.e. to find the designated message in
    the local echomail message base).

Appendix C. Foreseen future technologies
-+--------------------------------------

  This standard (the standard of FGHI URLs) is an obvious forerunner
  and precursor for many future technologies, some of which we are
  thus able to foresee unimpededly. This appendix contains a few early
  drafts and preview versions of possible standards for these future
  elements of the hypertext Fidonet.

  C.1. XML echolists
  -+----------------

    By the time of this writing, most of Fidonet echolists take one of
    the following two forms:

    1) Ingenuous echolist

       Each line of the text document contains an echotag,
       then a blank space and the echo's description.

    2) CSV echolist

       Each line of the text document contains a comma-separated list
       of values: echo's status, echotag, echo's description, name of
       the moderator, address of the moderator.

    Using XML to write echolists brings the following advantages
    of extensible markup language:

    *) data on a single echomail area MAY span several lines of text

    *) optional child elements are possible within parent elements

    *) comoderators MAY be mentioned next to moderators

    *) echoes MAY reference to URLs of rules (even to several URLs
       of mirrors)

    *) echoes MAY be organized (tags, categories, etc.)

    *) each echolist MAY contain the global identifier for the
       corresponding echomail bone and the list of nodes of that bone

  C.2. FFF (FGHI fidosphere features)
  -+---------------------------------

    Blogosphere and forums of the modern Web are both built upon WWW,
    but HTML seems too generic for them. Necessary elements of blogs
    and forums, elements like avatars or quoting or contacts, become
    lumps of non-semantic markup (HTML images, HTML blocks, sections
    of signature), because WWW browsers do not know of that elements'
    inner meanings.

    Now consider the hypertext Fidonet (the place where FGHI URLs meet
    kludges) as a place for social intercourse, as fidosphere. Seems
    obvious that a set of semantic kludges (defined below) is enough
    to contain all the necessary hyperlinks and reflect their semantic
    meanings. Fidosphere built upon FFF provides better separation of
    message and its social features than blogosphere upon WWW does.

    In the below examples, "^a" represents a single SOH character
    (Ctrl+A, ASCII 1).

    C.2.1. Social file (SOCFILE kludge)
    -+---------------------------------

      This kludge contains an URL of an external file. That file
      contains one or more of the kludges defined in the following
      sections of this document. Fidonet browsers SHOULD attempt
      to get FFF kludge values from the social file first, and then
      from the Fidonet message (netmail letter, echomail letter).
      If kludges of the same name are discovered in the social file
      and in the Fidonet message, the kludge of the message takes
      precedence, and the kludge from the social file is discarded.

      Such a file, if given, eliminates the need of repeating most
      of the kludges again and again in each of the Fidonet messages
      of the same author. Such a precedence, if taken, allows the
      message author to redefine one or more properties of the message
      (or of the author) without touching the social file and without
      forcing all the readers to reload that file.

      The URL authors SHOULD properly give the "time" optional
      parameter (if available for the URL scheme of their URLs)
      to encourage caching of their social files.

      The message MAY contain several SOCFILE kludges, in that case
      Fidonet browsers MAY choose any of the given URLs they see fit.

      Example:

         ^aSOCFILE: faqserv://2:5063/88/socfile/socfile.txt?time=2009
         ^aSOCFILE: http://mithgol.ru/socfile.txt

      (In this example, Fidonet browsers of Internet-connected nodes
      MAY prefer the Web server, and the rest of nodes MAY prefer the
      Fidonet FAQ server.)

      The social file MUST have the following inner structure:

      *) If the line of text starts with a semicolon (";"),
         the rest of the line represents the name of some kludge.

      *) If the line of text starts with a colon (":"),
         the rest of the line represents the value of the kludge
         named in the nearest above given ";"-line.
         (The social file MAY contain one or more of such ":"-lines
         that represent values of one or more kludges of the same
         name.)

      Example:

         ;RealName
         :Robert A. Hayden
         ;GeekCode
         :GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
         :E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
         :PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
         :DI+++ D+++ G+++++ e++  h r-- y++**

      This example represents the following kludges (as if they
      directly appeared in the message referencing the social file):

         ^aRealName: Robert A. Hayden
         ^aGeekCode: GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++
         ^aGeekCode: E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$
         ^aGeekCode: PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+
         ^aGeekCode: DI+++ D+++ G+++++ e++  h r-- y++**

      A moderator MAY force echomail authors to move most of their FFF
      kludges to their social files, except for the SOCFILE kludges
      themselves, and probably also for the few most volatile kludges
      (such as current mood, current music, avatars, wiki roots,
      etc.). Some FFF kludges (like QUOTE and especially UPD)
      SHOULD NOT ever appear in social files because these kludges
      are different across messages of the same author. See details
      in the corresponding sections below.

**********************************************************************
EOTD                                               END OF THE DOCUMENT
**********************************************************************