Simtel MSDOS - Coast to Coast/simteldosarchivecoasttocoast2.iso/fido/ftsc_all.z43/FSC-0034.TXT

Text File | 1989-06-14 | 16KB | 331 lines

                        Gateways to and from FidoNet <tm>
              Technical, Administrative, and Policy Considerations
                                    FSC-0034

                             Randy Bush  14 June 89

Copyright 1989, Randy Bush.  All rights reserved.  The right to distribute for
non-commercial use is granted to the FidoNet Technical Standards Committee,
provided that no fee is charged.  This may be posted on FidoNet electronic BBSs
which charge no fee for accessing this document.  Any and all other reproduction
or excerpting requires the explicit written consent of the author.



What is a Gateway to/from FidoNet?
---- -- - ------- ------- --------

A gateway is a collection of software and procedures whereby net mail and/or
echomail may be transferred between FidoNet and another computer communications
network.  Gateways are bi-directional, as folk always want to reply to others'
mail.

Gateways exist now.

  o There are a number of software packages for gating between uucp-based
    systems and FidoNet, the most well-known beingthe UFGATE shareware package.
    These packages gate both netmail and echomail, and are often used to provide
    FidoNet access to/from Internet via the uucp network.  These tend to go
    through much effort to make FidoNet look as much like Internet as possible.
    As of this writing, about 25 uucp gateways are scattered around FidoNet.

  o Rhodes University has developed a complete system between a Cyber-based NOS
    network and FidoNet.  This system handles both net mail and echomail, and is
    also strongly based on the Internet standards, and almost views FidoNet as a
    transport mechanism to get to/from Internet.  It is used to gate a fairly
    localized cluster of mainframes to FidoNet at a single point, and has made
    special arrangements for further routing and forwarding of mail.

  o WWIVnet has developed gating software based on the ForDog package for the
    MS-DOS-based WWIV systems, and some other package for the Mac-based Tabby
    systems.  The MS-DOS system uses Binkley or another FidoNet mailer handles
    the protocol transfers to make the WWIV system look like a FidoNet system to
    other FidoNet nodes.  WWIVnet gates are said to be scattered around the US
    and Canada.

  o A number of FidoNet-based systems have been developed for various flavors of
    UN*X.  These vary from encapsulated Fido-worlds within UN*X (i.e not true
    gates at all), to FidoNet front ends for UN*X mail systems.

  o RBBS-net seems to have developed gateway software for the MS-DOS-based BBS
    network, but I do not know enough to characterize it.

All of these gateway systems can and are being run in a safe and cooperative
fashion, and are providing a nice cross-cultural exchange with benefits for both
sides of the gates.

At this time, there are also other nets which, because they are based on
technology similar to FidoNet, are dumping mail onto and taking mail off of
FidoNet willy nilly, with little thought to the technical, administrative, or
social consequences.  Often, this is done with good intentions, not realizing
they are providing a disservice to both nets.


What are the Characteristics of a Good Gateway?
---- --- --- --------------- -- - ---- --------

Like good contracts, good gateways should be fair to both sides.  There is the
need to preserve both the technical and sociopolitical integrity of all parties
to the transaction.

Technically, both networks will have specifications and requirements for
transfer protocols, message and echomail formats, control data files, etc.
Beyond the borders of the gateway software, each universe should be completely
and safely maintained.

  o Messages and echomail should completely conform in format and content to the
    technical specifications of each side of the gateway.

  o Addressing of messages and echomail should completely conform to that of the
    network in or through which the messages are traveling or resident at all
    times.

  o A normal user should be able to enter new messages destined for the other
    side of the gate and to reply to gated mail with relative ease.

  o If FidoNet uses a network A as an intermediate to get to/from a network B,
    or if network C uses FidoNet to get to/from network D, then the inter-net
    transitions should be auditable, but local customs and technalia of the
    intermediate network may not need always be enforced.  Socially, the customs
    and fashions of each network should be maintained in that network.

  o There must be administrative liaison and control between the two networks so
    agreements may be made and enforced and disputes may be adjudicated.

  o If the networks being gated overlap geographically, then systems should not
    have to pay significant costs to move mail between the two networks when it
    is between two nodes that are in the same general locale.

  o Gating is not simple, technically or administratively.  Unless each net
    anticipates significant use of the gateways, and the anticipated gain is
    seen as greater than the anticipated pain, then one side or the other may
    reasonably decline to do the necessary work.


