Text 1054, 360 rader
Skriven 2007-10-14 00:32:00 av Mithgol the Webmaster (2:5063/88)
Ärende: [5/11] FidoURL.txt
==========================
* originally in FTSC_Public
* also sent to GanjaNet.Local
* also sent to Ru.Fido.WWW
* also sent to Ru.FTN.Develop
* also sent to SU.FidoTech
* also sent to Titanic.Best
textsection 5 of 11 of file FidoURL.txt
textbegin.section
7.1.2. Dealing with unknown containers
-+------------------------------------
Sometimes an <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.
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 66. My security keypad will actually be a fingerprint scanner.
--- Orcs are near! My Golded 1.1.5-b20060515 is gleaming!..
* Origin: Be careful, the paranoid ones are always wathing you!.. (2:5063/88)
|