Text 1058, 385 rader
Skriven 2007-10-14 00:40:52 av Mithgol the Webmaster (2:5063/88)
Ärende: [9/11] FidoURL.txt
==========================
* originally in FTSC_Public
* also sent to GanjaNet.Local
* also sent to Ru.Fido.WWW
* also sent to Ru.FTN.Develop
* also sent to SU.FidoTech
* also sent to Titanic.Best
textsection 9 of 11 of file FidoURL.txt
textbegin.section
7.2.1.5.4. Coordinates in nodelists and pointlists
-+------------------------------------------------
It is NOT RECOMMENDED for sysops and points of Fidonet
to imbue each message of their own echomail with GEO kludges
of the sender's usual geographical location (as opposed to
the coordinates of a place mentioned or photoghraphed or
otherwise referenced in the message that contains these
coordinates). The location of the sender (a sysop or a point
of Fidonet) SHOULD be announed only once, by flying the
corresponding user flags in the nodelist or in a pointlist.
Such a flags, if used, MUST conform to the section 6
('Userflags') of FTS-5001; in particular, they MAY contain
any alphanumeric character except blanks. The decimal dot
(the character ".") is probably not alphanumeric, so it MUST
be avoided, and the boundary between the integral and the
fractional parts of a decimal numeral is not marked in the
degree values of the following flags.
The LONE or LONW flag represents the location east or west
of the prime meridian, respectively. The longitude value
immediately follows the flag; the decimal dot is assumed
after the third digit; the value MUST be preceded by some
zero-padding if the integral part of the longitude is
actually lesser than three digits.
Example:
LONE03805
(This flag means 38.05 degrees to the east of the prime
meridian.)
The LATN or LATS flag represents the location north or south
of the equator, respectively. The latitude value immediately
follows the flag; the decimal dot is assumed after the
second digit; the value MUST be preceded by a zero if the
integral part of the latitude is actually lesser than two
digits.
Example:
LATN4457
(This flag means 44.57 degrees to the north of the
equator.)
The constraints enumerated in section 7.2.1.5.4 are all in
effect: the Greenwich meridian MUST be used, the WGS84 geoid
SHOULD be used, the decimal degree values MUST be used.
Example of a nodelist line:
,88,FGHI_Global_Headlight_Ignited,Gelendzhik,
Sergey_Sokoloff,00-00-000000,300,IBN:1978,
INA:Fidonet.Mithgol.Ru,U,TSU,LATN4457,LONE03805
Sysops and network coordinators SHOULD carefully avoid
giving out the exact coordinates of Fidonet stations, due to
the substantial loss of privacy it causes. The flags SHOULD
rather contain only the coordinates that correspond to the
primary local location (town, suburb, city, etc.) that is
given out in Field 4 of the same line (see section 5.3 of
FTS-5000); two digits in the fractional part of the value
(after the assumed dot) ought to be enough for everyone.
7.2.1.5.5. Filters of "geomark" type
-+----------------------------------
The "geomark" filter's value contains the four coourdinate
constraints in <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.6. 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 at least one (i.e. one or more) of the following
requirements are met:
1) The message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
coordinate flags of this line (see section 7.2.1.5.4)
correspond to a place on the Earth (a dot on the map)
that belongs to the region defined by the filter's
value.
2) The message originates from an address that corresponds
to a line in the nodelist or in the pointlist, and the
line has no coordinate flags (see section 7.2.1.5.4),
but the primary local location (town, suburb, city,
etc.) that is given out in Field 4 of the same line
(see section 5.3 of FTS-5000) belongs to the region
defined by the filter's value.
The second of these requirements fails if the URL parser
is not capable of geocoding, or if the location is not
known to the parser. Fidonet sysops and points SHOULD use
coordinate flags (defined in section 7.2.1.5.4) to ensure
that their echomail messages are correctly processed by
filters of "geofrom" type.
If several "geofrom" filters are present in the
<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. 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.
7.2.3. Regular expressions
-+------------------------
It is possible for an optional parameter of an area URL
to contain a regular expression. In section 7.2.1.4 a regex
is used to specify the designated message(s); in section 7.2.4.1
a regex defines whether a kludge is visible.
The language of regular expressions has several dirrerent
dialects. Perl Compatible Regular Expressions (PCRE) are chosen
here as the RECOMMENDED; that's because PCRE engine has a rich
set of features, and because the engine is already embedded in
ECMAScript-compatible browsers of the modern Web.
The language of regular expressions is far beyond the scope of
this document. The article http://en.wikipedia.org/wiki/PCRE (in
Wikipedia) and the external links referenced there are probably
the best to start learning how to write PCRE regexes.
Some Fidonet browsers have their own JavaScript engines, that
SHOULD conform to the requirements of the ECMA-262 standard,
third edition, section 15.10. (The form and functionality of
its regular expressions is modelled after the regular expression
facility in the Perl 5 programming language.) Any other Fidonet
browsers SHOULD use the PCRE library package, which is an
open source software, written by Philip Hazel, and downloadable
at http://www.pcre.org/
Fidonet gates in the Web SHOULD use either Perl itself, or PCRE
implementation in PHP (preg_grep() function, for example), or
any other suitable PCRE-compatible implementation.
A regular expression in a Fidonet URL MUST always take the form
/pattern/flags
The only possible flag (pattern modifier) in Fidonet URLs is
the letter "i" (if this modifier is set, letters in the pattern
match both upper and lower case letters; in brief, "i" means
ignoring of case).
The regular expression MAY also contain the "m" flag (if this
modifier is set, then the "start of line" and "end of line"
constructs match immediately following or immediately before any
newline in the subject string, respectively, as well as at the
very start and end; in brief, "m" means multi-line mode of
matching). However, even if the "m" letter is absent, this mode
MUST be assumed. So the "m" letter MAY be omitted even if the
corresponding mode is necessary; in kludge matching, for example
(see section 7.2.1.4).
textend.section
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... Software is like sex: it's better when it's free. (Linus Torvalds)
--- Orcs are near, All! My Golded 1.1.5-b20060515 is gleaming!..
* Origin: And the Soviets ÄÄ waist-deep in the snow ÄÄ marched in (2:5063/88)
|