What Technical Standards Exist?
---- --------- --------- ------

Before we develop new specifications, social protocols, and standards, we should
see what exists already.

  o FidoNet Technical Standards exist already for the data formats and the
    communication protocols for net mail and echomail.  All conforming gateway
    systems mentioned above conform to these standards.  These are named
    FSC-nnnn, or more recently FTS-nnnn.

  o The SRI-NIC has published standards for message formats and communication
    protocols that are used between a significant number of networks that
    already gate to each other.  These are often referred to as the Internet
    standards and named RFCnnnn or IDEAnnnn.

  o The ISO and CCITT have standards for message formats and communication
    protocols which are used between a significant number of systems.  These
    are based on X.nnn specifications, eg. X.400.

Other standards undoubtedly exist and should be investigated by anyone desiring
to build a gateway system.

The game of 'my standard is better than yours' has been played for decades with
no conclusion other then demonstrating the stupidity of war.  What matters is
that each net's standards are maintained within that net.


What Administrative Standards Exist?
---- -------------- --------- ------

Most networks have formed administrative procedures and guidelines which
regulate if and how other networks may gate to/from them.

The most notable exception is the uucp/Usenet which, having no formalized
administrative rules for anything else, imposes none on gateways.  Before we
recoil in horror, note that uucp/Usenet is three to four times the size of
FidoNet, is over twice FidoNet's age, and has a significantly better signal-
to-noise ratio.

The SRI-NIC provides a procedure for registering Internet domains.  A domain is
somewhat like what we are considering a network.  This Internet registration
procedure ensures that the network has
  o administrative responsibility and control, and
  o at least two registered sites which provide address mapping for the netowrk
    being gated.

FidoNet is a registered domain of Internet.  Our domain is called fidonet.org.
The administrative responsibility is the FidoNet IC's.  The registered
'nameservers' are at lynx.cs.orst.edu and k9.cs.orst.edu, both at Oregon State
University, though this is bending the two nameserver policy a bit.

DECNET, ARPANET, ... all have applicable standards, but, as they are strictly
limited to formal commercial relationships, they are of little interest here.


What Administrative Policies are Needed by FidoNet?
---- -------------- -------- --- ------ -- --------

What does FidoNet really need to state in terms of administrative requirements
on a network wishing to gate to/from FidoNet?

FidoNet needs a means of ensuring that a formal relationship exists which may be
used to negotiate technical standards between the two nets, internet
adjudication of disagreements both technical and social, and enforcement of
decisions.  Similarly, the other network will likely want such assurances as
well.  Therefore an agreement should be reached stating:

  o who is administratively responsible,

  o who is technically responsible,

  o what technical and administrative documentation exists, and

  o both parties will abide by eachother's rules when in the other's house, and

  o how grievances are to be stated and adjudicated.

