| |
PA2AGA > PACDIG 18.07.00 22:45l 175 Lines 7306 Bytes #-9245 (0) @ EU
BID : PR_2000_170B
Read: GUEST
Subj: PacketRadioDigest 2000/170B
Path: DB0AAB<DB0PV<DB0MRW<DB0ERF<DB0FBB<DB0GOS<DB0PKE<DB0ACH<PI8JOP<PI8ZAA<
PI8HGL
Sent: 000711/2134Z @:PI8HGL.#ZH1.NLD.EU #:61037 [Den Haag] FBB $:PR_2000_170B
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To : PACDIG@EU
Date: Tue, 11 Jul 00 20:51:32 MET
Message-Id: <pr_2000_170B>
From: pa2aga@pe1mvx.ampr.org
To: pr_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B
February 2000 (ISO ALPHA-3 code).
7. Composition of macro geographical (continental) regions and
component geographical regions - revised 16 February 2000.
8. Various documentation collected from packet-radio network
during about a decade as PBBS SysOp.
Foreword:
---------
The following would be a *further* attempt to define the
information that should be placed in the "TO" and the "@"
portions of a message.
These info will help to comprise the HIERARCHIAL ADDRESS
of a message and consequently it concerns with the correct
compilation of forwarding files.
The two types of messages that are discussed here are
PERSONAL and BULLETINS.
If it is a Personal message, the first line that is sent may
look like |
this: +---+-------------- (S)end the (P)ersonal message
| +------- (TO) IK1GKJ
| | +--- distribute to the PBBS IK1MSL
| | | located in Piemonte region
| | | in ITA
| | | in EUROPE
-+ -----+ +-----------------
example 1: SP IK1GKJ @ IK1MSL.IPIE.ITA.EU
----------
Or, if it is a Bulletin, it may look something like this:
|
+-----+------- (S)end a (B)ulletin
| +-- addressed (TO) anyone interested
| | to (AMSAT) informations
| | +- distribute to the geographic
| | | location (Lazio region)
-+ --+-- +---
example 2: SB AMSAT @ ILAZ
----------
In example 1 the message being sent is Personal and needs a
specific GEOGRAPHIC HIERARCHICAL address. The hierarchy of the
address is parsed from right to left and identifies the
location of the station to whom the message is addressed. The
format of that address is as follows:
+---- Send Personal +- AF - Africa
| +- NA - NAmerica
-+ +- SA - SAmerica
SP IK1GKJ @ IK1MSL.IPIE.ITA.EU +- AS - Asia
+----- +----- +--- -+- | +- EU - Europe
| | | | +- CONTINENT -+- OC - Oceania
| | | | (see Note 2)
| | | +-- COUNTRY -----+- PRT - Portugal
| | | (see Note 2) +- ESP - Spain
| | +-- REGION +- FRA - France
| | (see Note 1) +- xxx - yyyyyyy
| +-- DESTINATION PBBS CALLSIGN
+---- ADDRESSEE CALLSIGN
NOTE 1:
-------
In our italian system, the administrative part (and also a
manageable area for packet-radio purposes) wich characterizes
a distinct *geographical area* below the *country area* is
called Region (there are 20 Regions wich, in some instances,
identify also a *call area*) and to wich we can (or *must*)
address the forwarding, in a well defined mode, without any
possible ambiguity of *geographic route*. See Annex 1.
The just done considerations make clear that adding another
field to our r-lines between, PBBS callsign and Region, filled
for example with the abbreviation (numberplate) of our
(italian) 'provinces' (in many instances a consistent number
within each region), prefixed with, or without a '#' sign,
besides being useless (unproductive) as per forwarding rule,
could be lead also (in general) to an incorrect messages
routing.
NOTE 2:
-------
The Country and Continental H designators are *ignored* when
the message is in its particular domain. Example: in a msg
wich originates inside Lazio region and addressed to a
station of the same region, the Nation and Continent
designators (.ITA.EU) will be ignored.
Proposal:
---------
The *general* format, wich could be represent almost all
over the world realities follows:
+---- Send Personal
-+
sp call @ pbbs.region.state.country.continent
(a) (a) (b) (c) (d) (e)
(a) = valid callsigns as defined by local communications
autority.
(b) = may be a 'Region', an 'Area routing number', a
'Sub-region';
*or*
any other 'large' Administrative/Postal district
existing *below* the Country, or *below* the
State/Province areas (as defined into the next (c)
note).
This field *MUST* be defined by each Country.
(c) = the names of 'States' or 'Provinces' into wich some
Countries are subdivided. This field is applicable
*ONLY* for such a systems in wich this situation is
foreseen. Classic situations in wich 'State' or
'Province' applies are, for example: USA 'states',
Canada 'provinces', Mexican 'states', Chinese
'provinces', Brasilian 'states', Australian
'provinces'(?) an so on; for all other countries
this field *must* not exist.
At the risk to be repetitious I guess that, while
the reference to the "State" appear be generally
understood, that for "Province", *not yet*, in
particular, in this context, I would stress the
the concept that we refer to the word "Province" as
that, *exclusively* applicable to those very large
areas as for the above examples and for other
equivalent situations; all other applications are a
very big error.
(d) = the names of 'Countries' or 'Areas' code as per
International Standard ISO 3166-1, Codes for the
representation of names of countries and their
subdivisions-Part 1: Country codes, ISO 3166-1: 1997
(E/F), International Organization on Standardization
(Geneva 1997);
(ST/ESA/STAT/SER.M/49/Rev.4/WWW revised 16 February
2000). See Annex 2.
(e) = the 'Continent' in accordance with 'Composition of
macro geographical (continental) regions and
component of geographical regions' as excerpted from
the United Nations publication in press, also
revised 16 February 2000:
Note: No ISO ALPHA-x code has been foreseen for
Continent's designation into the above
official documentation and others (United
Nations, NATO, EEC, UEO, etc.) as per my own
knowledge.
Code proposed by myself as *standard* for each
To be continued in digest: pr_2000_170C
Read previous mail | Read next mail
| |
