= Сообщение: 2491 из 3030 =================================== GANJANET.LOCAL = От : Mithgol the Webmaster 2:5063/88 14 Oct 07 00:38:52 Кому : All 14 Oct 07 00:38:52 Тема : [9/11] FidoURL.txt FGHI : area://GANJANET.LOCAL?msgid=2:5063/88+47112d8d На : area://GANJANET.LOCAL?msgid=2:5063/88+47112d13 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== * изначально написано в эхоконференцию FTSC_Public * также было отослано в эхоконференцию GanjaNet.Local * также было отослано в эхоконференцию Ru.Fido.WWW * также было отослано в эхоконференцию Ru.FTN.Develop * также было отослано в эхоконференцию SU.FidoTech * также было отослано в эхоконференцию 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.
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.
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.
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.)
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.
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)
