Text 1050, 365 rader
Skriven 2007-10-14 00:19:30 av Mithgol the Webmaster (2:5063/88)
Ärende: [1/11] FidoURL.txt
==========================
* originally in FTSC_Public
* also sent to GanjaNet.Local
* also sent to Ru.Fido.WWW
* also sent to Ru.FTN.Develop
* also sent to SU.FidoTech
* also sent to Titanic.Best
textsection 1 of 11 of file FidoURL.txt
textbegin.all
**********************************************************************
FGHI FIDONET GLOBAL HYPERTEXT INTERCHANGE
**********************************************************************
Status: draft
Revision: 0.4
Title: FGHI URL, the set of Uniform Resource Locators
for Fidonet objects and services
Author: Mithgol the Webmaster (Sergey Sokoloff, 2:5063/88)
Special thanks to: Shannar (Boris Kassal, 2:463/587)
Trooper (Alexey Bezugly, 2:5030/1520.9)
NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1)
Revision Date: 13 Oct 2007
-+--------------------------------------------------------------------
Contents:
1. Status of this document
2. Introduction
3. Key words to indicate requirement levels
4. Changelog of this document
5. General Fidonet URL syntax
5.1. The main parts of URLs
5.1.1. Conformance note
5.1.2. Delimiter guidelines
5.2. URL character encoding
5.2.1. Encoding of original characters
5.2.2. Encoding of octets
5.2.2.1. No corresponding graphic 7-bit character
5.2.2.2. Unsafe characters
5.2.2.3. Reserved characters
5.2.2.3.1 Using domain suffixes in areatags
5.2.2.4. The plus ("+") and the encoding of white spaces
5.2.2.4.1. Specificity note
5.2.2.4.2. Internet practice note
5.2.2.5. URLs that span several lines of text in Fidonet
5.3. Parsing the scheme-specific part of URL
5.3.1. Dealing with inappropriate reserved characters
6. Fidonet URL schemes designating actions
6.1. "netmail:" scheme
6.1.1. Optional parameter "to"
6.1.2. Optional parameter "subject"
6.1.3. Optional parameter "subj"
6.1.4. Optional parameter "from"
6.1.5. Optional parameter "body"
6.2. "areafix:" scheme
6.2.1. Optional parameter "uplink"
6.2.2. Optional parameters "unsubscribe" and "leave"
6.2.3. Future optional parameters
6.2.4. Relative "areafix:" URLs
6.3. "echomail:" scheme
6.3.1. Optional parameter "to"
6.3.2. Optional parameter "subject"
6.3.3. Optional parameter "subj"
6.3.4. Optional parameter "from"
6.3.5. Optional parameter "body"
7. Fidonet URL schemes designating objects
7.1. The <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.
5.1.2. Delimiter guidelines
-+-------------------------
In current Internet practice they distinguish between delimiters
":" and "://". The delimiter "://" is often used after scheme
names that designate objects and resources ("http://", "ftp://",
"gopher://", "nntp://", "ed2k://", "file://", etc.).
The delimiter ":" is often used after scheme names that
designate actions (e.g. "mailto:", "skype:").
The same difference exists between Fidonet resources (objects)
and actions. That's why, though these delimiters MUST always
be interpreted as equivalent, it is still RECOMMENDED that ":"
SHOULD be used after schemes that designate actions ("netmail:",
"echomail:", "areafix:") and "://" SHOULD be used after schemes
that designate resources ("area://", "freq://", "fecho://",
"faqserv://", etc.).
5.2. URL character encoding
-+-------------------------
URLs are sequences of characters (i.e., letters, digits, and/or
special characters). URLs may be represented in a variety of ways:
e.g., ink on paper, or a sequence of octets in a coded character
set. The interpretation of URL depends only on the identity of the
characters used.
It is useful to distinguish between a "character" (distinguishable
semantic entity) and an "octet" (an 8-bit byte).
In most URL schemes, the character sequences in different parts
of a URL are used to represent sequences of octets used in Fidonet
services. For example, in the "netmail:" scheme, the Fidonet
address, netmail subject and addressee name are such sequences of
octets, represented by parts of the URL. That sequences of octets,
in turn, represent the original characters (of subject line, or of
sysop's name, etc.); each original character is represented by one
or more octets.
So there are always two mappings, one from URL characters to
octets, and the second from octets to original characters:
URL character sequence<->octet sequence<->original character sequence
5.2.1. Encoding of original characters
-+------------------------------------
The following paragraph is informative.
The sequence of octets defined by a component of the URL
is subsequently used to represent a sequence of original
characters. That process could have a very volatile nature.
Being an international network, Fidonet always needs to deal
with hundreds of national characters, with dozens of available
encoding traditions and character sets. There is a number of
FSC (Fidonet Standard Proposal documents) suggesting several
kludge-based methods to define which character set is used.
However, it is not wise to implement any equivalents to kludges
as a required part of every Fidonet URL; and it could be hard to
mantain complete lists of all possible character sets inside all
programs interpreting Fidonet URLs. (Remember, it should be also
made possible for Fidonet URLs to appear and be well interpreted
in traditional HTML hypertext environment of the Web, Internet
e-mail, instant messaging, etc.) That's why only one encoding,
with large enough character set, has to be chosen.
The following paragraphs of this subsection are normative.
The sequence of octets used in Fidonet URLs MUST always contain
UTF-8 encoded representation of original characters.
ISO/IEC 10646-1 defines a multi-octet character set called the
Universal Character Set (UCS), which encompasses most of the
world's writing systems. And UTF-8, one of a few so-called UCS
transformation formats (UTF), preserves the 7-bit ASCII range,
thus providing some compatibility with file systems, parsers and
other software elements that rely on 7-bit ASCII values but are
transparent to other values.
UTF-8 is defined in RFC 2279. Its description can also be found
in Unicode Technical Report #4 and in the Unicode Standard,
version 2.0.
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 203. I will not employ an evil wizard if he has a sleazy mustache.
--- Orcs are near, All! My Golded 1.1.5-b20060515 is gleaming!..
* Origin: I have a strange feeling, as if I already had a deja vu (2:5063/88)
|