= Сообщение: 2483 из 3030 =================================== GANJANET.LOCAL = От : Mithgol the Webmaster 2:5063/88 14 Oct 07 00:17:26 Кому : All 14 Oct 07 00:17:26 Тема : [1/11] FidoURL.txt FGHI : area://GANJANET.LOCAL?msgid=2:5063/88+47112837 На : area://GANJANET.LOCAL?msgid=2:5063/88+45cda489 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== * изначально написано в эхоконференцию FTSC_Public * также было отослано в эхоконференцию GanjaNet.Local * также было отослано в эхоконференцию Ru.Fido.WWW * также было отослано в эхоконференцию Ru.FTN.Develop * также было отослано в эхоконференцию SU.FidoTech * также было отослано в эхоконференцию Titanic.Best
textsection 1 of 11 of file FidoURL.txt textbegin.all
********************************************************************** FGHI FIDONET GLOBAL HYPERTEXT INTERCHANGE ********************************************************************** Status: draft Revision: 0.4 Title: FGHI URL, the set of Uniform Resource Locators for Fidonet objects and services Author: Mithgol the Webmaster (Sergey Sokoloff, 2:5063/88) Special thanks to: Shannar (Boris Kassal, 2:463/587) Trooper (Alexey Bezugly, 2:5030/1520.9) NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) Revision Date: 13 Oct 2007 -+-------------------------------------------------------------------- Contents: 1. Status of this document 2. Introduction 3. Key words to indicate requirement levels 4. Changelog of this document 5. General Fidonet URL syntax 5.1. The main parts of URLs 5.1.1. Conformance note 5.1.2. Delimiter guidelines 5.2. URL character encoding 5.2.1. Encoding of original characters 5.2.2. Encoding of octets 5.2.2.1. No corresponding graphic 7-bit character 5.2.2.2. Unsafe characters 5.2.2.3. Reserved characters 5.2.2.3.1 Using domain suffixes in areatags 5.2.2.4. The plus ("+") and the encoding of white spaces 5.2.2.4.1. Specificity note 5.2.2.4.2. Internet practice note 5.2.2.5. URLs that span several lines of text in Fidonet 5.3. Parsing the scheme-specific part of URL 5.3.1. Dealing with inappropriate reserved characters 6. Fidonet URL schemes designating actions 6.1. "netmail:" scheme 6.1.1. Optional parameter "to" 6.1.2. Optional parameter "subject" 6.1.3. Optional parameter "subj" 6.1.4. Optional parameter "from" 6.1.5. Optional parameter "body" 6.2. "areafix:" scheme 6.2.1. Optional parameter "uplink" 6.2.2. Optional parameters "unsubscribe" and "leave" 6.2.3. Future optional parameters 6.2.4. Relative "areafix:" URLs 6.3. "echomail:" scheme 6.3.1. Optional parameter "to" 6.3.2. Optional parameter "subject" 6.3.3. Optional parameter "subj" 6.3.4. Optional parameter "from" 6.3.5. Optional parameter "body" 7. Fidonet URL schemes designating objects 7.1. The <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.4. Filters of "find" type 7.2.1.5. Geographically referenced echomail 7.2.1.5.1. GEO kludge 7.2.1.5.2. GEOBOX kludge 7.2.1.5.3. GEOKML kludge 7.2.1.5.4. Coordinates in nodelists and pointlists 7.2.1.5.5. Filters of "geomark" type 7.2.1.5.6. Filters of "geofrom" type 7.2.1.6. Future message filters 7.2.2. Encoded objects within echomail messages 7.2.2.1. Names of encoded objects 7.2.2.2. How the designated object is determined 7.2.2.2.1. Possible applications 7.2.3. Regular expressions 7.2.4. Controlling the visibility of kludges and hidden lines 7.2.4.1. Optional parameter "kl" 7.3. "faqserv://" scheme 7.3.1. Optional parameter "bot" 7.3.2. Future optional parameters 7.4. "fecho://" scheme 7.5. "freq://" scheme 7.5.1. Future optional parameters -+--------------------------------------------------------------------
1. Status of this document -+------------------------
This document is a draft of a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard that can be used both in the Fidonet community and in the Web, and requests discussion and suggestions for improvements.
Implementation of the protocols defined in this document is not mandatory, but all implementations of these protocols are expected to adhere to this standard.
Distribution of this document is unlimited, provided that its text is not altered without notice.
2. Introduction -+-------------
This document specifies several Fidonet schemes of Uniform Resource Locators (URL), providing both syntax and semantics of formalized information for location and access of resources and services via Fidonet.
It is designed to conform with the specifications of RFC 1738, so hyperlinks specified according to this document could be used both in Fidonet (echomail, netmail) and in the traditional HTML hypertext environment of the Web and Internet e-mail.
Besides its independent significance, this document will serve as the first and the most basic part of FGHI (pronounced 'fig-high', stands for 'Fidonet Global Hypertext Interchange') -- that is future hypertext automation of some currently manual Fidonet operations, delivery and browsing of HTML-alike illustrated hypermedia over the traditional set of echomail and netmail plain-text connections, and probably some other elements of hypertext-over-Fido networking.
3. Key words to indicate requirement levels -+-----------------------------------------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in FTA-1006 (based on RFC 2119).
4. Changelog of this document -+---------------------------
In version 0.4: [13 Oct 2007]
*) renamed message-identifying optional parameters; now they are called message filters (see sections 7.2.1, 7.2.2.2 and their subsections) *) several filters of the same type may now be used simultaneously *) the "/m" flag is now always implied in regular expressions (section 7.2.3), thus it can be omitted when searching for kludges (section 7.2.1.4) *) now default requests can't be implied in "faqserv://" URLs (section 7.3) *) optional suffix "@domain" added to areatags to distinguish between different FTNs (requested by Scott Little) in "area://" URLs (section 7.2), in "areafix:" URLs (section 6.2), and in "fecho://" URLs (section 7.4); the character "@" is now a reserved character inside areatags (section 5.2.2.3.1) *) added a paragraph to clarify the difference between undecodable objects and unknown containers (in section 7.2.2.2) *) several uplinks and/or lists of uplinks can be specified in "areafix:" URLs (section 6.2.1) *) single "areafix:" URL may contain several areatags (section 6.2), so it should be possible now to subscribe to several echoes with single mouse click (requested by Dmitry Gaivoronsky) *) single "echomail:" URL may contain several areatags (section 6.3) to support cross-posting of messages (i.e. messages are sent to several echoes with single mouse click) *) single "area://" URL may contain several areatags (section 7.2) to designate a set of messages from several echomail areas *) multi-line URLs (requested by Alex Kocharin) are now possible (section 5.2.2.5) *) filters of "mid" type are no longer needed, use "msgid" instead (the corresponding section is deleted) *) new message filter "time" (section 7.2.1.2) and TrueTime kludge (subsection 7.2.1.2.9) *) echomail may contain geographic references (section 7.2.1.5) and be filtered geographically
In version 0.3: [10 Feb 2007]
*) started this changelog *) added subsection 7.2.1.3 (Optional parameter "from") *) added subsection 7.2.1.4 (Optional parameter "find") *) edited the surrounding subsection 7.2 to reflect the fact that now several messages can be identified, not only a single message *) added special thanks to NoSFeRaTU *) edited subsection 5.2.2.4.2, RFC 1630 is mentioned *) edited the list of examples in section 5 *) added subsection 7.2.3 (Regular expressions) *) added subsection 7.2.4 (Controlling the visibility of kludges and hidden lines) *) edited subsection 5.2.2.2, the word "Origin" in not unsafe now *) edited the subsection 7.5.1 to reflect the fact that requests may be delayed
5. General Fidonet URL syntax -+---------------------------
Just as there are many different types of Fido objects and services, there are several URL schemes for describing the location of such resources.
The generic syntax for URLs provides a framework for new schemes to be established using protocols other than those defined in this document.
URLs are used to 'locate' resources, by providing an abstract identification of the resource location. Having located a resource, a Fidonet system may perform a variety of operations on the resource (as might be characterized by such words as 'access', 'subscribe', 'unsubscribe', 'send', 'request', 'show attributes').
5.1. The main parts of URLs -+-------------------------
In general, Fidonet URLs are written as follows:
<scheme>:<scheme-specific-part>
Any URL contains the name of the scheme being used (<scheme>) followed by a colon and then a string (the <scheme-specific-part>) whose interpretation depends on the scheme.
Scheme names consist of a sequence of characters. The lower case letters "a"--"z", digits, and the characters plus ("+"), period ("."), and hyphen ("-") are allowed. For the sake of resiliency, programs interpreting Fidonet URLs SHOULD treat upper case letters in scheme names as equivalent to the corresponding lower case letters (e.g., allow "AREA" scheme name as well as "area").
Only the first colon of the URL plays the role of delimiter between <scheme> and <scheme-specific-part>. The scheme-specific part of any URL MAY contain other colons.
The colon delimiter between <scheme> and <scheme-specific-part> MAY be immediately followed by an optional double slash ("//"). Fidonet programs interpreting URLs MUST treat the delimiter "://" as equivalent to the simple colon before <scheme-specific-part>.
5.1.1. Conformance note -+---------------------
This subsection is informative.
The Fidonet URL schemes defined in this document consist of lower case letters "a"--"z" only. However, digits, and the characters plus ("+"), period ("."), and hyphen ("-") MUST also be allowed in scheme names, so that Internet schemes conforming with the specifications of RFC 1738 are correctly dealt with.
In current Internet practice they distinguish between delimiters ":" and "://". The delimiter "://" is often used after scheme names that designate objects and resources ("http://", "ftp://", "gopher://", "nntp://", "ed2k://", "file://", etc.). The delimiter ":" is often used after scheme names that designate actions (e.g. "mailto:", "skype:").
The same difference exists between Fidonet resources (objects) and actions. That's why, though these delimiters MUST always be interpreted as equivalent, it is still RECOMMENDED that ":" SHOULD be used after schemes that designate actions ("netmail:", "echomail:", "areafix:") and "://" SHOULD be used after schemes that designate resources ("area://", "freq://", "fecho://", "faqserv://", etc.).
5.2. URL character encoding -+-------------------------
URLs are sequences of characters (i.e., letters, digits, and/or special characters). URLs may be represented in a variety of ways: e.g., ink on paper, or a sequence of octets in a coded character set. The interpretation of URL depends only on the identity of the characters used.
It is useful to distinguish between a "character" (distinguishable semantic entity) and an "octet" (an 8-bit byte).
In most URL schemes, the character sequences in different parts of a URL are used to represent sequences of octets used in Fidonet services. For example, in the "netmail:" scheme, the Fidonet address, netmail subject and addressee name are such sequences of octets, represented by parts of the URL. That sequences of octets, in turn, represent the original characters (of subject line, or of sysop's name, etc.); each original character is represented by one or more octets.
So there are always two mappings, one from URL characters to octets, and the second from octets to original characters:
URL character sequence<->octet sequence<->original character sequence
5.2.1. Encoding of original characters -+------------------------------------
The following paragraph is informative.
The sequence of octets defined by a component of the URL is subsequently used to represent a sequence of original characters. That process could have a very volatile nature. Being an international network, Fidonet always needs to deal with hundreds of national characters, with dozens of available encoding traditions and character sets. There is a number of FSC (Fidonet Standard Proposal documents) suggesting several kludge-based methods to define which character set is used. However, it is not wise to implement any equivalents to kludges as a required part of every Fidonet URL; and it could be hard to mantain complete lists of all possible character sets inside all programs interpreting Fidonet URLs. (Remember, it should be also made possible for Fidonet URLs to appear and be well interpreted in traditional HTML hypertext environment of the Web, Internet e-mail, instant messaging, etc.) That's why only one encoding, with large enough character set, has to be chosen.
The following paragraphs of this subsection are normative.
The sequence of octets used in Fidonet URLs MUST always contain UTF-8 encoded representation of original characters.
ISO/IEC 10646-1 defines a multi-octet character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. And UTF-8, one of a few so-called UCS transformation formats (UTF), preserves the 7-bit ASCII range, thus providing some compatibility with file systems, parsers and other software elements that rely on 7-bit ASCII values but are transparent to other values.
UTF-8 is defined in RFC 2279. Its description can also be found in Unicode Technical Report #4 and in the Unicode Standard, version 2.0.
textend.section
With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 203. I will not employ an evil wizard if he has a sleazy mustache. --- Orcs are near, All! My Golded 1.1.5-b20060515 is gleaming!.. * Origin: I have a strange feeling, as if I already had a deja vu (2:5063/88)