In addition, it will be advisable for FidoNet to place some requirements on a
network wishing to form official gateways.  Some of these requirements and their
motivations are:

  o If the other network geographically overlaps a significant portion of
    FidoNet, then the other net should be of sufficient size that gateways can
    likely be recruited in most areas where the nets overlap.  Thus, systems
    should not have to pay significant costs to move mail between two nets that
    happen to be in the same locale.

  o If the other network geographically overlaps a significant portion of
    FidoNet, then there should, at a minimum, be gateways in each FidoNet zone
    where they overlap.

  o If the other network geographically overlaps more than one zone of FidoNet,
    then that net should have its own gateways between the zones, and not use
    FidoNet to move the burden of interzone PTT costs.

  o If the other network geographically overlaps a significant number of the
    regions in a FidoNet zone, then there should, at a minimum, be gateways in
    each FidoNet region where they overlap.

  o If the other network is geographically localized, then special arrangements
    may be made whereby there traffic is gated to/from FidoNet at one or more
    places by special arrangement as if the other network were a FidoNet node or
    local network (in the intra-FidoNet sense) itself.

  o Gating of net mail, i.e. user-to-user messages, must be implemented and
    easily used.  Gating of Echomail is optional.

  o Mail must be bi-directional.  If someone in the other net can send mail to a
    node/user on FidoNet, then that FidoNet node/user must be able to  reply.

  o If echomail is gated, then, unless special circumstances are recognized by
    the responsible administrators, it must be gated bi-directionally.

  o If a conference is moderated (in the Usenet sense, similar to Dutchie's
    Conference Mail's moderation or GroupMail) on one network, then it should be
    moderated on all other networks, or at least the gateway into the network
    where it is moderated should ensure that correct moderation is done by
    forwarding or whatever is appropriate.

For inter-net gateway systems in the process of formation, it is assumed that
some of the above requirements may be waived during a startup period at the
discretion of the administrative bodies.

Observe that if FidoNet were to try to take a shortcut which has been suggested
and simply require Intetnet registration of gating networks, then, of the
current networks gating to FidoNet correctly (see above), only the Rhodes system
could conform technically.  Eg. the uucp gating packages gate to uucp which has
no administrative center and is not registered with Internet.  To require
Internet registration would further neither the goals of Internet, nets wishing
to gate to FidoNet, nor FidoNet itself.


What Technical Requirements should FidoNet Place on Gating Systems?
---- --------- ------------ ------ ------- ----- -- ------ --------

Each network will have its own specifications for communication protocols, data
formats, message conventions, addressing, etc.  Though more generally used
standards are to be preferred, what really matters is that each net be self-
consistent and integritous and that gateway systems maintain that integrity.

From the FidoNet perspective, the following attributes of a gateway system seem
to be mandatory.

  o Conformance to FidoNet message format as specified in current FidoNet
    technical standards (eg. currently FSC-0001) must be maintained while
    messages are within FidoNet.

  o Information to assist message comprehension and processing by gateway
    systems and/or other networks may be contained within the message body,
    either hidden behind ^A lines or not.  If such information is needed, then
    conformance to current Internet standards (eg. currently RFC822) is
    recommended.

  o The FidoNet message header must contain valid FidoNet addresses at all times
    the message is on FidoNet.  Valid FidoNet addresses are addresses of
    specific FidoNet nodes in the current FidoNet nodelist.

  o The source and/or destination address in the other net should be embedded in
    the text body of the FidoNet message, either hidden behind ^A lines or not.
    Conformance to current Internet standards is recommended where appropriate,
    but addressing conventions in the other net may preclude this.

  o A message must contain sufficient information that the originating system
    and user may be easily determined.

  o A FidoNet sysop and/or normal FidoNet BBS user should be able to enter
    messages destined for users in the other network and reply to gated mail
    using current FidoNet software.

  o If echomail is gated, then the echo messages should conform to all current
    FidoNet standards for echomail.  For example, currently an echomail message
    should:
    - have a correct tear line
    - have an origin line of the proper format with a FidoNet origin of the
      gating FidoNet node
    - have seenbys of only FidoNet nodes
    - have a path line that goes back at least to the gating node

  o If echomail is gated, then an echomail message must contain sufficient
    information that the system and user of origin may be trivially
    determined, whatever net may have originated it.

  o The origin of gated echomail should be determinable in a regular way
    sufficient that the gating software can provide easy construction of
    private net mail replies to echomail messages which would return to the
    echo messages's originator through the appropriate gateway, which may or
    may not be different than the gateway through which the echo message came.
    It is acknowledged that this may require  hand editing on the part of the
    user composing the reply.

  o If echomail is gated, and the other net has no equivalent, it may use net
    mail and/or net mail mailing lists.  Messages coming into FidoNet from
    this type of net mail or mailing list should properly gate into the
    appropriate echomail conference, and replies should work correctly as
    well.


Conclusion
----------

It is hoped that, given a philosophy and guidelines such as those outlined in
this paper, FidoNet will continue to expand its links to other networks to the
benefit of FidoNet and networking in general.

It is hoped that this paper will be of some help to those constructing gateways
to/from FidoNet, and to the administrators of FidoNet and other nets who are
considering gating to/from FidoNet.

This paper, the purported facts contained, and the philosophy espoused are the
sole responsibility of the author, and are quite likely technically incorrect
and are undoubtedly morally bankrupt.  Should you have constructive correction
or criticism, please contact:

Randy Bush
FidoNet: 1:105/6 1:105/42    [e-mail]
uucp: { mcvax!uunet, tektronix }!oresoft!dawggon!randy
Internet: [e-mail]      [e-mail]
Telemail: RBush
FAX: [phone]  TWX 910-464-4779

----------
FidoNet is a trademark of Tom Jennings and Fido Software, to whom we all owe
        much thanks for the origin and spirit of FidoNet.
DECNET is a trademark of Digital Equipment Corporation.
MS-DOS is a trademark of Microsoft Corporation.