As per Relevance of the word september, we have this rfc below:

---

---------


< INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;;





RFC 874 September 1982
M82-50







A CRITIQUE OF X.25





















M.A.
THE MITRE
Bedford, Massachusetts










The widely touted network interface protocol, "X.25",
its attendant conceptual framework, the International
Organization's Reference Model for Open System
(ISORM), are analyzed and found wanting. The paper is
companion piece to M82-48, and M82-51.











































i




A CRITIQUE OF X.25

M. A.






According to some sources, the International
Organization's (ISO) "Open System Interconnection" (OSI)
has adopted the International Consultative Committee on
and Telegraphy (CCITT) developed X.25 protocol(s) as its
1-3. ("Loose constructionists" of the ISORM would hold that X.25
is a mechanization of L1-L3 rather than the mechanization, and
least one British source holds that "we in the U.K. don't
that ISO have adopted X.25.") In the U.S. Government arena
where the author spends much of his time, the
Accounting Office (GAO) has suggested that the Department
Defense (DoD) ought to consider adopting "X.25 networks,"
apparently in preference to networks based on protocols
by the DoD-sponsored intercomputer networking research community
That intercomputer networking research community in turn has
with a few recent exceptions, adhered to its commitment to
Oral Tradition and not taken up the cudgels against X.25 in
open literature, even though X.25 is an object of
scorn in personal communications

Although the DoD Protocol Standards Technical Panel
begun to evolve a "Reference Model" different from ISO's
reasons which will be touched on below, there seems to be a
to address the deficiencies of X.25 on their own demerits as
as possible. Without pretending to completeness*, this paper
attempt to do just that

The overall intent is to deal with X.25 in the abstract
because of who pays the bills, though, a necessary preliminary
to at least sketch the broad reasons why the DoD in
should

________________
* Various versions of X.25 and ISO documentation were employed
one incompleteness of note, however, is that no attempt
been made to do proper bibliographic citation.
incompleteness lies in the area of "tutoriality"; that is
appropriate prior knowledge is assumed on the part of
reader. (The author apologizes for the omissions but hasn'
the time or the energy to be overly scholarly. Reference [3]
might be of use to the reader who feels slighted.)





1
RFC 874 September 1982


employ intercomputer networks which base their protocol suites
the ISO Reference Model (ISORM) with X.25 as Levels 1-3. (
that this is a different formulation from "use
subnetworks which present an X.25 interface.") Very briefly,
DoD has concerns with "survivability," reliability, security
investment in prior art (i.e., its research community has
working protocol suite in place on many different
systems), procurability (i.e., ISORM-related protocol suites
not as yet fully exist even on paper and the
standardization process is acknowledged even by its advocates
require several years to arrive at full suite specification,
less offer available interoperable implementation),
interoperability with a much wider range of systems than are
likely to receive vendor-supplied implementations of
protocol suites. Regardless of which particular concerns
considered to dominate, the DoD cannot be expected to
events in the ISO arena. (Particularly striking is the fact
DoD representatives are not even permitted under current
to present their specific concerns in the area of security in
sort of unclassified environment the ISO arena constitutes.)

Some zealous ISORM advocates have suggested that the
research community suffers from a "Not Invented Here"
with respect to ISORM-related protocols, though, so even if
various reasons just cited were to prevail, there would still
an open issue at some level. At least one or two zealous
of the research community have asserted that the problem is
Not Invented Here, but Not Invented Right, so an assessment
the apparent keystone of the ISORM suite, X.25, from
perspective of whether it's "good art" ought to be appropriate
That's what we're up to here
























2
RFC 874 September 1982


Problems With the Conceptual Model

There is confusion even amongst its advocates as to the
conceptual model of X.25-based ISO networking. Some draw
Reference Model as two "highrises," others draw "
garages" beside each highrise. That is, some draw the
ISORM layers in large rectangles (representing Hosts) next to
another, showing each layer in communication with its "peer"
the other Host/Open System; this implies an "end-to-end" view
X.25. Others draw smaller rectangles between the larger ones
with Levels 1-3 having peer relationships from the Host-OS ("
Terminal Equipment") to the Comm Subnet Node ("Data
Terminating Equipment"); this implies a "link-by-link" view
X.25. This ambiguity does not engender confidence in
architects, but perhaps the real problem is with the spectators
Yet it is indisputable that when internetting with X.75,
model becomes "hop-by-hop" (and it is likely it's meant to
link-by-link even on a single comm subnet).

A major problem with such a model is that the designers
chosen to construe it as requiring them to break the "
circuit" it is supposed to be supporting whenever there
difficulty with any one of the links. Thus, if internetting,
on some interpretations even on one's proximate net, rerouting
messages will not occur when needed, and all the upper levels
protocols will have to expend space-time resources
reconstituting their own connections with their counterparts
(Note that the success of the reconstitution under DCE
appears to assume a certain flexibility in routing which is
guaranteed by the Model.) This can scarcely be deemed
design practice for an intercomputer networking environment
although many have conjectured that it probably makes sense
telephonists

________________
* Note that we are assuming an ISO-oriented model rather than
CCITT-oriented one (X.25/X.28/X.29) because the latter
to offer only "remote access" functionality whereas the
of intercomputer networking we are interested in is
with the full "resource-sharing" functionality the former
striving for. This might be somewhat unfair to X.25, in
it is taking the protocol(s) somewhat out of context; however
it is what ISO has done before us, and if what we're
accomplishing is a demonstration that ISO has erred in
doing, so be it. As a matter of fact, it can also be
that X.25 is itself somewhat unfair--to its users, who
expecting real networking and getting only communication; cf
Padlipsky, M. A., "The Elements of Networking Style", M81-41,
The MITRE Corporation, October 1981, for more on the
important topic of resource sharing vs. remote access





3
RFC 874 September 1982


Indeed, it appears the virtual circuit metaphor is in
sense being taken almost literally (with the emphasis on
"circuit" aspect), in that what should be an environment
confers the benefits of packet-switching is, at the X.25 level
reduced to one with the limitations of circuit-switching. On
other hand, the metaphor is not being taken literally enough
some other sense (with the emphasis on the "virtual" aspect),
many construe it to imply that the logical connection
represents is "only as strong as a wire." Whether the
problem stems from the desire to "save bits" by not
addresses explicitly available on a per-transmission basis
conjectural, but if such be the case it is also unfortunate

(As an aside, it should be noted that there is some
that bit saving reaches fetish--if not pathological--
in X.25: For instance, there does not even appear to be a
Type field in data packets; rather--as best we can determine--
data packets the low order bit of the "P(R)" field,
overlaps/stands in the place of the Packet Type is always 0,
whereas in "real" Packet Type fields it's always 1. [That may
by the way, not even be the way they do it--it's hard to tell ...
or care.])

There is also confusion even amongst its advocates as
what implications, if any, the protocol(s) has (have) for
subnet node to comm subnet node (CSN) processing. Those who
just two highrises seem to be implying that from
perspective the CSN (or "DCE") is invisible. This might make
certain amount of sense if they did not assert that each floor
a highrise has a "peer-relationship" with the corresponding
of the other highrise--for to do so implies excessively
wires, well beyond the state of the wire-drawing art, when
notices that the first floor is the physical level. (It
appears to disallow the existence of concatenated comm
into an internet, or "catenet," unless the CSN's are
identically constituted. And those who hold that the
dictates single protocols at each level will have a hard
making an HDLC interface into a Packet Radio Net, in
probability.)

Those who, on the other hand, "draw parking garages,"
to be dictating that the internal structure of the CSN
adhere to X.25 link and physical protocols. This implies
Packet Radio or satellite CSNs, for example, cannot "be X.25."
Now that might be heartening news to the designers of such
subnets, but it presumably wasn't intended by those who
universality for X.25--or even for the ISO Reference Model








4
RFC 874 September 1982


Even granting that ambiguities in the conceptual model
not constitute prima facie grounds for rejecting the protocol(s),
it is important to note that they almost assuredly will lead
vendor implementations based on differing interpretations
will not interoperate properly. And the unambiguous position
virtual circuits are broken whenever X.25 says so constitutes
flaw at least as grave as any of the ambiguities

Another, in our view extremely severe, shortcoming of
X.25 conceptual model is that it fails to address how
that interpret its protocol(s) are to be integrated into
containing operating systems. (This goes beyond the
of the X.25 specifications in this area, for even the
of the ISORM--who, by hypothesis at least, have adopted X.25
their Levels 1-3--are reticent on the topic in their literature.)
Yet, if higher level protocols are to be based on X.25,
must be commonality of integration of X.25 modules with
systems at least in certain aspects. The most important
that comes to mind is the necessity for "out-of-band signals"
take place. Yet if there is no awareness of that sort of
reflected in the X.25 protocol's specification, implementers
not insert X.25 modules into their operating systems in such
fashion as to let the higher level protocols function
when/if an X.25 Interrupt packet arrives

Yet much of the problem with the conceptual model might
out to stem from our own misunderstandings, or
misunderstandings of others. After all, it's not easy to infer
philosophy from a specification. (Nor, when it comes
recognizing data packets, is it easy even to infer
specification--but it might well say something somewhere on
particular point which we simply overlooked in our desire to
the spec back on the shelf rapidly.) What other aspects of X.25
appear to be "bad art"?

"Personality Problems

When viewed from a functionality perspective, X.25
to be rather schizophrenic, in the sense that sometimes
presents a deceptively end-to-end "personality" (indeed,
are many who think it is usable as an integral Host-Host,
Transport, and network interface protocol, despite the fact
its specification itself--at least in the CCITT "Fascicle
version--points out several functional omissions where
higher-level protocol is expected--and we have even spoken to
or two people who say they actually do -- use it as an end-to-
protocol, regardless); sometimes it presents a comm
network interface personality (which all would agree it must);
and sometimes (according to some observers) it presents






5
RFC 874 September 1982


"Host-Front End Protocol" personality. Not to push the "bad art
methaphor too hard, but this sort of violation of "the Unities
is, if demonstrable, grounds for censure not only to
critics but also to those who believe in Layering. Let's look
the evidence for the split-personality claim

X.25 is not (and should not be) an "end-to-end" protocol
the sense of a Transport or Host-to-Host protocol. Yet it
several end-to-end features. These add to the space-time
of implementation (i.e., consume "core" and CPU cycles)
reflect badly on the skill of its designers if one believes
the design principles of Layering and Least Mechanism. (
of end-to-end mechanisms are cited below, as
superfluous to the network interface role.) The absence of
datagram mode which is both required and "proper" (e.g., not
Controlled, not Delivery Confirmed, not Non-delivery mechanized
may also be taken as evidence that the end-to-end view is
strong in X.25. That is, in ISO Reference Model (ISORM) terms
even though X.25 "is" L1-3, it has delusions of L4-ness;
ARPANET Reference Model (ARM) terms, even though X.25 could "be
L I, it has delusions of L II-ness.*

X.25 is at least meant to specify an interface between
Host (or "DTE") and a comm subnet processor (or "DCE"),
regardless of the ambiguity of the conceptual model about
it constrains the CSNP "on the network side." (Aside:
ambiguity probably reflects even more badly on certain X.25
advocates than it does on the designers, for there is a
sense in which "of course it can't" is the only
answer to the question of whether it is meant to
generic CSN processors (CSNP's) in the general case. Note
though, that it might well be meant to constrain specific DCE's
that is, it started life as a protocol for PTT's--or Postal
Telephone, and Telegraph monopolies--and they are
entitled to constrain themselves all they want.) Yet
end-to-end features alluded to above are redundant to
interfacing role, and, as noted, extraneous features
space-time consequences. There are also several features which
though not end-to-end, seem superfluous to a "tight"
protocol. Further, the reluctance of the designers
incorporate a proper "datagram" capability in the protocol (
they've got doesn't seem to

________________
* For more on the ARM, see Padlipsky, M. A., "A Perspective
the ARPANET Reference Model", M82-47, The MITRE Corporation
September 1982; also available in Proc. INFOCOM '83. (
light may also be cast by the paper on the earlier-
topic of Who Invented What.)






6
RFC 874 September 1982


usable as a "pure"--i.e., uncontrolled at L3 but usable
superfluous overheard by L4--datagram, but instead
delivery confirmation traffic like it or not; note that "seem"
used advisedly: as usual, it's not easy to interpret
Fascicle) suggests at least that they were confused about
higher-level protocols need from interfaces to CSNP's, and
worst that there is some merit to the suggestion that,
paraphrase Louis Pouzin, "the PTT's are just trying to drum
more business for themselves by forcing you to take more
than you need."

Examples of mechanisms superfluous to the interface role

1. The presence of a DTE-DTE Flow Control mechanism

2. The presence of an "interrupt procedure" involving
remote DTE

3. The presence of "Call user data" as an end-to-end
(i.e., as "more" than IP's Protocol field).

4. The "D bit" (unless construed strictly as a "RFNM"
the remote DCE).

5. The "Q bit" (which we find nearly incomprehensible,
which is stated to have meaning of some sort
X.29--i.e., to at least violate Layering by having
higher-level protocol depend on a lower
machanism--and hence can't be strictly a
interface mechanism).

























7
RFC 874 September 1982


The final "personality problem" of X.25 is that some of
advocates claim it can and should be used as if it were
Host-Front End protocol.* Yet if such use were intended,
its designers would have offered a means of
between control information destined for the
implementation of the relevant protocols and data to
transmitted through X.25, but there is no evidence of
mechanisms in the protocol. "Borrowing" a Packet Type id
H-FP would be risky, as the spec is subject to
alteration. Using some fictitious DTE address to indicate
proximate DCE is also risky, for the same reason. Further,
"Call user data" to "talk to" the counterpart H-FP module
only 15 octets (plus, presumably, the 6 spare bits in the 16
octet) for the conversation, whereas various TCP and IP
might require many more octets than that. Granted that
sufficient ingenuity--or even by the simple expedient
conveying the entire H-FP as data (i.e., using X.25 only to
channels to demultiplex on, and DTE-DCE flow control, with
"DCE" actually being an Outboard Processing Environment that
its commands in the data fields of X.25 data packets)--X.25
be used to "get at" outboard protocol interpreters, but
failure to address the issue explicitly again reflects badly
its designers' grasp of intercomputer networking issues
(Another possibility is that the whole H-FP notion stems from
use of X.25 as a Host-

________________
* That is, as a distributed processing mechanism which
Host operating systems to be relieved of the burden
interpreting higher level protocols "inboard" of themselves
virtue of allowing Host processes to manipulate "outboard
interpreters of the protocols on their behalf. Note that
outboarding may be to a separate Front-End processor or to
CSNP itself. (The latter is likely to be found
microprocessor-based LAN "BIU's.") Note also that
dealing with "process-level" protocols (ARM L III
approximately ISORM L5-7), only part of the functionality
outboarded (e.g., there must be some Host-resident code
interface with the native File System for a File
Protocol) and even when outboarding Host-Host protocols (ARM
II; approximately ISORM L4 plus some of 5) the association
logical connections (or "sockets") with processes must
performed inboard--which is why, by the way, it's annoying
find ISO L5 below ISO L6: because, that is, you'd like
outboard "Presentation" functionality but its protocol
to interact with the "Session" protocol, the functionality
which can't be outboarded. (Although this approach, not
proper context for a full treatment of the H-FP approach,
is also of interest that the approach can effectively
the Host from changes in the protocol suite, which can be
major advantage in some environments.)




8
RFC 874 September 1982


protocol so that some might think of it in its Host aspect
"simply" a way of getting at the H-HP. This interpretation
give rise to the interesting observation that DCE's seem to
a protocol as strong as TCP amongst themselves, but doesn'
strike the author as particularly convincing evidence for
X.25 as anything like a proper H-FP--if for no other reason
that a central premise of Outboard Processing is that
Host-side H-FP module must be compact relative to an
generic Network Control Program.)

X.25, then, is rather schizophrenic: It exceeds its
as an interface protocol by pretending to be end-to-
(Host-Host) in some respects; it is by no means a full end-to-
protocol (its spec very properly insists on that point on
occasions); it's at once too full and too shallow to be a
interface; and it's poorly structured to be treated as if it
"just" an H-FP. (Some would phrase the foregoing as "It'
extremely ill layered"; we wouldn't argue.)

A Note on "Gateways"*

Although it was at least implied in the discussion
conceptual model problems, one aspect of X.25/X.75
is sufficiently significant to deserve a section of its own:
only does the link-by-link approach taken by CCITT make
unlikely that alternate routing can take place, but it is
the case that ARPANET Internet Protocol (IP) based
not only permits alternate routing but also could alt-route
an "X.25 Subnet." That is, in IP's conceptual model,
attach to two or more comm subnets "as if they (the Gateways
were Hosts." This means that they interpret the
Host-comm subnet processor protocol of whatever comm
they're attached to, giving as the "proximate net address" of
given transmission either the ultimate (internet addressed
destination or the address of another Gateway "in the
direction." And an implementation of IP can certainly employ
implementation of ("DTE") X.25 to get a proximate net, so ...
least "in an emergency" X.25 interface presenting Public
Networks can indeed carry IP traffic. (Note also that only
proximate net's header has to be readable by the nodal
of/on the proximate net, so if some appropriate steps were
to render the data portion of such transmissions
to the nodal processors, so much the better.)

________________
* This section was added to address the ill-founded concerns
several ISORMites that "TCP/IP won't let you use Public
Nets in emergencies."







9
RFC 874 September 1982


(Further evidence that X.75 internetting is undesirable
found in the fact that the U.S. National Bureau of Standards has
despite its nominal adoption of the ISORM, inserted IP
approximately L3.5 in its version of the Reference Model.)

The Off-Blue

Although touched on earlier, and not treatable at
length in the present context, the topic of security
separate mention. We are familiar with one reference in the
literature [1] which appears to make a rather striking
about the utility of X.25 in a secure network. Dr. Kent's
that the very field sizes of X.25 are not acceptable from
point of view of encryption devices would, if correct (and we
neither competent to assess that, nor in a position to even if
were), almost disqualify X.25 a priori for use in many arenas
Clearly, uncertified "DCE's" cannot be permitted to
classified (or even "private") data and so must be "
around," after all

It would probably be the case, if we understand Dr. Kent'
point, that X.25 could be changed appropriately--if
specifiers were willing to go along. But this is only
problem out of a potentially large number of problems, and
returning briefly to our concern with the interplay of X.25
the DoD, those persons in the DoD who know best what the
are and/or could be are debarred from discussing them with
specifiers of X.25. Perhaps a sufficiently zealous
advocate would be willing to suggest that Professor Kuo'
publisher be subsidized to come out with a new edition whenever
problem arises so that if Dr. Kent happens to spot it
can continue to be taken of his ability to write for the
literature--but we certainly hope and trust that no
would be so tone-deaf as to fail to recognize the
of that suggestion

In short, it appears to be difficult to dispute
assertion that whatever sort of security blanket X.25
represent would at best be an off shade of blue

Space-Time

Another topic touched on earlier which deserves
mention, if only to collect the scattered data in a
section, is that of what have been called space-
considerations. That is, we are concerned about how well X.25
particular and the ISORM-derived protocols in general
implement, both in terms of size of protocol interpreters (PI's
and in terms of execution and delay times






10
RFC 874 September 1982


On the space heading, certainly the fact that X.25
more functionality in its end-to-end guise than is required
fulfill its network interface role suggests that X.25 PI's
be bigger than they need be. As an aside--but a striking one--
should be noted that X.25's end-to-end functions are at
with the ISORM itself, for the "peer entity" of a DTE X.25
must surely be the local DCE X.25. Perhaps a later version
the ISORM will introduce the polypeer and give rise to a
new round of Layering-Theologic controversy.* Speaking of
ISORM itself, those who hold that each layer must be traversed
each transmission are implicitly requiring that space (and time
be expended in the Session and Presentation Levels even
applications that have no need of their services. The Well-
Socket concept of the ARM's primary Host-Host protocol,
Transmission Control Protocol (TCP), lets Session
be avoided for many applications, on the other hand--unless
L5 is to usurp the Host's user identification/authentication
at some point. (Yes, we've heard the rumors that "null layers
might be introduced into the ISORM; no, we don't want to get
the theology of that either.)

On the time heading, X.25's virtual circuit view can
debilitating--or even crippling--to applications such
Packetized Speech where prompt delivery is preferred over
or even reliable delivery. (Some hold that the X.25
option will remedy that; others hold that it's not "
datagrams"; we note the concern, agree with the others, and
on.) Speaking of reliable delivery, as noted earlier
observers hold that in order to present an acceptable
circuit X.25 must have a protocol as strong as TCP "beneath
itself; again, we're in sympathy with them. Shifting focus
to the ISORM itself, it must be noted that the principle
"N-entities" must communicate with one another even in the
Host via "N-1 entities" even in the same Host is an over-
application of the Principle of Layering that must consume
time in the interpreting of the N-1 protocol than would a
interface between N-level PI's or such process-level protocols
FTP and Telnet, as is done in the ARPANET-derived model

Other space-time deficiencies could be adduced, but
a shortcut will suffice. There is a Law of
(attributed to Sutherland) to the effect that "Programs are
waffles: you should always throw the first one out."
relevance should

________________
* And perhaps we now know why some just draw the highrises








11
RFC 874 September 1982


clear when it is realized that (with the possible exception
X.25) ISORM PI's are in general either first implementations
not even implemented yet (thus, the batter, as it were, is
being mixed). Contrast this with the iterations
ARPANET-derived PI's--and, for that matter, protocols--have
through over the years and the grounds for our concern
X.25/ISORM space-time inefficiency become clear irrespective
corroborative detail. Factor in the consideration that space-
efficiency may be viewed as contrary to the corporate
of the progenitors of X.25 ("the PTT's") and at least the
favorite for ISORM Level 4 (ECMA--the European
Manufacturers' Association), and it should become clear why
insist that space-time considerations be given separate
even though touched upon elsewhere.*

Getting

Still another area of concern over X.25 is that it
only one means of attaching a "DTE" to a "DCE." That is,
references to "the X.25 protocol(s)" were not
errors. Most of the time, "X.25" refers to ISORM Level 3;
actually, though, the term subsumes L2 and L1 as well. Indeed
the lowest levels constitute particular bit serial interfaces
This is all very well for interfacing to "Public Data Nets
(again, it must be recalled that X.25's roots are in CCITT),
is scarcely appropriate to environments where the
subnetwork may consist of geosynchronous communications
channels, "Packet Radios," or whatever. Indeed, even
conventional Local Area Networks it is often the case that
Direct Memory Access arrangement is desired so as to
bottlenecking--but DMA isn't HDLC, and the "vendor supported X.25
interface" so prized by some won't be DMA either, one imagines
(Speaking of LAN's, at least the evolving standard in
arena--"IEEE 802"--apparently will offer multiple
interfaces depending on comm subnet style [although there is
disagreement on this point amongst readers of their draft specs];
we understand, however, that their Level 2 shares X.25's end-
aspirations--and we haven't checked up on DMA capability.) X.25,
then, imposes constraints upon its users with regard to
technology that are inappropriate

________________
* The broad issue of design team composition is amplified
Padlipsky, M. A., "The Illusion of Vendor Support", M82-49,
The MITRE Corporation, September 1982.










12
RFC 874 September 1982


Other Observers'

This paper owes much to conversations with a number
people, although the interpretations of their concerns are
author's responsibility. Mention should be made, however, of
few recent documents in the area: The Defense
Agency (DCA Code J110) has sent a coordinated DoD position [2]
NBS holding that X.25 cannot be the DoD's sole network
standard; Dr. Vinton Cerf of the ARPA Information
Technology Office made a contribution to the former
contains a particularly lucid exposition of the desirability
proper "datagram" capability in DoD comm subnets [3]; Mr.
McFarland of the DoD Computer Security Evaluation Center has
explored the limitations of X.25 [4]. Whether because
authors are inherently more tactful than the present author,
whether their positions are more constraining, or even
they have been more insulated from and hence less provoked
uninformed ISORMite zealots, none has seen fit to address
"quality" of X.25. That this paper chooses to do so may
attributed to any one of a number of reasons, but the
believes the key reason is contained in the following



X.25 is not a good thing



[1] Kent, S. T., "Security in Computer Networks," in Kuo, F.,
Ed., Protocols and Techniques for Data
Networks, Prentice-Hall, 1981, pp. 369-432.

[2] Letter to NBS from P. S. Selvaggi, Chief,
and Standards Office, 7 April 1982.

[3] Cerf, V. G., "Draft DoD Position Regarding X.25" in
letter to P. S. Selvaggi

[4] Personal communications

---

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.



RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX

---