From 40e2939e73f973109a473ddae02b53ead5417c48 Mon Sep 17 00:00:00 2001 From: Michiel Broek Date: Sun, 11 Jan 2004 16:50:10 +0000 Subject: [PATCH] Updated documentation --- html/Makefile | 12 +- html/dist.html | 9 +- html/ftsc/fsc-0035.html | 80 -- html/ftsc/fsc-0039.html | 363 -------- html/ftsc/fsc-0046.html | 228 ----- html/ftsc/fsc-0048.html | 418 --------- html/ftsc/fsc-0049.html | 104 --- html/ftsc/fsc-0050.html | 99 -- html/ftsc/fsc-0053.html | 188 ---- html/ftsc/fsc-0056.html | 1079 ---------------------- html/ftsc/fsc-0057.html | 534 ----------- html/ftsc/fsc-0059.html | 1623 --------------------------------- html/ftsc/fsc-0062.html | 364 -------- html/ftsc/fsc-0070.html | 123 --- html/ftsc/fsc-0072.html | 1926 --------------------------------------- html/ftsc/fsc-0087.html | 306 ------- html/ftsc/fsc-0088.html | 327 ------- html/ftsc/fsc-0091.html | 61 -- html/ftsc/fsc-0093.html | 157 ---- html/ftsc/fsp-1002.html | 141 --- html/ftsc/fsp-1011.html | 1757 ----------------------------------- html/ftsc/fta-1005.html | 269 ------ html/ftsc/fts-0001.html | 1261 ------------------------- html/ftsc/fts-0004.html | 415 --------- html/ftsc/fts-0005.html | 618 ------------- html/ftsc/fts-0006.html | 871 ------------------ html/ftsc/fts-0007.html | 1645 --------------------------------- html/ftsc/fts-0008.html | 491 ---------- html/ftsc/fts-0009.html | 105 --- html/ftsc/fts-4001.html | 193 ---- html/ftsc/fts-4008.html | 191 ---- html/ftsc/fts-4009.html | 245 ----- html/ftsc/fts-5000.html | 453 --------- html/ftsc/fts-5001.html | 403 -------- html/ftsc/ftscprod.html | 312 ------- html/ftsc/index.htm | 69 +- html/known_bugs.html | 5 +- html/setup/global.html | 42 +- 38 files changed, 50 insertions(+), 17437 deletions(-) delete mode 100755 html/ftsc/fsc-0035.html delete mode 100755 html/ftsc/fsc-0039.html delete mode 100755 html/ftsc/fsc-0046.html delete mode 100755 html/ftsc/fsc-0048.html delete mode 100755 html/ftsc/fsc-0049.html delete mode 100755 html/ftsc/fsc-0050.html delete mode 100755 html/ftsc/fsc-0053.html delete mode 100755 html/ftsc/fsc-0056.html delete mode 100755 html/ftsc/fsc-0057.html delete mode 100755 html/ftsc/fsc-0059.html delete mode 100755 html/ftsc/fsc-0062.html delete mode 100755 html/ftsc/fsc-0070.html delete mode 100755 html/ftsc/fsc-0072.html delete mode 100755 html/ftsc/fsc-0087.html delete mode 100755 html/ftsc/fsc-0088.html delete mode 100755 html/ftsc/fsc-0091.html delete mode 100755 html/ftsc/fsc-0093.html delete mode 100755 html/ftsc/fsp-1002.html delete mode 100755 html/ftsc/fsp-1011.html delete mode 100755 html/ftsc/fta-1005.html delete mode 100755 html/ftsc/fts-0001.html delete mode 100755 html/ftsc/fts-0004.html delete mode 100755 html/ftsc/fts-0005.html delete mode 100755 html/ftsc/fts-0006.html delete mode 100755 html/ftsc/fts-0007.html delete mode 100755 html/ftsc/fts-0008.html delete mode 100755 html/ftsc/fts-0009.html delete mode 100755 html/ftsc/fts-4001.html delete mode 100755 html/ftsc/fts-4008.html delete mode 100755 html/ftsc/fts-4009.html delete mode 100644 html/ftsc/fts-5000.html delete mode 100644 html/ftsc/fts-5001.html delete mode 100755 html/ftsc/ftscprod.html diff --git a/html/Makefile b/html/Makefile index 60c18005..36f292be 100644 --- a/html/Makefile +++ b/html/Makefile @@ -9,17 +9,7 @@ H_BASE = dist.html manual.css \ intergate.html intro.html invoking.html faq.html \ known_bugs.html mgetty.html routing.html nodelist.html -H_FTSC = ftsc/fsc-0039.html ftsc/fsc-0056.html ftsc/fsc-0087.html \ - ftsc/fts-0007.html ftsc/fsc-0046.html ftsc/fsc-0057.html \ - ftsc/fsc-0091.html ftsc/fta-1005.html ftsc/fts-0008.html \ - ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fts-0001.html \ - ftsc/fts-0009.html ftsc/fsc-0049.html ftsc/fsc-0062.html \ - ftsc/fsc-0093.html ftsc/fts-0004.html ftsc/index.htm \ - ftsc/fsc-0050.html ftsc/fsc-0070.html ftsc/fts-4008.html \ - ftsc/fts-5000.html ftsc/fsc-0053.html ftsc/fsc-0072.html \ - ftsc/fsp-1002.html ftsc/fts-0006.html ftsc/fsc-0035.html \ - ftsc/fts-4009.html ftsc/fsp-1011.html ftsc/ftscprod.html \ - ftsc/fsc-0088.html ftsc/fts-4001.html ftsc/fts-5001.html +H_FTSC = ftsc/index.htm H_IMAGES = images/b_arrow.png images/magic.png images/nodes1.png \ images/connec.png images/mbsetup0.png images/nodes2.png \ diff --git a/html/dist.html b/html/dist.html index a9f2469f..99dcf517 100644 --- a/html/dist.html +++ b/html/dist.html @@ -14,7 +14,7 @@
-
Last update 15-Aug-2003
+
Last update 11-Jan-2004

Unix Distributions.

Which distribution

@@ -59,9 +59,14 @@ The installation works on a Debian 2.1, 2.2 and 3.0 distribution without any pro How to build an optimized Debian system is not tested by me.

 

+

GenToo

+

+Installation and startup scripts are tested on GenToo. +

 

+

FreeBSD

-I test on FreeBSD 3.2 and 4.4 stable releases. +I tested on FreeBSD 3.2, 4.4 and 4.7 stable releases. The setup is quite simple, do a small setup (average user), and add some needed packages from the ports collection such as gcc, mgetty, infozip etc. The test machine has a 500 MB harddisk, about 250 MB is still free. Note that the older diff --git a/html/ftsc/fsc-0035.html b/html/ftsc/fsc-0035.html deleted file mode 100755 index 194fa6a5..00000000 --- a/html/ftsc/fsc-0035.html +++ /dev/null @@ -1,80 +0,0 @@ - - - -Transparant Gateways to and from FidoNet. - - - - -

-                  Transparent Gateways to and from FidoNet 
-                           Technical Considerations
-                                    FSC-0035
-
-                            Michael Shiels 22 June 89
-
-Copyright 1989, Michael Shiels.  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.
-
-
-Gateways
---------
-
-Gatewaying between Fidonet and other networks seems to be the latest feature
-which hopefully brings more benefits to the users of each network.  But there
-are some real problems with gatewaying and doing "transparent" replies.
-This proposal should allow for almost totally transparent gateways but requires
-the co-operation of BBS software writers to support this following protocol.
-
-Incoming Messages
------------------
-
-When a message is entered into fidonet from another network it will be entering
-through one machine (say 1/2).  The userid on the other network may not match
-very will with the 2 word 36 character userid on Fidonet.  So the following is
-done to store away the proper userid of the sender.
-
-Two (2) lines are added to the message (usually at the top of the text portion
-hidden by the infamous ^A KLUDGE).
-
-^AREPLYADDR .....\r
-
-which signifies the FULL userid of the person on the other network.  The first
-36 characters or the full userid if less than 36 characters long, are stored
-in the FROM field of the message header.  When replies are done they use a 
-second line of the following form.
-
-^REPLYTO zone:net/node firstname lastname
-
-which is used to signify the "userid" which mail destined to this other network
-must be sent to and on which machine that userids resides.  Replies are sent
-to this zone:net/node and userid with the first line of the message being
-changed into 'TO: ....' where .... is the FULL userid from the ^AREPLYADDR
-line.
-
-Should you have constructive correction or criticism, please contact:
-
-Michael Shiels
-FidoNet: 1:250/410   michael.shiels@masnet.fidonet.org
-uucp: ?!tmsoft!masnet!michael.shiels
-Internet: michael.shiels@masnet.uucp
-
-----------
-FidoNet is a trademark of Tom Jennings and Fido Software, to whom we all owe
-        much thanks for the origin and spirit of FidoNet.
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0039.html b/html/ftsc/fsc-0039.html deleted file mode 100755 index e64523c3..00000000 --- a/html/ftsc/fsc-0039.html +++ /dev/null @@ -1,363 +0,0 @@ - - - -A Type-2 Packet Extension Proposal. - - - - -
-Document: FSC-0039
-Version:  04
-Date:     29-Sep-90
-
-
-                      A Type-2 Packet Extension Proposal
-                       Mark A. Howard 1:260/340@FidoNet
-
-  Status of this document:
-  ------------------------
-  This FSC suggests a proposed protocol for the FidoNet(r) community,
-  and requests discussion and suggestions for improvements.  Distribution
-  of this document is unlimited.
-
-  Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
-  FTS-0001 is a copyrighted work of Randy Bush.
-
-  Introduction
-  ------------
-  This document serves two major purposes.  The first is an attempt to define
-  and document the Type-2 packet which is widely in use in FidoNet today.
-  Although FTS-0001 defines the structure of a Type-2 packet, the natural
-  evolution of our network, mostly with regards to addressing methodology,
-  has made it necessary to utilize hitherto unused portions of the header
-  to insert Zone and Point information.  Also, it has become apparent that
-  some of the existing fields are not large enough to accomplish their
-  original tasks.
-
-  The second is to propose a simple mechanism to allow FidoNet to begin to
-  utilize advanced mail packing techniques.  It is quite apparent that while
-  Type-2 has served us faithfully for some time now, the evolution of our
-  network in terms of technical and physical complexity has caused us to
-  consider more efficient and functional ways to pack mail.
-
-  It should be made clear that with the exception of the Capability Word,
-  Capability Word Validation Copy, ProductCode(hi), and Revision(minor),
-  which are proposed extensions to the Type-2 packet header, this FSC is
-  an attempt to correctly document existing practices with regards to the
-  insertion of zone and point info by at least three mail processors in
-  use today.
-
-
-  The Type-2 Header (Where's the Zone?)
-  -------------------------------------
-  Although FTS-0001 has recently been updated to reflect the use of some of
-  the areas in the packed message header for zone data, at least two other
-  methods for inserting the zone information have been adopted, making it
-  necessary to provide support for both formats in all of the zone aware mail
-  processors.  The end result is more code, and redundant information in the
-  packet header.
-
-  This has presented a problem in logistics, as it is difficult to consider
-  the project of updating mail processors using one type to use the other.
-  As sufficient indentification is provided, in the form of the product code,
-  to determine the expected location of the zone information, and because
-  code already exists in most of the mail processors to overcome this, this
-  proposal does not attempt to suggest that one method be used over the
-  other, rather the intent is to attempt to document the extensions in use,
-  and the products involved.
-
-  See the accompanying chart and cross-reference.
-
-
-  The Product Code
-  ----------------
-  Based upon the current rate of requests for product codes from the FTSC,
-  it is probable that the Product Code byte will not be large enough to
-  accomodate all of the codes required.  While it is not reasonable to
-  expect that all Type-2 processors will eventually check the hi-order byte
-  proposed here, it is likely that 'current' mail processors will.  This
-  can be nothing but benefical, as it will force users to upgrade their
-  mail processors to a product which will as a minimum, support Type-2
-  with Zone and Point extensions, and quite possibly, processors that will
-  utilize more advanced mail packing techniques, making Type-2 extinct once
-  and for all.
-
- 
-  The Capability Word  (How do we GET there from here?)
-  -----------------------------------------------------
-  Everybody would like to see more efficient and functional ways to pack and
-  exchange mail.  Several Type-3 message bundle proposals exist, but none
-  really address a problem which must be solved first.  The problem is that
-  since FidoNet is a hobbyist network, no demands can be placed on any one
-  sysop to upgrade or change their bundling software.  Because of this, it
-  is necessary to consider strategies which allow for the existence of Type-2
-  bundlers in the network topology.
-
-  Considerable advantages can be realized, however, between systems that
-  consent to use advanced bundling techniques.  One way to do this is to
-  simply send netmail to all of your connecting systems, saying "Hey, I've
-  got a Type-3 bundler now, how about you?"  This could become quite
-  tiresome, and does not represent much of an improvement on the current
-  situation.
-
-  What would be desirable is a network that would 'upgrade itself'.  Given a
-  situation where mail processors of various capabilities will exist in a
-  network topology, the goal is to provide a mechanism whereby two links can
-  determine and utilize the most efficient bundling method to use, in a
-  manner transparent to the sysop.
-
-  For instance, let's say that the FTSC releases the Type-7 All New Singing
-  and Dancing bundle format.  Well, your current version of SlingToss can
-  only support Types 2, 3, and 5.  One of your downlinks gets a new version
-  of MailMangle which can support Types 2, 3, 4, and 7.  Well, it is quite
-  obvious that since you and he are exchanging 4 megs of mail each night,
-  and it's an overseas call, that it would be in your interest to obtain a
-  new version of SlingToss which can support Type 7.
-
-  Note that this is *optional*.  Because both processors can support Type-3,
-  they will continue to exchange Type-3 mail quite happily, even though
-  MailMangle is happily advertising the availability of Type-7.  Even your
-  downlinks which are still using stone-age Type-2 processors will be fine,
-  as SlingToss will always export Type-2 bundles when no higher capability
-  can be determined.
-
-  So, after dashing off the check to the author, your new version of
-  SlingToss comes in the mail!  You rush over to your system, and install it.
-  The next time SlingToss exports mail to the MailMangle system, it says
-  "Hey!  I can now support Type 2, 3, 5, and 7!  So, whattya got?"  This is
-  no skin off MailMangle's nose, he's had Type-7 for quite a while, and he
-  begins to export Type-7 bundles to SlingToss.  "It's about time.", he says.
-
-  Now, this scenario is made possible by implementing a 'Capability Word' in
-  the present and future packet headers.  The Capability Update mechanism
-  depends on several assumptions:
-
-  1)   Any Advanced Capability Bundler *MUST* be capable of receiving and
-     faithfully processing Type-2 bundles.  Hopefully, the inbound packets
-     will be in the new format proposed by this document, but then again,
-     this is not an exact science.  What this means is that it is likely
-     that some packets may arrive with the Capability Word (CW) set to 0.
-     In this case, Type-2 is assumed, assuring compatibility.  The only
-     caveat is that it is conceivable that some obscure mail processor
-     uses the location proposed for the CW for other arcane purposes.  This
-|    can detected through the CWValidation Copy, which is byte-swapped and
-|    compared with the CW at that time.  If a mismatch is found, a CW of
-|    type 0 is assumed, and a Type-2 bundling method is used.
-
-  2) An Advanced Capability Bundler, hereafter referred to as a Type-N
-     Bundler, must have a method to store and maintain the node-by-node
-     capability information.  This can be done many ways, and in fact
-     several processors already have begun to maintain node information
-     outside of that found in AREAS.BBS, mostly to implement pre-arranged
-     alternate compression methods.  In a text configuration file, you
-     might see the following:
-
-     ;       Address      Comp    Send  LastCW ; Comments
-     Node    1:260/340    ZIP     Auto  7      ; Auto detect & upgrade
-     Node    1:135/20     LZH     3     2,3,7  ; Always send Type-3
-     Node    1:           ARC     2     0      ; Stone-Age processor
-     Node    1:135/4      ---     Auto  7      ; Sent me netmail
-     Node    1:           ---     0     0      ; Don't send CW
-
-     In this example, the fields are:
-
-     Address - downlink address.  Note that this is not necessarily
-               relative to echomail, only, it is possible to append
-               information to the node database as netmail packets are
-               receieved from different addresses.
-
-     Comp    - desired mail compression method.
-
-     Send    - Auto - automatically determined maximum common packing
-                      method to use.  Automatically update to LastCW
-                      when packing.
-
-     LastCW  - Last CW received from remote system.
-
-
-  3) A Type-N Bundle will always advertise it's capabilities in the CW
-     regardless of the type being sent.  As shown in the above example,
-     it allows Type-N processors to automatically track the capability
-     of your system.  Again, in cases where a stone-age processor is
-     being used, this field will be ignored, and in the unusual event
-     that it is not ignored, and is somehow harmful to the far system,
-     the Type-N processor can be configured to send a CW of 0.
-
-  The format of the Capability Word is designed to support up to 15 future
-  bundle types, and is bit-mapped to facilitate the easy determination of
-  the maximum common level supported between two nodes:
-
-                 msb           Capability Word               lsb
-  Node Supports  ------------FTSC Type Supported----------------
-
-                  U 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2
-
-  2, 3, and 7     0  0  0  0  0  0  0  0  0  0  1  0  0  0  1  1
-  2, 3, and 5     0  0  0  0  0  0  0  0  0  0  0  0  1  0  1  1
-  2 (this FSC)    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  1
-  Stone Age**     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
-                  ^
-                  +--- Indicates UseNet RFC-822 capability
-
-                  ** - a mismatch in the CWValidation Copy also
-                       produces a CW=0.
-
-  In this example, the Type-N bundler would first compare the remote CW
-| and the byte-swapped remote CWValidation Copy, and check for a mismatch.
-  Prior to the compare, the MSB of the CW's are masked, as this bit is
-  reserved to indicate whether the mail processor is capable of also
-  accepting UseNet RFC-822 bundles.  Following the MSB mask, and bit
-  comparison, if they do not match, a remote CW of 0 is assumed.  If they
-  match, the Type-N processor would AND the local and remote CW words,
-  obtaining a CW expressing the Types which are in common to both systems.
-  The most significant Type will be used, by default, but note that this
-  assumes that new bundling Types will be increasingly more efficient or
-  in some way more beneficial.
-
-  Because this may not always be the case, there should be a method provided,
-  as illustrated above, to override the automatic upgrade should this become
-  the case.
-
-  The MSB of the CW is used to indicate whether the mail processor can accept
-  UseNet RFC-822 bundles or not.  It is a separate indicator, and not intended
-  to be used as a part of the above comparison, however can be used to also
-  advertise RFC-822 capability to other systems.  Since RFC-822 is 'set in
-  stone', there is no need to assign more than one capability bit.
-
-  It might seem somewhat limiting to only consider the possibility of 15
-  different future bundling methods, but it is my opinion that the careful
-  use of a 'Sub-Type' byte in the packet header can allow for the variations
-  on a single theme, and that proposals for new formats should be evaluated
-  by the FTSC to determine whether sufficient benefit can be realized in
-  the implementation of the given format, prior to assigning a new type
-  code.
-
-
-  Mailers
-  -------
-  It is quite clear to me that should this concept take hold, that the
-  logical place to store node capability data is in the local nodelist
-  database, or an index-associated data file.  As above, it is necessary
-  to generate Type-2 packets for whatever purpose, unless it is known
-  by prior association, that the far mailer can accept other types of
-  packets.  It is also quite reasonable to assume that a nodelist flag
-  could be assigned to advertise the CW for a given node, which the
-  native mailer nodelist compiler could then immediately determine the
-  preferred bundling method for any given node in FidoNet.
-
-  Another possibility would be to pass a capability advertisement in the
-  extensible portion of a handshake protocol, which may or may not already
-  exist in FidoNet.
-
-  The approach suggested previously in this document suggests the use of
-  a text configuration file, but it is quite obvious that many benefits
-  can be realized through the use of the nodelist, including the use of
-  additional flags to indicate the preferred compression method, etc.
-
-
-  Summary
-  -------
-  This document has been created in an attempt to define a method to allow
-  the future expansion and enhancement of FidoNet technology mail processors
-  and mailers, and in a way that is the least disruptive to existing mail
-  operations.  The intent is to provide for an environment that is as open,
-  and extensible as possible.
-
-  The mechanism described should allow many different types of processors
-  (FTSC-registered) to exist in the network at once, and to provide an
-  environment which is designed to operate at it's maximum efficiency
-  wherever possible or practical.
-
-  Revision 2 of this document was produced to implement suggestions made
-  primarily by Jan Vroonhof, who suggested the use of the CW Validation
-  Copy.  Jan presented this idea in his FSC-0048, along with other concepts
-  relating to the correct indentification and handling of zone and point
-  addressing.   This document sanctions the improvements to the CW as
-  recommended, but does not address or support the other extensions
-  recommended in FSC-0048.
-
-
-  Thanks
-  ------
-  To Ward Christensen, creator of XModem and BYE.
-
-     Tom Jennings, who started this whole mess.
-
-     Joaquim Homrighausen, for lots of good ideas, and motivation.  Here's
-                           another Lamborghini to work on.
-
-     Wynn Wagner, Oliver McDonald, Roeland Meyer, Andrew Farmer, Claude
-     Warren, Jan Vroonhof, Bob Hartman, and Vince Perriello, who all
-     contributed in some way to the creation of this document, mostly
-     through their messages in NET_DEV.
-
-
-
-  Type-2 Packet Format (proposed, but currently in use)
-  -----------------------------------------------------
-    Field    Ofs Siz Type  Description                Expected value(s)
-    -------  --- --- ----  -------------------------- -----------------
-    OrgNode  0x0   2 Word  Origination node address   0-65535
-    DstNode    2   2 Word  Destination node address   1-65535
-    Year       4   2  Int  Year packet generated      19??-2???
-    Month      6   2  Int  Month  "        "          0-11 (0=Jan)
-    Day        8   2  Int  Day    "        "          1-31
-    Hour       A   2  Int  Hour   "        "          0-23
-    Min        C   2  Int  Minute "        "          0-59
-    Sec        E   2  Int  Second "        "          0-59
-    Baud      10   2  Int  Baud Rate (not in use)     ????
-    PktVer    12   2  Int  Packet Version             Always 2
-    OrgNet    14   2 Word  Origination net address    1-65535
-    DstNet    16   2 Word  Destination net address    1-65535
-    PrdCodL   18   1 Byte  FTSC Product Code     (lo) 1-255
-  * PVMajor   19   1 Byte  FTSC Product Rev   (major) 1-255
-    Password  1A   8 Char  Packet password            A-Z,0-9
-  * QOrgZone  22   2  Int  Orig Zone (ZMailQ,QMail)   1-65535
-  * QDstZone  24   2  Int  Dest Zone (ZMailQ,QMail)   1-65535
-    Filler    26   2 Byte  Spare Change               ?
-| * CapValid  28   2 Word  CW Byte-Swapped Valid Copy BitField
-  * PrdCodH   2A   1 Byte  FTSC Product Code     (hi) 1-255
-  * PVMinor   2B   1 Byte  FTSC Product Rev   (minor) 1-255
-  * CapWord   2C   2 Word  Capability Word            BitField
-  * OrigZone  2E   2  Int  Origination Zone           1-65535
-  * DestZone  30   2  Int  Destination Zone           1-65535
-  * OrigPoint 32   2  Int  Origination Point          1-65535
-  * DestPoint 34   2  Int  Destination Point          1-65535
-  * ProdData  36   4 Long  Product-specific data      Whatever
-    PktTerm   3A   2 Word  Packet terminator          0000
-
-  * - extensions to FTS-0001
-
-  Ofs, Siz are in hex, other values are decimal.
-
-
-  Zone/Point Aware Mail Processors (probably a partial list)
-  ----------------------------------------------------------
-    Prod
-    Code Name - Uses QOrg/QDstZone Orig/DestZone Orig/DestPoint
-    ---- ----------- ------------- ------------- --------------
-    0x0C  FrontDoor  Reads/Updates      Yes           Yes
-    0x1A  DBridge        ?????          Yes           Yes
-    0x45  XRS        Reads/Updates      Yes           Yes
-    0x29  QMail           Yes          ?????      Not point-aware
-    0x35  ZMailQ          Yes          ?????      Not point-aware
-    0x3F  TosScan    Reads/Updates      Yes           Yes
-
-
-
-
-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0046.html b/html/ftsc/fsc-0046.html deleted file mode 100755 index 79ce7fd7..00000000 --- a/html/ftsc/fsc-0046.html +++ /dev/null @@ -1,228 +0,0 @@ - - - -A Product Identiefier for FidoNet Message Handlers. - - - -
-Document: FSC-0046
-Version:  005
-Date:     30-Aug-94
-
-
-
-
-
-
-
-
-            A Product Idenfifier for FidoNet Message Handlers
-
-                            Joaquim Homrighausen
-                       2:270/17@fidonet or joho@abs.lu
-
-                              August 30, 1994
-
-         Copyright 1994 Joaquim Homrighausen; All rights reserved.
-
-
-
-Status of this document:
-
-     This FSC suggests a proposed protocol for the FidoNet(r) community,
-     and requests discussion and suggestions for improvements.
-     Distribution of this document is unlimited.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-
-    Purpose
-
-    This document should serve as a guide for the product identfier, PID
-    hereafter, format for FidoNet message handlers. The purpose behind PIDs
-    is related to my attempt to remove the requirement of Origin lines in
-    conference mail messages.
-
-    While I fully understand that this won't happen in all conferences, I
-    would like to provide the facility to those who can use it (i.e. for
-    conferences where all the participants are using software that supports
-    messages without origin lines).
-
-    Another use for PIDs is to minimize the excessive amount of information
-    some programs put on the tear lines which increases overall
-    transportation cost and time of conference mail.
-
-
-    PID
-
-    A PID replaces the program identifier often seen on the tear line of
-    conference mail messages and is hidden behind a ^A (ASCII SOH, 01h).
-    This also allows for better tracking of software causing problems in
-    conferences.
-
-:   Only one PID per message is allowed and should only be added by the
-:   program that creates the message. I.e. programs passing the message on
-:   to someone else may not add additional PIDs. If a PID is added, no
-:   program information may be present after the tear line.
-
-    A PID also offers the ability to add serial numbers to identify a
-    specific copy of a program as being the source of a message with little
-    or no effort.
-
-
-    Format
-
-      ^APID:  [ ]
-
-
-    Sample
-
-      ^APID: FM 2.11.b
-
-      Would identify FrontDoor's editor, beta version 2.11 and replace:
-
-       --- FM 2.11 (beta)
-
-
-    Fields
-
-    pID         The ID of the product responsible for creating the message.
-                This should be kept as short as possible. The maximum
-                length for this field is 10 characters.
-
-    version     The version of the product including any alpha, beta, or
-                gamma status. Only the relevant part of the version should
-                be included. I.e. 1.00 should be expressed as 1, 1.10 as
-                1.1 and 1.01 as 1.01. Alpha, beta, or gamma status should
-                be expressed by appending a / or . followed by a, b, or g
-                and optionally a revision indicator, such as a1, b2, etc.
-                The maximum length for this field is 10 characters.
-
-    serial#     The serial number of the product, omitted if irrelevant
-                or zero. The maximum length for this field is ten (10)
-                characters.
-
-
-    TID
-
-    TIDs or "Tosser IDs" started to appear shortly after the first
-    revision of this document was released. They are added by Conference
-    Mail ("EchoMail") processors when a message is exported from the
-    local message base and injected into the network distribution scope
-    for a conference.
-
-    When a Conference Mail processor adds a TID to a message, it may not
-    add a PID. An existing TID should, however, be replaced. TIDs follow
-    the same format used for PIDs, as explained above.
-
-
-    List of products
-
-    The accompanying file, PIDLIST.TXT, is a list of products known to
-    support the PID proposal. Software authors are encouraged to inform
-    the author of this document of changes and additions to this list.
-
-     --- end of file "fsc-0046.005" ---
-
-
-
-Document: PIDLIST.TXT (FSC-0046)
-Date:     30-Aug-94
-
-
-
-                     A list of used product idenfifiers
-
-                            Joaquim Homrighausen
-                      2:270/17@fidonet or joho@abs.lu
-
-
-
-Product identifiers
-
-Product                Version  ID        Author
------------------------------------------------------------------------------
-!!MessageBase           1.6+    !!MB      Holger Lembke          2:240/500.20
-Alert                   2.1+    Alert     Richard Kail           2:310/25.2
-ANet                    921213+ ANet      Thomas Ekstroem        2:201/411
-ArcMail RISC OS         1.04+   AM        Philip Blundell        2:440/34.4
-Artmail Mailer System   1.00+   ART       Klaus Landefeld        2:247/402
-Auto Message Taker      1.00+   AMT       Patrik Torstensson     n/a
-AVALON                  3.10+   AVALON    Stephan Slabihoud      2:2401/103.6
-CrossPoint              2.10+   XP        Peter Mandrella        2:243/97.80
-EchoSprint              1.02+   ES        Ben Elliston           3:620/262
-Enhanced Mail MAnager   .01+    EMMA      Johan Zwiekhorst       2:292/118
-Enhanced Message EDitor .02+    EMED      Johan Zwiekhorst       2:292/118
-EZMail                  .67+    EZMail    Torben Paving          2:234/41
-F_POINT                 1.1+    F_POINT   Florian Rupp           2:248/107.2
-FastEcho                1.21a+  FastEcho  Tobias Burchhardt      2:245/39
-FileScan                1.5+    FileScan  Matthias Duesterhoeft  2:241/4513
-Freqit (Windows)        1.0+    FIW       Marvin Hart            1:106/462
-Freqit (MS-DOS)         1.0+    FID       Marvin Hart            1:106/462
-FrontDoor APX           1.00+   FDAPX     Joaquim Homrighausen   2:270/17
-FrontDoor (Editor)      2.00+   FM        Joaquim Homrighausen   2:270/17
-FrontDoor (Mailer)      2.00+   FD        Joaquim Homrighausen   2:270/17
-FrontEnd FX             1.00+   FEFX      Eric Theriault         1:132/220
-GEcho                   1.00+   GE        Gerard van der Land    2:2802/110
-GeeMail                 2.00+   GeeMail   Lech Szychowski        2:480/4.7
-HbToSca                 1.00+   HTS       Jani Laatikainen       2:220/150
-HyperBBS                2.00+   HyperBBS  Jani Laatikainen       2:220/150
-JetMail                 1.00+   JetMail   Daniel Roesen          2:243/93.8
-LazyBBS                 .5+     LazyBBS   Franck Arnaud          2:320/100
-Mail FX                 1.00+   MFX       Eric Theriault         1:132/220
-MsgTrack                3.20+   MT        Andrew Farmer          1:243/1
-NewsFlash               1.01+   NwF       Chris Lueders          2:2402/330
-NodeDiff Processor      3.00+   NDP       Serge Vikulov          2:5080/5
-Notify                  2.1     Notify    Frank Schuhardt        2:247/160
-OFFFax                  3.03    OFFFax    Frank Schuhardt        2:247/160
-Pobble                  0.15+   Pobble    Josh Parsons           3:771/340
-QBBed                   2.64+   qbbed     Werner Berghofer       2:310/90.100
-RemoteAccess            1.10+   RA        Andrew Milner          2:270/18
-RASS                    1.00+   RASS      Yossi Gottlieb         2:403/139.75
-SendFile                1.00+   SendFile  Mike Shoyher           2:5020/17.3
-Synchronet              1.00+   SYNC      Rob Swindell           1:103/705
-TB-Edit                 1.10+   TB-Edit   Arjen Lentz            2:283/512
-TB-Mailer               1.97+   TB-Mailer Arjen Lentz            2:283/512
-TB-Point                .10+    TB-Point  Arjen Lentz            2:283/512
-TechBBS                 1.00    TECHBBS   Marcel Tegelaar        2:281/409
-TechMail                1.00    TECHMAIL  Raymond van der Holst  2:281/409.2
-TosScan                 1.10+   TosScan   Joaquim Homrighausen   2:270/17
-TPCS                    .89b    TPCS      Krister Hansson-Renaud 2:201/201.7
-                                          Mikael Kjellstrom      2:201/201.10
-XRobot                  3.00+   XRobot    Joaquim Homrighausen   2:270/17
-Xrs Alternative Packer  1.04+   XAP       Jeroen Smulders        2:512/1.8
-ZeroToss                1.00    ZeroToss  Jeff Masud             1:103/115
------------------------------------------------------------------------------
-
-
-Product identifier registration
-
-Simply fill in the required information and send this form to the author of
-this document via private netmail.
-
- Product: _________________________________________
-
- Version: __________
-
-PID info: _________________________________________
-
-  Author: _________________________________________
-
- Address: ___________________________ (eMail address)
-
---- end of file "pidlist.txt" ---
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0048.html b/html/ftsc/fsc-0048.html deleted file mode 100755 index 574db5ab..00000000 --- a/html/ftsc/fsc-0048.html +++ /dev/null @@ -1,418 +0,0 @@ - - - -A Proposed Type-2 Packet Extension. - - - - -
-Document: FSC-0048
-Version:  002
-Date:     21-Oct-90
-
-
-
-
-
-                   A Proposed Type-2 Packet Extension
-                              Jan Vroonhof
-                           2:281/1.12@fidonet
-                              Oct 21, 1990
-
-
-
-
-
-     Status of this document
-     =======================
-
-     This  FSC  suggests  a proposed  protocol  for  the  FidoNet(r) 
-     community,   and   requests  discussion  and  suggestions   for 
-     improvements. Distribution of this document is unlimited.
-
-     Fido and FidoNet are registered marks of Tom Jennings and  Fido 
-     Software.
-
-     Purpose
-     =======
-
-     The  final  goal of this document is to become  a  widely  used 
-     standardised  extension to FTS-0001,  like FTS-0006,  0007  and 
-     0008  are,  and  provide  an elegant way to  switch  to  a  new 
-     bundling  method  without requiring major  effort  or  breaking 
-     anything.
-
-     Prologue
-     ========
-
-     The  main  thing  that needs stressing is  that  the  additions 
-     covered  by this document are FULLY (I repeat FULLY)  BACKWARDS 
-     COMPATIBLE  with  FTS-0001 (and other  existing  standards  and 
-     practices  in  FidoNet and WhatEverOtherNets that I  know  of). 
-     When I say "backwards compatible" I mean that problems it would 
-     create  already  exist  in the current  FTS-0001  system  (e.g. 
-     zone  conflicts when dealing with a non compliant  system).  In 
-     short   it  only  corrects  some  flaws  in  FTS-0001   WITHOUT 
-     generating new ones.
-
-     In  this document I have tried to stay as much as  possible  on 
-     the   paths   of  existing   practices.   Therefore   I   think 
-     implementation  of  the additions it proposes will not  be  too 
-     hard.
-
-!    Prologue to revision 2
-!    ======================
-
-!    Revision   2   of  this  document  reserves  a   bit   in   the 
-!    CapabilityWord  for one bundle type already in use  outside  of 
-!    FidoNet,  RFC-822.  A small change was made to the  "receiving" 
-!    flowchart  in order to ensure compatibility with  FSC-0039.004. 
-!    In  the process a lot of errors and omissions in the  spelling, 
-!    credits etc. were corrected.
-
-     ===============
-
-!    All  references in the following to FSC-0039 are to Revision  1 
-!    of that document.
-
-     My thoughts on FSC-0039 and FTS-0001 rev 12
-     ===========================================
-
-     First,  revision  12  of FTS-0001 introduced  the  term  "(some 
-     impls)"  to indicate that some implementations used  their  own 
-!    extensions  to FTS-0001 (Note that in later revisions this  was 
-!    changed to "optional"). The problem is that this info cannot be 
-     relied upon,  because there is no way to actually validate  the 
-     data. One can only check whether the values of these fields are 
-     in the range of valid values and hope for the best.
-
-     Second,  FSC-0039  introduced  the idea of  having  a  bitfield 
-     (called the Capability Word) indicating whether extension  data 
-     was  valid.  Through  the  Capability Word,  it  also  made  it 
-     possible to indicate the ability to support other,  non type 2, 
-     packets,  thus allowing for flexible migration towards type  3. 
-     It  also documented the addressing extensions used  by  various 
-     programs.
-
-     However, FSC-0039 has two flaws:
-
-     1. One  cannot  be  sure the bitfield  is  zero  because  other 
-        implementations might use this field for their own purposes. 
-        Therefore  this document includes a second  validation  copy 
-        for the Capability Word (CW hereafter). This copy allows the 
-        FSC-xxxx compliant software to validate the CW by  comparing 
-        the two.  The chance of some junk portraying itself as a  CW 
-        is significantly reduced by this.
-
-!       Please  note  that  the  validation  copy  is  byte  swapped 
-!       compared to the normal capability word.  While this  started 
-!       out  as a typo,  I decided to leave it in as  it  introduces 
-!       some extra safety, without requiring much extra code effort. 
-!       In later revisions of FSC-0039,  Mark adopted this idea of a 
-!       validation copy too and eliminated the problem.
-
-     2. Although  FSC-0039 provides a way to make packet headers  4D 
-        it  is not backwards compatible.  It cannot be used in  FTS-
-        0001 sessions to unknown systems,  making FidoNet still  not 
-        totally 4D capable.  Although it implements fields for  zone 
-        and point number,  an FTS-0001 compliant application is  not 
-        required to look at these fields.  When a point mails  using 
-        these  fields  to implement its 4D address,  a  system  only 
-        looking  at the net/node info,  as is required by  FTS-0001, 
-        still sees it as a boss node, causing the obvious problems.
-
-        This document provides a way for transparent point handling, 
-        using   a  technique  already  exploited  by  many   mailers 
-        internally.  It  will allow this document to be  implemented 
-        and used by mailers not supporting it.  At the same time the 
-        danger that a point is seen as the boss node is eliminated.
- 
-        It does NOT provide full inter-zone backwards compatibility, 
-        but that is not needed as badly, as problems are not yet too 
-        great.  Any  measures to ensure backwards  compatibility  in 
-        this  area  might  harm  communication  with  non-supporting 
-        programs, when the old system could handle the situation.
-
-     Packet Header
-     =============
-
-     The "|" character is used to indicate extensions documented  in 
-     FTS-0001  revision  12,   the  ":"  character  indicates  those 
-     documented here and in FSC-0039.
-
-       Offset
-      dec hex
-              .-----------------------------------------------------.
-        0   0 | origNode     (low order) | origNode    (high order) |
-              +--------------------------+--------------------------+
-        2   2 | destNode     (low order) | destNode    (high order) |
-              +--------------------------+--------------------------+
-        4   4 | year         (low order) | year        (high order) |
-              +--------------------------+--------------------------+
-        6   6 | month        (low order) | month       (high order) |
-              +--------------------------+--------------------------+
-        8   8 | day          (low order) | day         (high order) |
-              +--------------------------+--------------------------+
-       10   A | hour         (low order) | hour        (high order) |
-              +--------------------------+--------------------------+
-       12   C | minute       (low order) | minute      (high order) |
-              +--------------------------+--------------------------+
-       14   E | second       (low order) | second      (high order) |
-              +--------------------------+--------------------------+
-       16  10 | baud         (low order) | baud        (high order) |
-              +--------------------------+--------------------------+
-       18  12 |      0      |      2     |      0      |      0     |
-              +--------------------------+--------------------------+
-       20  14 | origNet      (low order) | origNet     (high order) |
-:             |               Set to -1 if from point               |
-              +--------------------------+--------------------------+
-       22  16 | destNet      (low order) | destNet     (high order) |
-              +--------------------------+--------------------------+
-|      24  18 | ProductCode  (low order) | Revision         (major) |
-|             +--------------------------+--------------------------+
-|      26  1A |                      password                       |
-|             |               8 bytes, null padded                  |
-|             +--------------------------+--------------------------+
-|:     34  22 | origZone     (low order) | origZone    (high order) | }
-|             +--------------------------+--------------------------+ } As in
-|:     36  24 | destZone     (low order) | destZone    (high order) | } QMail
-:             +--------------------------+--------------------------+
-:      38  26 | AuxNet       (low order) | AuxNet      (high order) |
-:             +--------------------------+--------------------------+
-:      40  28 | CWvalidationCopy  (high) | CWvalidationCopy   (low) |
-:             +--------------------------+--------------------------+
-:      42  2A | ProductCode (high order) | Revision         (minor) |
-:             +--------------------------+--------------------------+
-:      44  2C | CapabilWord  (low order) | CapabilWord (high order) |
-:             +--------------------------+--------------------------+
-:      46  2E | origZone     (low order) | origZone    (high order) | }
-:             +--------------------------+--------------------------+ } As in
-:      48  30 | destZone     (low order) | destZone    (high order) | } FD etc
-:             +--------------------------+--------------------------+
-:      50  32 | origPoint    (low order) | origPoint   (high order) | }
-:             +--------------------------+--------------------------+ } As in
-:      52  34 | destPoint    (low order) | destPoint   (high order) | } FD etc
-:             +--------------------------+--------------------------+
-:      54  46 |                 Product Specific Data               |
-:             +                                                     +
-:             |                       4 Bytes                       |
-              +--------------------------+--------------------------+
-       58  3A |                     zero or more                    |
-              ~                        packed                       ~
-              |                       messages                      |
-              +--------------------------+--------------------------+
-              |      0      |      0     |      0      |      0     |
-              '-----------------------------------------------------'
-
-    Packet       = PacketHeader  { PakdMessage }  00H 00H
-
-    PacketHeader = origNode       (* of packet, not of messages in packet   *)
-                   destNode       (* of packet, not of messages in packet   *)
-                   year           (* of packet creation, e.g. 1986          *)
-                   month          (* of packet creation, 0-11 for Jan-Dec   *)
-                   day            (* of packet creation, 1-31               *)
-                   hour           (* of packet creation, 0-23               *)
-                   minute         (* of packet creation, 0-59               *)
-                   second         (* of packet creation, 0-59               *)
-                   baud           (* max baud rate of orig and dest         *)
-                   PacketType     (* old type-1 packets now obsolete        *)
-                   origNet        (* of packet, not of messages in packet
-                                     set to -1 if orig=point                *)
-                   destNet        (* of packet, not of messages in packet   *)
-+                  productCode Lo (* 0 for Fido, write to FTSC for others   *)
-|+                 serialNo Maj   (* binary serial number (otherwise null)  *)
-|                  password       (* session pasword  (otherwise null)      *)
-|                  origZone       (* zone of pkt sender (otherwise null)    *)
-|                  destZone       (* zone of pkt receiver (otherwise null)  *)
-|                  auxNet         (* contains Orignet if Origin is a point  *)
-+!        Bytesw.  CWvalidationCopy (* Must be equal to CW to be valid      *)
-+                  ProductCode Hi
-+                  revision Minor
-+                  origZone       (* zone of pkt sender (otherwise null)    *)
-+                  destZone       (* zone of pkt receiver (otherwise null)  *)
-+                  ProdData       (* Product specific filler                *)
-
-     When  the two copies of the CW match they can be asumed  to  be 
-     valid and used.
-
-     Stone-Aged: Old FTS-0001
-     Type-2+   : Old FTS-0001 plus changes indicated by "|" and  ":" 
-                 are valid
-
-     A  Type-N Bundle will always advertise its capabilities in  the 
-     CW regardless of the type being sent.   As shown in the example 
-     below,  the CW allows Type-N processors to automatically  track 
-     the capability of your system.   Again, in cases where a stone-
-     age processor is being used, this field will be ignored, and in 
-     the  unusual  event  that it is not  ignored,  and  is  somehow 
-     harmful  to  the  far  system,  the  Type-N  processor  can  be 
-     configured to send a CW of 0.
-
-     The format of the Capability Word is designed to support up  to 
-     15  future bundle types,  and is bit-mapped to  facilitate  the 
-     easy  determination  of  the  maximum  common  level  supported 
-     between two nodes:
-
-                    msb           Capability Word               lsb
-     Node Supports  ------------FTSC Type Supported **)------------
-
-                     U 16 15 14 13 12 11 10  9  8  7  6  5  4  3 2+
-
-     2+,3, and 7     0  0  0  0  0  0  0  0  0  0  1  0  0  0  1  1
-     2+,3, and 5     0  0  0  0  0  0  0  0  0  0  0  0  1  0  1  1
-     2+ (this Doc)   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  1
-     Stone Age       0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
-
-!                    ^-- "U" Indicates nodes able to process RFC-822 
-!                        bundles.
-                    ** - In the example bit definitions only type 2, 
-                         and  the Stone-Age type,  are defined  now. 
-                         The rest are to be concidered "reserved  by 
-                         FTSC".
-
-     The receiving Type-N bundler would AND the two words, obtaining 
-     a  word  expressing  the Types which are  common  to  both  the 
-     receiving  and the sending system.   The most significant  Type 
-     will be used for future sessions,  by default. Please note that 
-     this assumes that new bundling Types will be increasingly  more 
-     efficient or in some way more beneficial.  Because this may not 
-     always  be  the  case,  there should be a  method  provided  to 
-     override the automatic upgrade,  as illustrated  above,  should 
-     this ever happen.
-
-!    N.B. The  one bit left over (Msb) is now used as indicator  for 
-!         RFC-822 type bundles. For info on RFC-822 please check out 
-!         the relevant documents themselves.
-
-!         For  a more explanatory text on using the CW to  its  full 
-!         potential,  refer  to  the FSC-0039 text by  Mark  Howard. 
-!         Mark also gives some more rationale for the origional idea 
-!         of the CW.
-
-     Generating Type-2+ bundles
-     ==========================
-
-      Do we have a CW              Does CW indicate
-     stored for dest?  YES ---->   higher packets  YES ---> Generate higher
-           NO                       we support?                packet
-           |                            NO
-          \|/                           |
-           +-----<----------------------+
-           |
-      Fill header with all info
-           |
-          \|/
-           |
-      Are we sending from a point? (origPoint != 0) YES --+
-           |                                              |
-          NO                                              |
-           |                                             \|/
-           |                                    set AuxNet = OrigNet
-          \|/                                  set OrigNet = -1
-           |                                              |
-           +-----<----------------------------------------+
-           |
-      Add Messages
-           |
-      Terminate packet
-           |
-       Send packet
-
-     Receiving Type-2+ bundles
-     =========================
-
-       Receive Packet
-           |
-       Packettype = 2  NO  -------------> Process Type-Other
-          YES
-           |
-           |
-       CWcopies match  NO --------+------> Treat as normal Stone-Age packet
-          YES                     |     |
-           |                      |     |
-       Store CW                  /|\    |
-           |                      |    /|\
-       CW is 0 YES  --------------+     |
-          NO                            |
-           |                            |
-           |                            |
-       CW indicates support for 2+ NO --+
-          YES
-           |
-           |
-!      OrigPoint is not 0 and OrigNet = -1 YES -------+
-           NO                                         |
-           |                                         \|/
-!         \|/                            Set OrigNet is AuxNet
-           |                                          |
-           +------<-----------------------------------+
-           |
-        Process using added info
-
-     Credits
-     =======
-
-     To Mark Howard,  for introducing the idea of a CW in his  FSC-
-     0039  document and quite rightly pointing out one big  omision 
-     in revision 1 of this document.
-
-     To  Rick Moore,  for doing a good job in processing all  these 
-     revisions by Mark and myself, and for his work for the FTSC in 
-     general.
-
-     To  Joaquim  Homrighausen,  for his contributions  to  FidoNet 
-     software  in general,  and especially for his time devoted  to 
-     reading,  discussing  and  implementing the ideas Mark  and  I 
-     introduced.
-
-     To  Andre van de Wijdeven,  for producing and letting me  beta 
-     test his TS-MM software, which in my opinion is the best point 
-     software around.  (I'm not saying available,  because it isn't 
-     :-()
-
-     To john lots, for shipping this stuff to the US.
-
-     To  Jon  Webb,  for doing a much needed grammar  and  spelling 
-     check.
-
-     To Bob Hartman, Vince Periello, Tom Jennings, Eelco de Graaff, 
-     aXel Horst,  Arjen van Loon,  jim nutt,  Odinn Sorensen, David 
-     Nugent,  Peter  Janssens and many others,  for making  FidoNet 
-     what it is now, for me and for everybody.
-
-     Epilog
-     ======
-
-     So  this it,  now it's up to you to decide whether or  not  to 
-     implement  it.  A  small  change was  made  in  the  receivers 
-     flowchart and a small incompatibility with the later revisions 
-     of  FSC-0039 was removed.  That will ensure that FSC-0048  and 
-     FSC-0039 mailers can happily talk to each other....
-
-     The best way to implement this would be to always support FSC-
-     0048  on inbound trafic and generate FSC-0048 on  outbound  by 
-     default. A switch on a per-node basis will force your software 
-     to be FSC-0039 or even FSC-0001 only,  and you will cover  all 
-     bases.
-
-     This can be done easily, as FSC-0048 is a superset of FSC-0039 
-     (The -1 thing on points being the difference) which in turn is 
-     a superset of FTS-0001 (CW). I'd be glad to get some feedback. 
-     You can put it in NET_DEV or netmail me.
-
-                              Jan Vroonhof (2:281/1.12@fidonet)
-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0049.html b/html/ftsc/fsc-0049.html deleted file mode 100755 index d6be8505..00000000 --- a/html/ftsc/fsc-0049.html +++ /dev/null @@ -1,104 +0,0 @@ - - - -A Proposal for Passing Domain Information During an FST-0006 Session. - - - - -
-Document: FSC-0049
-Version:  001
-Date:     03-Jul-90
-
-
-
-
-                               A Proposal for
-                         Passing Domain Information
-                         During an FTS-0006 Session
-
-                                     by
-                                Bob Hartman
-                           1:104/501@fidonet.org
-                                July 3, 1990
-
-
-
-
-Status of this document:
-
-     This FSC suggests a proposed protocol for the FidoNet(r) community,
-     and requests discussion and suggestions for improvements.
-     Distribution of this document is unlimited.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-
-FSC-0045 proposes a method for sending five dimensional FidoNet addresses
-(ie, zone:net/node.point@domain) via the type 2 packet header.  This
-document describes a proposed method for sending the same five dimensional
-address in the Hello packet of an FTS-0006 session, with the additional
-advantage of being able to utilize the full Internet recognized domain name
-for various Fidonet technology networks.  This proposal, combined with
-FSC-0045 will help to solve one of FidoNet's most pressing problems: How to
-recognize alternative networks without the need of some centralized
-management looking at all of them and what they are doing with Zone numbers,
-etc.  Like FSC-0045, this proposal remains backwards compatible with what it
-is replacing.
-
-Currently FTS-0006 has provisions for zone, net, node, and point information
-to be passed in the Hello packet.  To extend this to allow the domain name
-to be passed, an extra capability bit is used.  This bit corresponds to the
-0x4000 bit, and will be called the DO_DOMAIN bit.  If this bit is set, it
-means that the sender is domain aware, and has enclosed his domain in the
-Hello packet.  The domain is stored in the system name field, after the null
-that terminates the real system name.  The system name field is a maximum of
-60 characters, so the sender must make the real system name, a null, the
-domain name, and another null byte fit within the 60 bytes.  The domain will
-start at the byte immediately after the first null byte.  The domain is
-arbitrary length and should correspond to the Internet assigned domain name.
-This is NOT the same as the FSC-0045 domain, and therefore there needs to be
-a mapping between real Internet domains, and the FSC-0045 style domain name,
-if FSC-0045 is accepted by the FTSC as a standard for use by all mailers.
-This mapping is normally straightforward (for example, Internet fidonet.org
-would correspond to FSC-0045 domain FidoNet).  Since most alternative nets
-do not have a registered Internet domain, the naming convention should be
-"known by" domain (ie, FSC-0045 domain name) followed by .ftn (for FidoNet
-Technology Network).  So, the FSC-0045 domain "Alternet" would be converted
-to alternet.ftn under this proposal.  This allows domains which are not
-normally FidoNet aware to use FTS-0006 to talk to FidoNet technology mail
-programs.  For example, a mailer located at Camex in Manchester, NH might
-send it's mail as 'man.camex.com' during an FTS-0006 session.  When parsing
-the domain name, the parsing should try to match the domain from right to
-left (Internet naming is hierarchical from right to left), so that if a
-mailer knew about man.camex.com, that could also match something of the form
-super.machine.silly.name.man.camex.com.  The domain name should be case
-INSENSITIVE, and the FSC-0045 abbreviation of it should be unique within the
-first 8 characters, and also should not include any periods ('.') or at-signs
-('@') since those characters are significant in the Internet domain naming
-scheme.
-
-In order for this proposal to be adopted, the FTSC would have to assign the
-DO_DOMAIN bit, and have it documented in FTS-0006.  This method is fully
-backwards compatible, since a domain aware mailer could send the domain
-information, and if the other end was not domain aware, it would ignore it.
-If the other end was domain aware, it would be able to extract the domain
-information easily and would then have a full five dimensional address
-available for the sender.  This proposal remains fully backward compatible
-with the current uses of all FTS-0006 fields, and should not affect operation
-of any mailer that has used reserved bytes in the Hello packet.
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0050.html b/html/ftsc/fsc-0050.html deleted file mode 100755 index bf4677de..00000000 --- a/html/ftsc/fsc-0050.html +++ /dev/null @@ -1,99 +0,0 @@ - - - -A Character Set Identifier For FidoNet Message Editors. - - - - -
-Document: FSC-0050
-Version:  001
-Date:     14-Jul-90
-
-
-
-
-         A Character Set Identifier For FidoNet Message Editors
-
-                                Draft I
-
-                           Thomas Sundblom
-                          2:201/114@fidonet
-
-
-
-			  
-Status of this document:
-
-     This FSC suggests a proposed protocol for the FidoNet(r) community,
-     and requests discussion and suggestions for improvements.
-     Distribution of this document is unlimited.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-
-   Purpose
-
-        This document should serve as a guide for the character set 
-        identifier, CHARSET hereafter, format for FidoNet message Editors.
-        The purpose behind CHARSET is related to my attempt to make it
-        easier for each reader of a FidoNet message to identify the 
-        characters used in the messages.
-
-        Since FidoNet messages aren't restricted to use any special character
-        sets in the messages, there will be differences between computer 
-        kinds and special country dependent characters. To avoid confusion
-        in such cases, I'm hereby introducing the CHARSET kludge.
-
-        There is no need that each FidoNet Message reader should be able
-        to understand every possible character set. If the reader can't
-        handle the special character set found in a message, then it should
-        use a default character set (as most readers do today).
-
-
-   Format
-
-        ^aCHARSET: <Character set identifier>
-
-   Sample
-
-        ^aCHARSET: ISO-11
-
-        Would identify that the message is written using the ISO-11 
-        character set, which relates to the character set mainly used
-        in Sweden.
-
-
-   Supported character sets
-
-        No special character set is specified, but it is recomended to
-        use the ISO numbering of the different character sets. Where no
-        ISO number is available, an easy to understand code should by used.
-
-
-   Character set identifier examples
-
-        ISO-6       Relates to plain ASCII 7 bit character set.
-        ISO-11      Swedish character set, 7 bit.
-        ISO-21      Germany character set, 7 bit.
-        ISO-69      French character set, 7 bit.
-
-        Other character set identifiers could be
-        PC-8        IBM PC complete character set.
-        ATARI       ATARI ST complete character set
-        AMIGA       AMIGA complete character set
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0053.html b/html/ftsc/fsc-0053.html deleted file mode 100755 index bf218b09..00000000 --- a/html/ftsc/fsc-0053.html +++ /dev/null @@ -1,188 +0,0 @@ - - - -Specifications for the ^aFLAGS field. - - - - -
-Document: FSC-0053
-Version:  002
-Date:     08-Dec-92
-
-
-
-
-
-
-                    Specifications for the ^aFLAGS field
-
-                           Joaquim H. Homrighausen
-                       2:270/17@fidonet or joho@ae.lu
-
-                              December 8, 1992
-
-
-
-
-Status of this document:
-
-     This FSC suggests a proposed protocol for the FidoNet(r) community,
-     and requests discussion and suggestions for improvements.
-     Distribution of this document is unlimited.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-
-     Purpose
-
-     To explain and document the existing usage of the ^aFLAGS field used
-     by many software packages, including FrontDoor, TosScan, and
-     D'Bridge. And to inform software authors of its proper usage.
-
-
-     Prologue
-
-     One of the problems with the FTS-1 (stored) message format is its
-     limitations in regards to message attributes. Several bits are used
-     (reserved) by SEAdog, another by several packers and editors - even
-     though most mailer authors don't support them, they remain. One
-     reason would be backward compatibility with older software.
-
-     Unfortunately, this presents a problem for software authors that
-     would like to pass extended message attributes for use and handling
-     by other software.
-
-     Some software packages have been using an alternate method called
-     "FLAGS" which is 7-bit ASCII placed behind FLAGS somewhere near
-     the beginning of a message. The various flags will now be described.
-
-
-     Flags
-
-     The FLAGS string should be placed somewhere near the beginning of
-     the message text, and is preceeded by a <SOH> (^a) character. There
-     is no need to support all or any of the below mentioned flags.
-
-     If flags are stripped when a message passes through a system, all
-     relevant and correct FTS-1 status bits should be updated to indicate
-     the original contents of the FLAGS field.
-
-
-     Flag      Brief          Long description
-     --------------------------------------------------------------------
-     PVT       Private        Indicates that the message may only be read
-                              by its addressee and author.
-
-     HLD       Hold           Message should be held for pickup by its
-                              destination system.
-
-     CRA       Crash          High-priority mail.
-
-     K/S       Kill/Sent      Remove message after it has been success-
-                              fully sent.
-
-     SNT       Sent           Message has been successfully sent (used
-                              for message without Kill/Sent status).
-
-     RCV       Received       Message has been read by its addressee.
-
-     A/S       Archive/Sent   Place message in "sent mail" archival
-                              system after it has been successfully sent.
-
-     DIR       Direct         Message must be sent directly to its
-                              destination and may not be routed.
-
-     ZON       Zonegate       Send message through zonegate (if
-                              possible).
-
-     HUB       Hub/Host-route Host- or Hub-route message (as
-                              appropriate).
-
-     FIL       File attach    Message has one or more files attached to
-                              it.
-
-     FRQ       File request   Message has one or more file requests in
-                              subject field.
-
-     IMM       Immediate      NOW!-priority mail. Send at first
-                              opportunity, override any transmission
-                              restrictions enforced by events, costs, or
-                              qualification.
-
-     XMA       Xmail          Message has alternate form of compressed
-                              mail attached.
-
-     KFS       Kill file      Remove attached file(s) after they have
-                              been successfully sent. Only valid for file
-                              attach message.
-
-     TFS       Truncate file  Truncate attached file(s) to zero length
-                              after they have been successfully sent.
-                              Only valid for file attach message.
-                              Primarily used by Conference Mail
-                              processors.
-
-     LOK       Lock           Prevent message from being processed.
-                              This includes sending, deleting,
-                              purging, and editing.
-
-     RRQ       Receipt REQ    When the mailer/packer at the message's
-                              final destination unpacks the message, it's
-                              asked to generate a receipt to the author
-                              of the message that indicates that the
-                              message arrived at its final destination.
-
-     CFM       Confirm REQ    When message is read by its addressee, a
-                              Confirmation Receipt should be generated to
-                              the author of the message.
-
-     HIR       HiRes          FAX: Hi-Resolution image.
-
-     COV       CoverLetter    FAX: Cover sheet.
-
-     SIG       Signature      FAX: Signature.
-
-     LET       LetterHead     FAX: LetterHead.
-
-|    FAX       Fax image      The filename specified in the message's
-|                             subject field contains a fax document that
-|                             should be viewed using software capable of
-|                             doing so.
-
-|    FPU       Force pickup   Treated as a message with an IMM flag. This
-|                             instructs the mailer to keep calling the
-|                             destination system, if the connection is
-|                             aborted for some reason, until a valid "End
-|                             of files" signal is received (i.e. no more
-|                             files remain to pick up).
-
-
-     Notes
-
-     Xmail is related to the ARCmail 0.60 standard as adopted by the FTSC.
-     The exception is that any type of compression method may be used and
-     the naming convention isn't necessarily limited to that of the
-     ARCmail 0.60 standard.
-
-
-     Epilogue
-
-     Feedback would be appreciated and can be sent to me at the addresses
-     specified on the title page. Please send feedback via netmail.
-
- -BackGo Back - - - - - diff --git a/html/ftsc/fsc-0056.html b/html/ftsc/fsc-0056.html deleted file mode 100755 index 28e2e998..00000000 --- a/html/ftsc/fsc-0056.html +++ /dev/null @@ -1,1079 +0,0 @@ - - - -EMSI/IEMSI Protocol Definitions. - - - - -
-Document: FSC-0056
-Version:  001
-Date:     03-May-1991
-
-
-
-
-
-                      EMSI/IEMSI Protocol Definitions
-                          Joaquim H. Homrighausen
-                               May 3, 1991
- 
-
-
-
-    Status of this document:
-
-     This FSC suggests a proposed protocol for the FidoNet(r) community,
-     and requests discussion and suggestions for improvements.
-     Distribution of this document is subject to the restrictions
-     specified on the next page.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-
-
-
-      (Also known as EMSC-001; Electronic Mail Standards Document #001)
-    ---------------------------------------------------------------------
-      Copyright 1989-1991 Joaquim H. Homrighausen. All rights reserved.
-    ---------------------------------------------------------------------
-
-
-    Notice
-    =====================================================================
-    This document obsoletes EMSI_003 and any previous document describing
-    the EMSI, UZAP, and/or IEMSI handshake protocol. I apologize for the
-    lack of proper state charts. I am currently under a fairly heavy
-    work-load and thought it would be better to release something half-
-    decent than not to release anything at all.
-
-    Restrictions
-    =====================================================================
-    EMSI/IEMSI may be used by any developer as long as these
-    specifications are followed exactly. The IEMSI and EMSI specifications
-    may be implemented independently of each other.
-
-    EMSI/IEMSI may be used free-of-charge by any developer for any
-    purpose, commercially or otherwise. In creating EMSI/IEMSI, we are
-    taking the first step towards developing a clear protocol definition
-    for state-of-the-art E-Mail systems to follow.
-
-    This document and its NOTES file (EMSI.NOT) may be freely copied and
-    distributed, but must NEVER be distributed in a modified form. If you
-    have an enhancement request, please contact the author of this
-    document; do not change it yourself.
-
-    Permission is hereby granted to the FTSC (Fidonet Technical Standards
-    Committee) and other technical organisations to republish this
-    document in its entirety. Librarians may change the title page and
-    page headers to match their library format as long as all copyrights
-    and body text remain unaltered. The original document name and source
-    (EMSC) must be mentioned in any republished versions of this
-    document.
-
-    No organization, company, person, or other being may impose any fees
-    for any reason for providing this document. This document may not be
-    sold or otherwise transferred for personal or company gain under any
-    circumstances.
-
-    Layout
-    =====================================================================
-    This document consists of four major parts; A short introduction and
-    explanation of the EMSI/IEMSI handshake protocol, the EMSI
-    definitions, the IEMSI definitions, and finally various notes and
-    credits.
-
-
-    PART I
-
-    Introduction
-    =====================================================================
-    The EMSI/IEMSI handshake protocol allows for maximum flexibility in
-    E-Mail session start-up and control. The YooHoo (FTS-6) standard,
-    designed by Wynn Wagner III, was a good idea, but did not allow
-    sufficient room for growth and cannot be used in 7-bit environments.
-    EMSI/IEMSI should provide for virtually unlimited growth and
-    expansion of its own scope. By providing variable-length packets,
-    EMSI/IEMSI is capable of being as simple or as complex as necessary
-    and entirely backwards compatible when new features and/or protocols
-    are added.
-
-    All EMSI/IEMSI packets and sequences consists of 7-bit printable
-    ASCII characters. This format allows us to establish a universal
-    handshake between "PCs" and "mainframes" alike. The more complicated
-    the computer system, the more restrictions affect its I/O; there are
-    many I/O channels that cannot transmit control characters such as XON
-    and XOFF; for this, we have created a universal handshake protocol
-    that uses all printable characters.
-
-    EMSI/IEMSI does allow control and 8-bit ASCII characters to be
-    transmitted. This is, however, accomplished by escaping the data
-    and converting it to 7-bit printable ASCII characters.
-
-    Data layer
-    =====================================================================
-    EMSI/IEMSI is a protocol based on multi-character sequences rather
-    than single character flow control. There are several advantages of
-    using several characters rather than just one, but there is also a
-    drawback. On very poor-quality telephone lines, EMSI will most likely
-    require several retransmissions of packets since line noise usually
-    come in bursts. That aside, there is little advantage in using a
-    protocol based on single characters.
-
-    All EMSI/IEMSI sequences are terminated by a single  unless
-    otherwise specified. This is necessary to force some data collection
-    equipment to flush their buffers. Appending  to EMSI/IEMSI
-    sequences in a FidoNet environment is a delicate matter and it is
-    important that you follow the notes regarding this.
-
-    Note regarding file requests
-    ---------------------------------------------------------------------
-    The file request concept mentioned in the EMSI document refers to
-    WaZOO style file requests as specified in FTS-6. No other file
-    request mechanism is supported in the EMSI specifications.
-
-
-    Separator usage
-    ---------------------------------------------------------------------
-    To designate the fields within the EMSI/IEMSI packets and retain
-    complete transparency, both start and stop characters are used.
-
-    The ASCII1 type is used for all fields within the packet. This uses
-    the brace characters to delimit the fields. The '{' (ASCII 123)
-    character is the start byte and '}' (ASCII 125) is the stop byte.
-    If a stop byte is used as literal data within a field, it must be
-    transmitted twice. The end of a field is designated by a stop byte
-    that is not followed by another identical stop byte.
-
-    The ASCII2 fields are delimited in exactly the same way, but use the
-    square brackets as delimiters. The '[' (ASCII 91) is the start byte
-    and ']' (ASCII 93) is the stop byte. ASCII2 is used to delimit data
-    within the ASCII1 extra_field information.
-
-    7-bit data restriction
-    ---------------------------------------------------------------------
-    It is the developer's responsibility to ensure that the software
-    generates EMSI/IEMSI packets and sequences containing only 7-bit
-    (00H through 7eH) printable ASCII characters.
-
-    It is recommended that all EMSI/IEMSI implementations strip the high-
-    order bit of all received characters prior to processing the packet/
-    sequence and prior to calculating CRC values.
-
-    CRC values
-    ---------------------------------------------------------------------
-    The polynomial used to calculate a 16-bit CRC is the same polynomial
-    used in the Xmodem file transfer protocol. The polynomial used to
-    calculate a 32-bit CRC is the same polynomial used in the Zmodem file
-    transfer protocol.
-
-    Binary values
-    ---------------------------------------------------------------------
-    Since the EMSI environment specifies only 7-bit printable ASCII
-    characters to be used, binary values, such as CRC and length
-    descriptors are expressed as a four character hexadecimal string. The
-    only exception to this is a 32-bit CRC value which is expressed as an
-    eight character hexadecimal string.
-
-    The application must treat them case insensitive, eg. ffaa should be
-    treated identical to FFAA. 
-
-
-    Handling 8-bit data
-    ---------------------------------------------------------------------
-    Although EMSI only uses 7-bit printable ASCII characters, there is an
-    escape mechanism that allows systems to transmit control and 8-bit
-    ASCII characters without the requirement of an 8-bit data link. The
-    escape character is a backslash character ('\') and is followed by two
-    characters in hexadecimal notation. Eg. "\80" is the ASCII character
-    128. To insert an actual backslash character, two backslashes are used
-    ("\\"), or a backslash followed by the hexadecimal code for a
-    backslash, eg. "\5c".
-
-    The hexadecimal code following a backslash MUST always be two
-    characters, ie. to insert ASCII 15 (hexadecimail 'f'), the result
-    would be "0f". All hexadecimal sequences must be treated case
-    insensitively.
-
-
-    PART II - Electronic Mail Standard Idenfitication
-
-    Connecting two EMSI capable systems
-    =====================================================================
-    This assumes that the two systems are connected and that no data
-    has been transmitted by the Caller.
-
-    It should be mentioned that sending/monitoring for the "YooHoo",
-    "TSYNC", and other protocol start characters is optional and not
-    required for a strict EMSI implementation.
-
-    STEP 1, EMSI INIT    
-
-        Calling system                   Answering system
-    +-+-------------------------------+----------------------------------+
-    :1: Send <CR> until ANY character : Send EMSI_REQ and possible       :
-    : : is received.                  : banner, etc.                     :
-    +-+-------------------------------+----------------------------------+
-    :2: Receive banner, etc. Monitor  : Monitor line for the EMSI_INQ    :
-    : : line for the EMSI_REQ         : sequence and if received,        :
-    : : sequence and if received,     : attempt to handshake immediately.:
-    : : transmit EMSI_INQ and attempt :                                  :
-    : : to handshake immediately.     :                                  :
-    +-+-------------------------------+----------------------------------+
-    :3: No EMSI_REQ sequence received,: Monitor line for EMSI_INQ and    :
-    : : send EMSI_INQ twice followed  : possible other protocol start    :
-    : : by possible other protocol    : characters and if received,      :
-    : : start characters.             : attempt to handshake immediately.:
-    : :                               :                                  :
-    : : Transmit <CR>                 : Go to step 3.                    :
-    +-+-------------------------------+----------------------------------+
-    :4: If EMSI_REQ sequence received,:
-    : : send EMSI_INQ and attempt to  :
-    : : handshake immediately,        :
-    : : otherwise repeat step 3.      :
-    +-+-------------------------------+
-
-    In steps 1 and 2, both the Calling and Answering system terminate all
-    sequences with <CR>. In step 3, the Calling system does not terminate
-    sequences with <CR> as it is explicitly transmitted after possible
-    protocol start characters. In step 4, the Calling system once again
-    terminate all sequences with a <CR>.
-
-
-    STEP 2A, RECEIVE EMSI HANDSHAKE
-
-    At this point, all sequences are terminated with a <CR>.
-
-    +-+------------------------------------------------------------------+
-    :1: Tries=0, T1=20 seconds, T2=60 seconds                            :
-    +-+------------------------------------------------------------------+
-    :2: Increment Tries                                                  :
-    : :                                                                  :
-    : : Tries>6?                      Terminate, and report failure.     :
-    : +------------------------------------------------------------------+
-    : : Are we answering system?      Transmit EMSI_REQ, go to step 3.   :
-    : +------------------------------------------------------------------+
-    : : Tries>1?                      Transmit EMSI_NAK, go to step 3.   :
-    : +------------------------------------------------------------------+
-    : : Go to step 4.                                                    :
-    +-+------------------------------------------------------------------+
-    :3: T1=20 seconds                                                    :
-    +-+------------------------------------------------------------------+
-    :4: Wait for EMSI sequence until EMSI_HBT or EMSI_DAT or any of the  :
-    : : timers have expired.                                             :
-    : :                                                                  :
-    : : If T2 has expired, terminate call and report failure.            :
-    : +------------------------------------------------------------------+
-    : : If T1 has expired, go to step 2.                                 :
-    : +------------------------------------------------------------------+
-    : : If EMSI_HBT received, go to step 3.                              :
-    : +------------------------------------------------------------------+
-    : : If EMSI_DAT received, go to step 5.                              :
-    : +------------------------------------------------------------------+
-    : : Go to step 4.                                                    :
-    +-+------------------------------------------------------------------+
-    :5: Receive EMSI_DAT packet                                          :
-    : +------------------------------------------------------------------+
-    : : Packet received OK?                Transmit EMSI_ACK twice, and  :
-    : :                                    go to step 6.                 :
-    : +------------------------------------------------------------------+
-    : : Go to step 2.                                                    :
-    +-+------------------------------------------------------------------+
-    :6: Received EMSI_DAT packet OK, exit.                               :
-    +-+------------------------------------------------------------------+
-
-    All processing of the information in the EMSI_DAT packet must be done
-    after transmitting EMSI_ACK twice to the remote system. It is
-    recommended that an EMSI_HBT sequence is issued once every seven
-    seconds while such processing is taking place to avoid unnecessary
-    handshake collissions. Emitting EMSI_HBT should only be done when
-    it is obvious that the remote system is waiting for the second phase
-    of the EMSI handshake to take place.
-
-
-
-    STEP 2B, TRANSMIT EMSI HANDSHAKE
-
-    At this point, all sequences are terminated with a <CR>.
-
-    +-+------------------------------------------------------------------+
-    :1: Tries=0, T1=60 seconds                                           :
-    +-+------------------------------------------------------------------+
-    :2: Transmit EMSI_DAT packet and increment Tries                     :
-    : :                                                                  :
-    : +------------------------------------------------------------------+
-    : : Tries>6?                        Terminate, and report failure.   :
-    : +------------------------------------------------------------------+
-    : : Go to step 3.                                                    :
-    +-+------------------------------------------------------------------+
-    :3: T2=20 seconds                                                    :
-    +-+------------------------------------------------------------------+
-    :4: Wait for EMSI sequence until T1 has expired                      :
-    : :                                                                  :
-    : : If T1 has expired, terminate call and report failure.            :
-    : +------------------------------------------------------------------+
-    : : If T2 has expired, go to step 2.                                 :
-    : +------------------------------------------------------------------+
-    : : If EMSI_REQ received, go to step 4.                              :
-    : +------------------------------------------------------------------+
-    : : If EMSI_ACK received, go to step 5.                              :
-    : +------------------------------------------------------------------+
-    : : If any other sequence received, go to step 2.                    :             :
-    +-+------------------------------------------------------------------+
-    :5: Received EMSI_ACK, exit.                                         :
-    +-+------------------------------------------------------------------+
-
-
-    EMSI packet and sequence definitions
-    =====================================================================
-
-    =====================================================================
-    EMSI Inquiry                                    **EMSI_INQ<crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI Inquiry is transmitted by the calling system to identify it as
-    EMSI capable. If an EMSI_REQ sequence is received in response, it is
-    safe to assume the answering system to be EMSI capable.
-
-    =====================================================================
-    EMSI Request                                    **EMSI_REQ<crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI Request is transmitted by the answering system in response to an
-    EMSI Inquiry sequence. It should also be transmitted prior to or
-    immediately following the answering system has identified itself by
-    transmitting its program name and/or banner. If the calling system
-    receives an EMSI Request sequence, it can safely assume that the
-    answering system is EMSI capable.
-    
-    =====================================================================
-    EMSI Client                                     **EMSI_CLI<crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI Client is used by terminal emulation software to force a mailer
-    front-end to bypass any unnecessary mail session negotiation and
-    treat the call as an incoming human caller. The EMSI_CLI sequence may
-    not be issued by any software attempting to establish a mail session
-    between two systems and must only be acted upon by an answering
-    system.
-
-    =====================================================================
-    EMSI Heartbeat                                  **EMSI_HBT<crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI Heartbeat is used to prevent unnecessary timeouts from occurring
-    while attempting to handshake. It is most commonly used when the
-    answering system turns around to transmit its EMSI_DAT packet. It is
-    quite normal that any of the timers of the calling system (which at
-    this stage is waiting for an EMSI_DAT packet) expires while the
-    answering system is processing the recently received EMSI_DAT packet.
-
-    =====================================================================
-    EMSI Data                      **EMSI_DAT<len16><data_pkt><crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI Data is transmitted by both the calling and answering system at
-    the appropriate time to exchange system information. Following the
-    header is a four byte number representing the length of <data_pkt>
-    excluding the CRC and terminating <CR>.
-
-    The EMSI_DAT packet is a variable length packet. Since this is a
-    synchronous protocol, the inbound data buffer should be purged
-    between transmission of the <data_pkt> and <crc16> fields to prevent
-    accidental EMSI_NAK sequences, etc.
-
-
-    =====================================================================
-    EMSI ACK                                        **EMSI_ACK<crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI ACK is transmitted by either system as a positive
-    acknowledgement of the valid receipt of a EMSI_DAT packet. This should
-    only be used as a response to EMSI_DAT and not any other packet.
-    Redundant EMSI_ACK sequences should be ignored.
-
-    =====================================================================
-    EMSI NAK                                        **EMSI_NAK<crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI NAK is transmitted by either system as a negative
-    acknowledgement of the valid receipt of a EMSI_DAT packet. This
-    should only be used as a response to EMSI_DAT and not any other
-    packet. Redundant EMSI_NAK packets should be ignored.
-
-    The EMSI_DAT packet
-    =====================================================================
-    The EMSI_DAT packet is the core of an EMSI negotiated session. It
-    contains information vital to the mail session. The following pseudo
-    structure shows the layout of the EMSI_DAT packet.
-
-    EMSI_DAT
-        fingerprint,            "EMSI"
-        system_address_list,
-        password,
-        link_codes,
-        compatibility_codes,
-        mailer_product_code,
-        mailer_name,
-        mailer_version,
-        mailer_serial_number:    ASCII1;
-        extra_field_1,
-            ..
-            ..
-        extra_field_n:            EMSI_addon; (optional fields)
-    end;
-
-    The EMSI_addon structure is defined as follows:
-
-    EMSI_addon
-        product_ID,
-        specific_data:            ASCII1;
-    end;
-
-
-    Following is an example of the actual data transmitted as an EMSI_DAT
-    packet:
-
-    {EMSI}{2:270/17}{}{8N1,PUA}{ZAP,ZMO,ARC,XMA}{44}{AirMail}{0.10}
-    {Beta-2}{IDENT}{[Advanced Engineering S.A.R.L.][Luxembourg]
-    [Joaquim Homrighausen][-Unpublished-][9600][MO,XA,HST,V32B,V42B]}
-
-    EMSI_DAT field definitions
-    ---------------------------------------------------------------------
-    
-    =====================================================================
-    Fingerprint                                                      EMSI
-    ---------------------------------------------------------------------
-    The constant "EMSI". There is no need for a revision level since this    
-    basic format cannot change and remain backward compatible.
-
-    =====================================================================
-    System address list
-    ---------------------------------------------------------------------
-    The system address list is a list of system-specific identifiers for
-    the E-Mail system separated by spaces.
-
-    For FidoNet-technology based networks, it is required that
-    Zone:Net/Node be presented, and .Point be omitted if zero. Zone and
-    Net must not be zero.
-
-    In other networks, an address such as "jhom@csource.oz.au" should be
-    considered valid.
-
-    =====================================================================
-    Password
-    ---------------------------------------------------------------------
-    For systems using a session level password, it would be passed in
-    this field. Note that the same password is used for all presented
-    addresses and that it must be treated case insensitive.
-
-    =====================================================================
-    Link codes
-    ---------------------------------------------------------------------
-    Link codes is a string of flags that specify desired connect
-    conditions. These codes are separated by commas. New codes may be
-    added with prior approval from the author of this document.
-
-    Calling system/answering system options:
-
-        8N1,
-        7E1,
-        7O2,
-        etc.       Communication parameters.
-
-    Calling system options:
-
-        PUA        Pickup mail for all presented addresses.
-        PUP        Pickup mail for primary address only.
-        NPU        No mail pickup desired.
-
-
-    Answering system options:
-
-        HAT        Hold ALL traffic.
-        HXT        Hold compressed mail traffic.
-        HRQ        Hold file requests (not processed at this time).
-
-    =====================================================================
-    Compatibility codes
-    ---------------------------------------------------------------------
-    Compatibility codes is a string of flags that specifies the
-    capabilities and enabled features of the mailer. These codes are
-    separated by commas. New codes may be added with prior approval from
-    the author of this document.
-     
-    The calling system must list supported protocols first and descending
-    order of preference (the most desirable protocol should be listed
-    first). The answering system should only present one protocol and it
-    should be the first item in the compatibility_codes field.
-
-        Protocols
-        -----------------------------------------------------------------
-        DZA*    DirectZAP (Zmodem variant).
-        ZAP     ZedZap (Zmodem variant).
-        ZMO**   Zmodem w/1,024 byte data packets.
-        JAN     Janus.
-        KER     Kermit.
-
-        Other codes
-        -----------------------------------------------------------------
-        NCP     No compatible protocols (failure).
-        NRQ     No file requests accepted by this system.
-        ARC     ARCmail 0.60-capable, as defined by the FTSC.
-        XMA     Supports other forms of compressed mail.
-        FNC     Filename conversion. This indicates that any transmitted
-                files must follow the MS-DOS restrictions of an eight
-                character file name followed by a three character
-                extension; eg. FILENAME.EXT
-
-    (*) DirectZAP is a variant of ZedZap. The difference is that the
-    transmitter only escapes CAN (18H). It is not recommended to use the
-    DirectZAP protocol when two systems are connected via a packet
-    switching network, or via another layer sensitive to control
-    characters such as XON and XOFF.
-
-    (**) The minimum protocol requirement for an EMSI implementation is
-    to support plain Zmodem (16- or 32-bit CRC, 1,024 byte packets) which
-    is represented by the ZMO flag in EMSI.
-
-    =====================================================================
-    Mailer product code
-    ---------------------------------------------------------------------
-    The hexadecimal representation of the EMSC product code assigned to
-    the mailer. Currently, the EMSC codes are the same as the FTSC
-    assigned codes.
-
-    =====================================================================
-    Mailer name
-    ---------------------------------------------------------------------
-    Specifies the name of the E-Mail system sending the EMSI packet.
-
-    =====================================================================
-    Mailer version
-    ---------------------------------------------------------------------
-    The version number of the mailer software, ie. "1.10", "2.00".
-
-    =====================================================================
-    Mailer serial number
-    ---------------------------------------------------------------------
-    The serial number, distribution source, version information, etc.
-    This field is usually displayed like:
-
-        NameVersion/Serial_number
-
-    eg.
-
-        AirMail 0.10/Beta-2
-
-    =====================================================================
-    Extra fields
-    ---------------------------------------------------------------------
-    The extra fields make the EMSI handshake protocol extremely flexible.
-    Any program or mailer may add fields to the end of the pre-defined
-    structure so that program-specific data may be passed without the
-    concern of interferring with other systems.
-
-    There may be any number of extra fields added to the end of this
-    structure. Each EXTRA_FIELD contains two ASCII1 strings:
-
-    PRODUCT_IDENTIFIER      A unique "tag" that defines a specific
-                            program (such as a mailer or a utility).
-
-    SPECIFIC_DATA           ASCII text that is specific data to the
-                            program defined in PRODUCT_IDENTIFIER. With
-                            this structure, any program can add its own
-                            data to the EMSI packet without affecting
-                            other applications.
-
-    It is recommended that you contact the author of this document should
-    you have any EXTRA_FIELDS that you may think worthwhile for other
-    developers to implement and support.
-
-    Predefined extra fields
-    ---------------------------------------------------------------------
-    The following extra fields have been defined to date.
-
-    PRODUCT_IDENTIFIER   :  IDENT
-
-    Purpose              :  General identification of system that
-                            includes all information to generate a St.
-                            Louis-format nodelist entry.
-
-    SPECIFIC_DATA        :  system_name,
-                            city,
-                            operator_name,
-                            phone_number,
-                            baud_rate,
-                            flags:            ASCII2;
-
-        SYSTEM_NAME         The name of the system given by the user.
-                            This would normally be a company name, BBS
-                            name or other identifying text.
-
-        CITY                The geographical location of the system.
-
-        OPERATOR_NAME       The name of the person primarily responsible
-                            for the system.
-
-        PHONE_NUMBER        The telephone number of the system, or
-                            "-Unpublished-" if the telephone number is
-                            unpublished. This MUST be in the standard
-                            format COUNTRY-CITY-NUMBER. Leading zeros
-                            should be stripped from the city code,
-                            ie. Stockholm (Sweden) has a city code of 08,
-                            included in an EMSI packet, it would read
-                            46-8-<number>.
-
-        BAUD_RATE           The maximum baud rate supported by the
-                            system. This is NOT necessarily the same as
-                            the highest DTE rate.
-
-        FLAGS               The St. Louis (FTSC) nodelist flags
-                            associated with the system.
-
-
-    PART III - Interactive Electronic Mail Standard Idenfitication
-
-    Connecting two IEMSI capable systems
-    =====================================================================
-    Two specific labels are used when discussing the IEMSI definitions.
-    The Client, which in this case is the Terminal software, and the
-    Server, which in this case is the interactive on-line software,
-    such as a BBS package or database system. It is assumed that the
-    Client and the Server have established a data link and that no
-    data has been transmitted by the Server.
-
-    STEP 1, IEMSI INIT    
-
-    There is no specific sequence of events in the IEMSI definition. The
-    Client must monitor incoming data and if the EMSI_IRQ sequence is
-    detected, it attempts to negotiate an IEMSI session with the Server.
-    Under no circumstances is the Client allowed to transmit an EMSI_ICI
-    packet prior to receiving the EMSI_IRQ sequence from the Server.
-    All IEMSI sequences and EMSI sequences used during an IEMSI session
-    are terminated by a single . There are no exceptions to this.
-
-
-    STEP 2A, Server
-
-    +-+------------------------------------------------------------------+
-    :1: Tries=0, T2=60 seconds                                           :
-    +-+------------------------------------------------------------------+
-    :2: Transmit EMSI_IRQ sequence                                       :
-    +-+------------------------------------------------------------------+
-    :3: T1=20 seconds, increment Tries                                   :
-    : :                                                                  :
-    : : Tries>3?                        Discontinue IEMSI negotiation.   :
-    +-+------------------------------------------------------------------+
-    :4: Wait for EMSI_ICI packet until any of the timers have expired.   :
-    : :                                                                  :
-    : : If T2 has expired, discontinue IEMSI negotiation.                :
-    : +------------------------------------------------------------------+
-    : : If T1 has expired, go to step 2.                                 :
-    : +------------------------------------------------------------------+
-    : : If EMSI_ICI seen, go to step 5.                                  :
-    : +------------------------------------------------------------------+
-    : : Go to step 4.                                                    :
-    +-+------------------------------------------------------------------+
-    :5: Receive EMSI_ICI packet                                          :
-    : +------------------------------------------------------------------+
-    : : Packet received OK?             Transmit EMSI_ISI packet, and    :
-    : :                                 go to step 6.                    :
-    : +------------------------------------------------------------------+
-    : : Packet not received OK?         Transmit EMSI_NAK and go to step :
-    : :                                 3.                               :
-    +-+------------------------------------------------------------------+
-    :6: Tries=0                                                          :
-    +-+------------------------------------------------------------------+
-    :7: T1=20 seconds, increment Tries                                   :
-    : :                                                                  :
-    : : Tries>3?                        Discontinue IEMSI negotiation.   :
-    +-+------------------------------------------------------------------+
-    :8: Wait for EMSI_ACK/EMSI_NAK until any of the timers have expired. :
-    : :                                                                  :
-    : : If T2 has expired, discontinue IEMSI negotiation.                :
-    : +------------------------------------------------------------------+
-    : : If T1 has expired or EMSI_NAK received, transmit EMSI_ISI packet :
-    : : again and go to step 7.                                          :
-    : +------------------------------------------------------------------+
-    : : If EMSI_ACK received, go to step 9.                              :
-    : +------------------------------------------------------------------+
-    : : Go to step 8.                                                    :
-    +-+------------------------------------------------------------------+
-    :9: IEMSI session successfully established, exit.                    :
-    +-+------------------------------------------------------------------+
-
-    The Server must monitor its incoming data channel for 'normal' data,
-    ie. data not transmitted as IEMSI sequences, to detect if the user is
-    attempting to log-in without the use of IEMSI. The only basic
-    restriction this imposes on the Server is that user names and/or IDs
-    may not start with the character '*' since all EMSI/IEMSI sequences
-    start with this character.
-
-    All processing of the information in the EMSI_ICI packet must be done
-    after transmitting the EMSI_ISI packet and receiving two EMSI_ACK
-    sequences in return.
-
-
-    STEP 2B, Client
-
-    Note that this assumes that the Client has seen the EMSI_IRQ sequence
-    transmitted by the Server and that the negotiation is ready to take
-    place.
-
-    +-+------------------------------------------------------------------+
-    :1: Tries=0, T2=60 seconds                                           :
-    +-+------------------------------------------------------------------+
-    :2: Transmit EMSI_ICI packet                                         :
-    +-+------------------------------------------------------------------+
-    :3: T1=20 seconds, increment Tries                                   :
-    +-+------------------------------------------------------------------+
-    :5: Tries>3 or T2 expired?            Discontinue IEMSI negotiation. :
-    : +------------------------------------------------------------------+
-    : : If T1 has expired, go to step 2.                                 :
-    : +------------------------------------------------------------------+
-    : : If EMSI_ISI seen, go to step 6.                                  :
-    : +------------------------------------------------------------------+
-    : : Go to step 5.                                                    :
-    +-+------------------------------------------------------------------+
-    :6: Receive EMSI_ISI packet                                          :
-    : +------------------------------------------------------------------+
-    : : Packet received OK?              Transmit EMSI_ACK packet twice, :
-    : :                                  and go to step 7.               :
-    : +------------------------------------------------------------------+
-    : : Packet not received OK?          Transmit EMSI_NAK and go to step:
-    : :                                  3.                              :
-    +-+------------------------------------------------------------------+
-    :7: IEMSI session successfully established, exit.                    :
-    +-+------------------------------------------------------------------+
-
-    All processing of the information in the EMSI_ISI packet must be done
-    after transmitting two EMSI_ACK sequences in return.
-
-    If either of the ICI or ISI packets are NAK'd three consecutive times,
-    the session negotiation attempt is terminated and the Client proceeds
-    as it would have done should the Server not have supported IEMSI.
-
-
-    IEMSI packet and sequence definitions
-    =====================================================================
-
-    =====================================================================
-    EMSI ACK                                        **EMSI_ACK<crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI ACK is transmitted by either Client or Server as a positive
-    acknowledgement of the valid receipt of an IEMSI packet such as
-    EMSI_ISI and EMSI_ICI. During an IEMSI session, this sequence can,
-    however, be used as a positive acknowledgement for other IEMSI
-    packets. Redundant EMSI_ACK sequences should be ignored.
-
-    =====================================================================
-    EMSI NAK                                        **EMSI_NAK<crc16><CR>
-    ---------------------------------------------------------------------
-    EMSI NAK is transmitted by either Client or Server as a negative
-    acknowledgement of the valid receipt of an IEMSI packet such as
-    EMSI_ISI and EMSI_ICI. During an IEMSI session, this sequence can,
-    however, be used as a negative acknowledgement for other IEMSI
-    packets. Redundant EMSI_NAK sequences should be ignored.
-
-    =====================================================================
-    EMSI IRQ                                        **EMSI_IRQ<crc16><CR>
-    ---------------------------------------------------------------------
-    Similar to EMSI_REQ which is used by mailer software to negotiate a
-    mail session. IRQ identifies the Server as being capable of
-    negotiating an IEMSI session. When the Client detects an IRQ sequence
-    in its inbound data stream, it attempts to negotiate an IEMSI
-    session.
-
-    =====================================================================
-    EMSI IIR                                        **EMSI_IIR<crc16><CR>
-    ---------------------------------------------------------------------
-    The IIR (Interactive Interrupt Request) sequence is used by either
-    Client or Server to abort the current negotiation. This could be
-    during the initial IEMSI handshake or during other interactions
-    between the Client and the Server.
-
-    =====================================================================
-    EMSI ICI                             **EMSI_ICI<len><data><crc32><CR>
-    ---------------------------------------------------------------------
-    The ICI packet is used by the Client to transmit its configuration
-    and Server-related information to the Server. It contains Server
-    parameters, Client options, and Client capabilities.
-
-    =====================================================================
-    EMSI ISI                             **EMSI_ISI<len><data><crc32><CR>
-    ---------------------------------------------------------------------
-    The ISI packet is used by the Server to transmit its configuration
-    and Client-related information to the Client. It contains Server data
-    and capabilities.
-
-    =====================================================================
-    EMSI ISM                             **EMSI_ISM<len><data><crc32><CR>
-    ---------------------------------------------------------------------
-    The ISM packet is used to transfer ASCII images from the Server to
-    the Client. These images can then be recalled by the Client when
-    the Server needs to display a previously displayed image. This will
-    be further described in future revisions of this document.
-
-    =====================================================================
-    EMSI CHT                                        **EMSI_CHT<crc16><CR>
-    ---------------------------------------------------------------------
-    The CHT sequence is used by the Server to instruct the Client
-    software to enter its full-screen conversation mode function (CHAT).
-    Whether or not the Client software supports this is indicated in the
-    ICI packet.
-
-    If the Server transmits this sequence to the Client, it must wait for
-    an EMSI_ACK prior to engaging its conversation mode. If no EMSI_ACK
-    sequence is received with ten seconds, it is safe to assume that the
-    Client does not support EMSI_CHT. If, however, an EMSI_NAK sequence
-    is received from the Client, the Server must re-transmit the
-    EMSI_CHT sequence. Once the on-line conversation function has been
-    sucessfully activated, the Server must not echo any received
-    characters back to the Client.
-
-    =====================================================================
-    EMSI TCH                                        **EMSI_TCH<crc16><CR>
-    ---------------------------------------------------------------------
-    The TCH sequence is used by the Server to instruct the Client
-    software to terminate its full-screen conversation mode function
-    (CHAT).
-
-    If the Server transmits this sequence to the Client, it must wait for
-    an EMSI_ACK prior to leaving its conversation mode. If no EMSI_ACK
-    sequence is received with ten seconds, a second EMSI_TCH sequence
-    should be issued before the Server resumes operation. If, however, an
-    EMSI_NAK sequence is received from the Client, the Server must
-    re-transmit the EMSI_TCH sequence.
-
-
-    The EMSI_ICI packet
-    =====================================================================
-    The following pseudo structure shows the layout of the EMSI_ICI
-    packet. Note that the information in the EMSI_ICI packet may not
-    exceed 2,048 bytes.
-
-    EMSI_ICI
-        name,
-        alias,
-        location,
-        data#,
-        voice#,
-        password,
-        birthdate,
-        crtdef,
-        protocols,
-        capabilities,
-        requests,
-        software,
-        xlattabl:                ASCII1;
-    end;
-
-    EMSI_ICI field definitions
-    ---------------------------------------------------------------------
-    
-    =====================================================================
-    Name and Alias (or Handle)
-    ---------------------------------------------------------------------
-    The name and possible alias (AKA) of the user (Client). This must be
-    treated case insensitively by the Server.
-
-    =====================================================================
-    Location
-    ---------------------------------------------------------------------
-    The geographical location of the user, ie. Stockholm, Sweden.
-
-    =====================================================================
-    data# and voice#
-    ---------------------------------------------------------------------
-    Unformatted data and voice telephone numbers of the user. Unformatted
-    is defined as the full telephone number, including country and local
-    area code. Eg. 46-8-90510 is a telephone number in Stockholm, Sweden.
-
-    =====================================================================
-    Password
-    ---------------------------------------------------------------------
-    The password for the user. This must be treated case insensitively by
-    the Server.
-
-    =====================================================================
-    Birthdate
-    ---------------------------------------------------------------------
-    Hexadecimal string representing a long integer containing the birth-
-    date of the user in UNIX notation (number of seconds since midnight,
-    Jan 1 1970). This must be treated case insensitively by the Server.
-
-    =====================================================================
-    CrtDef
-    ---------------------------------------------------------------------
-    Consisting of four sub-fields separated by commas, this field
-    contains from left to right: The requested terminal emulation
-    protocol, the number of rows of the user's CRT, the number of columns
-    of the user's CRT, and the number of ASCII NUL (00H) characters the
-    user's software requires to be transmitted between each line of text.
-
-    The following terminal emulation protocols are defined:
-
-        AVT0    AVATAR/0+. Used in conjunction with ANSI. If AVT0 is
-                specified by the Client, support for ANSI X3.64 emulation
-                should be assumed to be present.
-        ANSI    ANSI X3.64
-        VT52    DEC VT52
-        VT100   DEC VT100
-        TTY     No terminal emulation, also referred to as RAW mode.
-
-    =====================================================================
-    Protocols
-    ---------------------------------------------------------------------
-    The file transfer protocol option specifies the preferred method of
-    transferring files between the Client and the Server in either
-    direction. The Client presents all transfer protocols it is capable
-    of supporting and the Server chooses the most appropriate protocol.
-
-        DZA*    DirectZAP (Zmodem variant)
-        ZAP     ZedZap (Zmodem variant)
-        ZMO     Zmodem w/1,024 byte data packets
-        SLK     SEAlink
-        KER     Kermit
-    
-    (*) DirectZAP is a variant of ZedZap. The difference is that the
-    transmitter only escapes CAN (18H). It is not recommended to use the
-    DirectZAP protocol when the Client and the Server are connected via a
-    packet switching network, or via another layer sensitive to control
-    characters such as XON and XOFF.
-
-
-    =====================================================================
-    Capabilities
-    ---------------------------------------------------------------------
-    The capabilities of the user's software. If more than one capability
-    is listed, each capability is separated by a comma.
-
-    The following capability codes are defined:
-
-        CHT     Can do full-screen on-line conversation (CHAT).
-        MNU     Can do ASCII image download (see ISM packet).
-        TAB     Can handle TAB (ASCII 09H) characters.
-        ASCII8  Can handle 8-bit IBM PC ASCII characters.
-
-    =====================================================================
-    Requests
-    ---------------------------------------------------------------------
-    The requests field specifies what the user wishes to do once the
-    initial IEMSI negotiation has been successfully completed. If more
-    than one capability is listed, each capability is separated by a
-    comma.
-
-    The following request codes are defined:
-
-        NEWS    Show bulletins, announcements, etc.
-        MAIL    Check for new mail.
-        FILE    Check for new files.
-        HOT     Hot-Keys.
-        CLR     Screen clearing.
-        HUSH    Do not disturb.
-        MORE    Page pausing, often referred to as "More".
-        FSED*   Full-screen editor.
-        XPRS    <reserved>.
-
-    (*) Note that this allows the Client to request use of a full-screen
-    editor without requiring that it also supports a full-screen terminal
-    emulation protocol.
-
-    =====================================================================
-    Software
-    ---------------------------------------------------------------------
-    The name, version number, and optionally the serial number of the
-    user's software. Eg. {FrontDoor,2.00,AE000001}.
-
-    =====================================================================
-    XlatTabl
-    ---------------------------------------------------------------------
-    Used for character translation between the Server and the Client.
-    This field has not been completely defined yet and should always be
-    transmitted as {} (empty).
-
-
-    The EMSI_ISI packet
-    =====================================================================
-    The following pseudo structure shows the layout of the EMSI_ISI
-    packet. Note that the information in the EMSI_ISI packet may not
-    exceed 2,048 bytes.
-
-    EMSI_ISI
-        id,
-        name,
-        location,
-        operator,
-        localtime,
-        notice,
-        wait,
-        capabilities:            ASCII1;
-    end;
-
-    EMSI_ISI field definitions
-    ---------------------------------------------------------------------
-    
-    =====================================================================
-    ID
-    ---------------------------------------------------------------------
-    The name, version number, and optionally the serial number of the
-    Server software. Eg. {RemoteAccess,1.10/b5,CS000001}.
-
-    =====================================================================
-    Name
-    ---------------------------------------------------------------------
-    The name of the Server system. Eg. {Advanced Engineering S.A.R.L.}.
-
-    =====================================================================
-    Location
-    ---------------------------------------------------------------------
-    The geographical location of the user, ie. Stockholm, Sweden.
-
-    =====================================================================
-    Operator
-    ---------------------------------------------------------------------
-    The name of the primary operator of the Server software. Eg. {Joaquim
-    H. Homrighausen}.
-
-
-
-    =====================================================================
-    Localtime
-    ---------------------------------------------------------------------
-    Hexadecimal string representing a long integer containing the current
-    time of the Server in UNIX notation (number of seconds since midnight,
-    Jan 1 1970). This must be treated case insensitively by the Client.
-
-    =====================================================================
-    Notice
-    ---------------------------------------------------------------------
-    May contain copyright notices, system information, etc. This field
-    may optionally be displayed by the Client.
-
-    =====================================================================
-    Wait
-    ---------------------------------------------------------------------
-    A single character used by the Server to indicate that the user
-    has to press the <Enter> key to resume operation. This is used in
-    conjunction with ASCII Image Downloads (see ISM packet).
-
-    =====================================================================
-    Capabilities
-    ---------------------------------------------------------------------
-    The capabilities of the Server software. No Server software
-    capabilities have currently been defined.
-
-    Credits and other notes
-    =====================================================================
-    The original EMSI specifications were designed by Chris Irwin and
-    Joaquim H. Homrighausen. The original IEMSI specifications were
-    designed by Joaquim H. Homrighausen and Andrew Milner.
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0057.html b/html/ftsc/fsc-0057.html deleted file mode 100755 index 6f6b0cb0..00000000 --- a/html/ftsc/fsc-0057.html +++ /dev/null @@ -1,534 +0,0 @@ - - - -Conference Managaers - Specifications for Requests. - - - - -
-Document: FSC-0057
-Version:  003
-Date:     07-Dec-92
-
-
-
-
-               Conference Managers - Specifications for Requests
-
-                               December 7, 1992
-
-                   Fabiano Fabris      Joaquim H. Homrighausen
-                2:285/304.100@fidonet      2:270/17@fidonet
-
-
-
-
-    Status of this document:
-
-    This FSC suggests a proposed protocol for the FidoNet(r) community, and
-    requests discussion and suggestions for improvements. Revision 3
-    presents several additions and enhancements over the previous revision.
-
-    Distribution of this document is unlimited.
-
-    Fido and FidoNet are registered marks of Tom Jennings and Fido
-    Software.
-
-
-
-    1  Purpose
-
-       This document will explore the methods implemented by various
-       conference managers which process requests (in net mail form)
-       for changes to the conference mail links on the system on which
-       they are in use.
-
-       Until now, it would appear that no real standard exists, so most
-       software authors have either tried to emulate another program, or
-       to create a new method of their own, or both.
-
-       Here, an attempt will be made to define a standard, one which tries
-       to maintain compatibility with methods already in use, while also
-       extending them to provide new functions.
-
-
-
-    2  Conventions
-
-       The names of the commands described in the following paragraphs are
-       given in upper case, for legibility. However, a conference manager
-       should be able to interpret them even if they are given in lower
-       or mixed case.
-
-       Similarly, conference names, or tags, are given in upper case, but
-       the conference manager should be able to handle them even if typed
-       in lower or mixed case.
-
-       Optional information is enclosed with square brackets, while
-       variable information is enclosed with angle brackets. For example:
-
-          +CONF [,R=<n>]
-
-       indicates that the section within square brackets is optional, and
-       if supplied, requires a parameter after the equals sign.
-
-       Some conference managers may allow commands to be abbreviated to the
-       shortest non-ambiguous string. For example, %LIST might be reduced
-       to %L.
-
-
-
-    3  Format of the request
-
-       A request to a conference manager is generally made in a net mail
-       message containing specific information in some of the fields. In
-       particular, the addressee is the name of the conference manager
-       itself, and the subject of the message is a password assigned by
-       the sysop of the system running the program.
-
-       For example:
-
-          From:     John Doe, on 2:123/56
-          To:       Program,  on 2:234/0
-          Subject:  password
-
-       Here the first problem is encountered. Each of the existing programs
-       recognizes a different addressee. For this reason it is proposed
-       that all such programs recognize requests made to a single,
-       "standard" addressee, besides any other they may wish to implement.
-       The term "ConfMgr" has been arbitrarily chosen, and should be used
-       by those programs which adhere fully to all the standards proposed
-       in this document.
-
-       The text of the message itself contains the request proper, and is
-       the subject of the following paragraphs.
-
-
-
-    4  Linking and Unlinking of conferences.
-
-       The current methods for requesting that a conference be linked are
-       basically two:
-
-          +CONFNAME
-          CONFNAME
-
-       For reasons of uniformity, it is proposed that all conference
-       manager programs recognize the first method.
-
-       Requests that a conference be unlinked are given by:
-
-          -CONFNAME
-
-       It might be interesting to implement some form of pattern matching,
-       similar to the unix shell. The following basic wildcards should be
-       considered:
-
-          *        matches zero or more characters
-          ?        matches any one (not zero) character
-
-       Since the requests are processed top-down, a request of the form
-
-          +CONFNAME
-          -*
-
-       would be redundant, since the ConfMgr would link CONFNAME from the
-       first line, and then immediately unlink it again because of the
-       second line, which requests that all linked conferenecs be unlinked.
-
-       It should also be possible to specify more than one conference tag
-       on the same line. For example:
-
-          +CONF1 CONF2 CONF3
-
-       would link the three conferences CONF1, CONF2 and CONF3.
-
-
-
-    5  Rescanning Conference Mail
-
-       Many conference managers currently allow a system to request that an
-       area be "rescanned". In other words, the system receiving the
-       request will export all mail in one or more areas to the requesting
-       system.
-
-       This may be accomplished by specifying the %RESCAN command in the
-       body of the request. This will force the ConfMgr to generate a scan
-       request for those areas which the remote system requested with the
-       message containing the %RESCAN command.
-
-       Rescans of a single area, newly linked, could be requested as
-       follows:
-
-          +CONFNAME, R[=<n>]
-
-       where 'n' is the number of messages in that area to be rescanned.
-       (The space following the comma is optional, but allowed.)
-
-       Rescanning has one serious drawback: dupes! It is very possible for
-       the requesting system to have already set up the area with several
-       downlinks. Thus, when the rescanned mail is received, it could be
-       exported to other systems. In a tree-based topology, this is
-       harmless, but in circular topologies this would create dupes.
-
-       Thus, it is proposed that system receiving the rescan request add a
-       kludge to the messages, so that they can be recognized by the
-       requesting system and not re-exported.
-
-       The proposed kludge is:
-
-          ^ARESCANNED <addr>
-
-       where <addr> is the network address, including domain, of the
-       system from which the mail was rescanned.
-
-       In alternative to a rescan, a sysop might request a "sample",
-       consisting of a series of messages contained in a text file. The
-       ConfMgr would export some or all messages from an area to a plain
-       ASCII text file, and send it along with the reply, to the requesting
-       system. A "sample" request would be made as follows:
-
-          +CONFNAME, S[=<n>]
-
-       where 'n' indicates how many messages should be sampled.
-
-       a) Updating Conferences
-
-          Update requests allow a sysop to rescan or "sample" an area
-          without having to first unlink from it, and then relink with the
-          rescan or "sample" parameter.
-
-          The format of this command is:
-
-             =CONFNAME, <param>[=<n>]
-
-          Thus a rescan request for the most recent 50 messages would be
-          specified as:
-
-             =CONFNAME, R=50
-
-
-
-    6  Information Requests
-
-       Requests for information have until now taken two forms. In one
-       case, they are given as switches after the password on the subject
-       line, while in the second they are given as "commands" within the
-       body of the message text. It is proposed that the second method be
-       chosen as standard, since it is considerably more flexible.
-
-       Below are listed the proposed commands:
-
-         %HELP                    Sends a (pre-defined) help text to the
-                                  requesting system, explaining how the
-                                  ConfMgr is to be used.
-
-         %LIST[,B]                Lists the conferences currently available
-                                  to the requesting system, on the basis
-                                  of a method internal to the conference
-                                  manager itself. This list would flag the
-                                  areas which are already linked. The 'B'
-                                  modifier would generate the list in
-                                  binary format (see section 8e).
-
-         %BLIST                   Equivalent to %LIST,B above.
-
-         %QUERY                   Lists the conferences currently linked to
-                                  the requesting system.
-
-         %UNLINKED                Lists the conferences which are available
-                                  to the requesting system, but not
-                                  currently linked. This is the logical
-                                  difference between a %LIST and a %QUERY.
-
-
-
-    7  Remote Maintenance
-
-       Besides these simple functions, it is becoming more and more
-       interesting to make handling of the conference mail flow even more
-       automatic. For this reason, for example, it might be useful to
-       allow another sysop control over your own system, adding and
-       removing conferences as need requires. Thus a hub or coordinator
-       could automatically have a new area added to their conference
-       lists, or discontinued ones removed.
-
-       Naturally, the ConfMgr must be able to distinguish which system has
-       the ability to make such changes, but that is beyond the scope of
-       this document.
-
-       It is proposed that a conference manager be able to automatically
-       add a new conference to the system's list if/when it is detected.
-       Thus no special commands would be required. The manager should be
-       able to determine a default list of down-links for the new area,
-       and also the "group" of systems which could then request it.
-
-       However, should it be desired to explicitly create a new conference
-       via remote, this could be done by including a line such as the
-       following in the message text:
-
-          &CONFNAME
-
-       In order to remote delete an area, the requesting sysop should
-       include a line like this in the body of the message text:
-
-          ~CONFNAME
-
-       Thus, if the system has remote privileges, the conference would be
-       deleted (and optionally, all systems linked to the conference could
-       be informed of this fact).
-
-       Similarly, it would also be possible to allow a system to change the
-       tag of a conference. This would be accomplished by a line such as:
-
-          # OLD_NAME  NEW_NAME
-
-       The ConfMgr should inform all downlinks of the change by sending a
-       net mail message.
-
-       It might also be desirable to allow a sysop to make changes on
-       behalf of another system. This could be done by inserting a special
-       command at the beginning of the request itself. For example:
-
-          From:     John Doe, on 2:123/1
-          To:       Program,  on 2:987/65
-          Subject:  password
-          Text:
-          %FROM: 2:234/56
-          +CONFNAME
-
-       The %FROM command would make the ConfMgr carry out the changes as if
-       the system 2:234/56 had requested them. The password should
-       nonetheless be the one assigned to 2:123/1.
-
-
-
-    8  Further Automation
-
-       In order to make the system more powerful, and to reduce the
-       necessity for human intervention, several extensions are feasible.
-
-       a) ARCmail Compression Method
-
-          One interesting application is the possibility of allowing a
-          remote system to change the compression program used to "pack"
-          mail bound for his system. This could be done with the following
-          command in the message to a ConfMgr:
-
-             %COMPRESS <method>
-
-          where <method> is one of the compression programs supported by
-          the system. Of course, the remote system should also be able to
-          determine which compression methods are available; this could be
-          done with
-
-             %COMPRESS ?
-
-          Requests for an unsupported compression method should also be
-          responded to with a list of those available.
-
-          From the practical point of view, only systems which pick up
-          their mail (as opposed to those to whom mail is sent) should be
-          allowed to change the compression method used. How this
-          distinction is achieved is beyond the scope of this document.
-
-       b) Passwords
-
-          A sysop should be able to change the password used to make
-          requests to a ConfMgr without requiring the intervention of the
-          other system's sysop. This could easily be done if the
-          conference manager implemented the following command:
-
-             %PWD <new_password>
-
-          The new password (case insensitive) would replace the current
-          one as of the next request.
-
-       c) Temporary Unlink
-
-          Should a system's sysop be absent for a prolonged period of time,
-          he might want to temporarily cut all conferences from his
-          uplink.  This could be accomplished with the
-
-             %PAUSE
-
-          command. This would tell the ConfMgr to temporarily stop sending
-          conferences to that system.  On his return, the sysop could
-          reactivate them all with the
-
-             %RESUME
-
-          command.
-
-       d) Forwarding Remote Requests
-
-          If a conference manager receives a remote request to delete an
-          area, it could very easily "forward" that request to all its
-          downlinks by producing a similar request.  In that way, a single
-          request originating from, for example, a Region Coordinator,
-          would result in the conference being deleted from all systems
-          "below" him.
-
-          Similarly, remote requests for conference name changes could
-          also be passed on to downlinks.
-
-       e) Automatic Requests for Conferences
-
-          A conference manager should also be able to automatically request
-          an area from an uplink. This would become necessary if, for
-          example, it processed a request for an area not currently
-          available on the system. In this case, it would scan a series of
-          conference lists for the requested area, and if found, would
-          send a request for that area.
-
-          In order to be able to do this, the ConfMgr would need to have
-          one or more lists of conferences from the uplinks. These lists
-          could be produced on request by the ConfMgr itself. In order to
-          simplify matters, a binary format is proposed. (Note that these
-          are C-style structures, with everything which that implies.)
-          This binary file is called a Binary Conference List (BCL).
-
-          The file starts with a header, containing some basic system
-          information:
-
-             struct bcl_header {
-               char    FingerPrint[4];     /* BCL<NUL> */
-               char    ConfMgrName[31];    /* Name of "ConfMgr" */
-               char    Origin[51];         /* Originating network addr */
-               long    CreationTime;       /* UNIX-timestamp when created */
-               long    flags;              /* Options, see below */
-               char    Reserved[256];      /* Reserved data */
-             }
-
-          The currently defined flags for the header are:
-
-            BCLH_ISLIST     0x00000001L
-              File is complete list
-
-            BCLH_ISUPDATE   0x00000002L
-              File contains update/diff information
-
-          The BCL would then contain a series of entries having the
-          following format:
-
-             struct bcl {
-               int     EntryLength;      /* Length of entry data */
-               long    flags1, flags2;   /* Conference flags */
-               char    *AreaTag;         /* Area tag [51] */
-               char    *Description;     /* Description [51] */
-               char    *Administrator;   /* Administrator or contact [51] */
-             }
-
-          The flags currently defined are:
-
-             FLG1_READONLY   0x00000001L
-                Read only, software must not allow users to enter mail.
-
-             FLG1_PRIVATE    0x00000002L
-                Private attribute of messages is honored.
-
-             FLG1_FILECONF   0x00000004L
-                File conference.
-
-             FLG1_MAILCONF   0x00000008L
-                Mail conference.
-
-             FLG1_REMOVE     0x00000010L
-                Remove specified conference from list (otherwise add/upd).
-
-          Thus, instead of scanning an AREAS.BBS style list, the ConfMgr
-          would parse and use lists in the above format. Naturally, each
-          list would be in some way "attached" to a node number, and a
-          corresponding ConfMgr password.
-
-          Each system may only have one master file, called anything they
-          want. But when transmitted to other systems, this file must
-          always be named ????????.BCL.
-
-          The list would be generated in response to a
-
-            %LIST, B
-
-          command in the message text.
-
-       f) Receipts
-
-          It might be useful to have the ConfMgr generate a receipt to be
-          sent to another system, perhaps a co-sysop or a sysop point
-          node. This could be done with the command:
-
-            %RECEIPT <name>,<address>
-
-         embedded in the request message. For example:
-
-            %RECEIPT JoHo,2:270/17
-
-
-
-    9  Comments in the request
-
-       It should be possible for a sysop to insert a comment in the request
-       made to a conference manager. These comments, naturally, would be
-       destined to the sysop of the system, and not to the conference
-       manager itself. Such comments should be placed at the end of the
-       message, following a %NOTE command.
-
-       In all cases except the above, the request can be deleted by the
-       ConfMgr once processed, but messages containing comments should be
-       retained.
-
-       Note: the current method used is to supply comments after a tear-
-       line. This practice is somewhat "messy", but it might be wise to
-       support it until such time as all conference managers have
-       implemented the %NOTE command.
-
-
-
-    10 Summary
-
-       +CONFNAME[,R|S]        Request to link to CONFNAME
-       -CONFNAME              Request to unlink from CONFNAME
-       =CONFNAME,R|S          Rescan or "sample" linked conference
-       &CONFNAME              Request to create CONFNAME
-       ~CONFNAME              Request to delete CONFNAME
-       #OLD NEW               Name change request
-
-       %LIST[,B]              List available areas, flag linked
-       %QUERY                 Only list linked areas
-       %UNLINKED              List available but unlinked areas
-       %HELP                  Send help text
-       %FROM <addr>           Simulate request from another system
-       %RESCAN                Rescan conferences linked in current request
-       %COMPRESS <method>     Change compression method
-       %PWD <new_pwd>         Change ConfMgr password
-       %PAUSE                 Suspend link
-       %RESUME                Resume link
-       %RECEIPT <name>,<addr> Send copy of receipt to another system
-       %NOTE                  Introduces comment to the sysop
-
-
-
-    11 Final Note
-
-       This document is to be considered as a suggestion for software
-       developers to make their programs compatible with one another, so as
-       to make life easier for the average sysop when dealing with
-       conference managers.
-
-       Feedback would be appreciated and can be sent to us at the addresses
-       specified on the title page. Please send feedback via netmail only.
-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0059.html b/html/ftsc/fsc-0059.html deleted file mode 100755 index 57a7806e..00000000 --- a/html/ftsc/fsc-0059.html +++ /dev/null @@ -1,1623 +0,0 @@ - - - -Newsgroup Interchange within FidoNet. - - - - -
-Document: FSC-0059
-Version:  001
-Date:     08-Mar-1992
-
-
-
-
-                  Newsgroup Interchange within FidoNet
-                              Jack Decker
-                            1:154/8@fidonet
-
-  A proposed standard for the interchange of USENET News messages among
-                             FidoNet nodes.
-
-
-Status of this document:
-
-     This FSC suggests a proposed protocol for the FidoNet(r) community,
-     and requests discussion and suggestions for improvements.
-     Distribution of this document is unlimited.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-
-
-Introduction:
-
-This document defines the standard format for the interchange of USENET
-news messages among FidoNet nodes.  It incorporates by reference the
-document RFC-1036, "Standard for Interchange of USENET Messages" by M.
-Horton of AT&T Bell Laboratories and R. Adams of the Center for Seismic
-Studies.  A copy of RFC-1036 should be included in the distribution
-archive of this standard.  However, RFC-1036 is NOT applicable in its
-entirety to FidoNet.  Therefore, unless specifically referenced
-elsewhere in this document, only section 2 of RFC-1036 should be
-considered part of this standard.  Section 3, which deals with "control
-messages", may be implemented in FidoNet on an optional basis, and if
-processing of control messages is included in a FidoNet implementation,
-it should be done in accordance with section 3 of RFC-1036 to the
-extent possible.  Section 4 of RFC-1036 is *NOT* applicable to FidoNet
-(except for section 4.3, which will be discussed later) and therefore
-is NOT included as part of this standard.  Section 5 of RFC-1036 is a
-treatise on the News Propagation Algorithm used within UseNet, and
-should be studied even though it is not directly applicable to FidoNet,
-in particular because it contains a discussion on the prevention of
-loops (what we in FidoNet commonly refer to as "dupe loops").
-
-Please note that FidoNet implementations do not recognize nor support
-what is referred to as the "old format" or the "A format" in section 2
-of RFC-1036.
-
-The goal of this document is to define a standard for the interchange
-of news messages between FidoNet nodes in a format that will also be
-acceptable to UseNet hosts.  In order to simplify the creation of
-software that conforms to this standard, we do not intend to support
-every news format that has ever existed in UseNet.  The standard
-described in RFC-1036 is used by the majority of UseNet hosts, and
-therefore it is the standard that will be adopted in this document.
-
-This standard will contain three sections:  General theory of newsgroup
-transmission, Format and protocols of batched newsgroups, and the
-translation of newsgroup messages to and from FidoNet message format.
-
-1. General theory of newsgroup transmission:
-
-Prior to the introduction of the DoveMail program, the usual method of
-gating a UseNet newsgroup into FidoNet was to convert it to FidoNet
-echomail, and then send it to "downstream" nodes in echomail format.
-This method is still used at the majority of gateway systems at this
-writing.  Unfortunately, no conversion process is perfect, and some
-useful control information is usually lost in the conversion.  In
-addition, most FidoNet echomail processors don't handle long messages
-(which are fairly common in newsgroups) well at all, and many gateway
-systems either try to split these messages into multiple parts (a
-somewhat awkward process) or discard them entirely.  Because the
-duplicate message detection algorithms used in many FidoNet echomail
-processors incorrectly identify some of the parts of a split message as
-duplicates, parts of long messages often get "lost" when transmitted as
-echomail.  Also, UseNet allows a message to be posted to multiple
-newsgroups, and when such messages are converted to echomail, it may be
-necessary to create multiple copies of the message (one for each
-echomail area that it would be placed in), thus increasing the
-transmission time for such messages.
-
-Even normal-length newsgroup messages may be falsely discarded as
-duplicates by some "downstream" echomail processors.  The reason this
-is a particular problem in newsgroups converted to echomail is because
-some echomail processors use a checksum of parts of FidoNet message
-headers to determine if messages are duplicates. Since all newsgroup
-messages are assumed to be addressed to "All", and since some gateway
-software uses the date and time that the message was converted to
-echomail rather than the original date and time from the message, it's
-quite possible that the remainder of the message header contains
-information that is similar enough to information in another message's
-header to cause it to be discarded as a duplicate message.  This
-happens far more frequently with converted newsgroup messages than with
-messages originally entered as echomail.
-
-Finally, when a BBS user enters a reply to a news message that has been
-converted to echomail, in many cases the information is simply not
-available in the original message to generate a proper "References:"
-line in the reply, as required by RFC-1036.  If the original message
-contained a "Followup-To:" line, which requires that replies be posted
-to a different newsgroup than the one in which the original message was
-entered, this line may not transmitted in the message as converted to
-echomail.  And even if this information is available, no echomail
-processor currently available will modify the reply message as required
-(to add the "References:" line where necessary, or to move the message
-to a different area if it is a reply to a message that contained a
-"Followup-To:" line).
-
-Under this proposed standard, none of the UseNet message header
-information is lost in transmission between nodes, and reply messages
-can be generated that conform to UseNet specifications.  If a message
-is posted to multiple newsgroups, it is only transmitted once (instead
-of multiple times as it might be if converted to echomail).  Also, long
-messages are not truncated or changed in transmission between nodes,
-and finally, there is no chance that a message will be improperly
-discarded as a duplicate.
-
-The main thing to remember is that under this standard, news messages
-are never converted to echomail.  Echomail is an irrelevant concept in
-this context, since we are not passing echomail between nodes.
-Instead, newsgroups are transmitted in the native format specified by
-RFC-1036, and tossed directly from batched newsgroup packets to the
-FidoNet message format (e.g. the *.msg format) if necessary.  Keep in
-mind that most FidoNet BBS software uses the same general format not
-only for echomail messages, but also for netmail and local message
-areas, so it is not necessary to transmit messages between nodes in
-echomail format if another format is more suitable for the type of
-message being transmitted.
-
-2. Format and protocols of batched newsgroups:
-
-When newsgroup messages are transmitted between systems, the individual
-messages must conform to the specifications of section 2 of RFC-1036,
-and section 3 of this document.  Where section 3 of this document
-defines a more restrictive standard than RFC-1036, this document shall
-take precedence.
-
-When transmitting news messages between FidoNet nodes, they must be
-sent in a batched newsgroup file (as described in section 4.3 of
-RFC-1036) unless some other format is agreed upon in advance.  The
-transmission of unbatched news messages, or the use of any batching
-method other than that described in section 4.3 of RFC-1036 shall be
-considered non-standard.  Please note that RFC-1036 section 4.3 refers
-to this batching process as combining several messages into "one large
-message", but we will refer to this "one large message" as a "batched
-newsgroup file", or a "UseNet format mail packet" rather than as a
-"large message", since FidoNet systems do not normally handle large
-"messages".
-
-When messages pass through a FidoNet system on their way to other
-nodes, the header lines in the message may be modified to conform with
-the standards given here.  However, the text (body) of a message should
-NEVER be altered (one exception: Carriage Returns MAY be converted to
-Line Feeds in order to conform to this standard, but this is neither
-required nor expected of software).
-
-The standard format for sending a batched newsgroup file to other
-FidoNet nodes is as follows:
-
-First, as will be noted in section 3 of this document, individual lines
-of the batched newsgroup file must be terminated with Line Feeds only,
-and the file must NOT contain Carriage Return characters (ASCII 13).
-
-Batched newsgroup files shall be transmitted between FidoNet nodes as
-files named using the filename ????????.PKU, where the eight character
-root name can be any of the hexadecimal digits 0 - 9 or A - F.  The
-.PKU extension (which stands for "PacKet - Usenet format") is the news
-equivalent of the .PKT file used to transmit FidoNet format netmail and
-echomail between nodes.
-
-Batched newsgroup files with the filespec ????????.PKU may be archived
-into a standard mail archive file (bearing the extension *.MO?, *.TU?,
-*.WE? ... *.SU?).  It is assumed that the receiver of batched newsgroup
-files will take any necessary steps to make sure that both *.PKU and
-*.PKT files are extracted from incoming mail archive files before the
-mail archive files are deleted.  In certain cases, this may mean that
-an external unarchive shell may have to be used, instead of allowing
-the echomail processor to call the unarchiver (typical external
-unarchive shell programs at this writing are GUS, POLYXARC, and SPAZ).
-
-A batched newsgroup file awaiting transmission may be stored in a
-FidoNet system's "outbound" area in uncompressed form, prior to being
-archived for transmission or sent in uncompressed form.  It is
-suggested that when a system uses the .OUT extension to indicate an
-uncompressed netmail or echomail packet, the .UUT extension be used to
-indicate an uncompressed batched newsgroup packet.  It is expected that
-a .UUT file in a system's "outbound" area will be treated in much the
-same way as an .OUT file, except it will be renamed to a file with an
-extension of .PKU (rather than .PKT) before being archived into the
-mail archive.  This implies that the root name of the .UUT file will
-contain the net number and node number of the destination system,
-expressed as four hexadecimal digits each for net and node numbers, in
-the same manner as the root name for a FidoNet .OUT file is
-constructed.
-
-The root filename of the *.PKU file should be an eight digit
-hexadecimal number, with leading zeroes used if necessary, in order to
-make an eight character root filename.  It is suggested that this
-hexadecimal number be based on time of year, with 00000000.PKU
-generated at exactly midnight on January 1 and FFFFFFFF.PKU generated
-at just a moment before midnight on December 31.  However, it is
-permissible to use the same algorithm that is used to generate the root
-filename for *.PKT files.
-
-The normal sequence for transmission of messages between FidoNet nodes
-might then be described as follows:
-
-a. Messages created on the originating system are placed into a batched
-newsgroup file conforming to the specifications of RFC-1036 section
-4.3.  When this batched newsgroup file is destined for another FidoNet
-node, it will have a filename of the format:
-
-     [4 hex digit net number][4 hex digit node number].UUT
-
-This file will then be placed in the outbound mail area for packing.
-
-b. A mail packing program will examine the outbound mail area and, upon
-finding the .UUT file, will rename it to a file with an extension of
-.PKU, and then shell to a compression program in order to place the
-*.PKU file into a new or existing mail archive file for the destination
-node.  Mail archive files bear extension names consisting of the first
-two letters of a day of the week (in the English language) plus a
-numeric character in the range 0 - 9 (for example, .MO5 or .TH7).  The
-method of compression for the mail archive is as agreed upon between
-the originating and destination nodes.  No "standard" method of
-compression for the mail archive is specified in this document.  NOTE:
-If the compression program fails for any reason (such as running out of
-disk space), the mail packing program MUST rename the .PKU file back to
-the original *.UUT filename before exiting.  Since batched newsgroup
-files do not contain a header that indicates the destination node,
-there would be no way to determine the proper destination node if the
-file were not renamed back to the original filename.
-
-c. The mail archive is transmitted in the usual manner by a FidoNet
-compatible mailer, or such other means as may be agreed upon in advance
-by the sysops of the originating and destination nodes.
-
-d. At the destination system, the individual files are extracted from
-the mail archive.  *.PKT files are processed in the usual manner to
-extract any netmail or echomail messages, while *.PKU files are
-processed by software designed to handle batched newsgroup files.  In
-this context, such files could be "handled" by re-processing the
-messages and batching them to be sent on to one or more additional
-node(s), or by tossing the messages to the local message base, or both.
-
-Please note that this standard does not anticipate that batched
-newsgroup files will be converted to FidoNet echomail at any point
-along the way.  It is realized that this may indeed happen, but such
-conversions should be considered as something to be avoided if at all
-possible due to the problems discussed in section 1 of this document.
-
-3. Translation of newsgroup messages to and from FidoNet message
-format:
-
-NOTE: Where applicable, the standards defined in this section for
-messages shall apply not only to locally created messages, but also to
-all messages sent to "downstream" FidoNet nodes.
-
-In this context, "FidoNet message format" means that format in which
-messages commonly reside on a FidoNet BBS.  At this writing, there are
-three formats commonly used for message storage on FidoNet systems, but
-other formats may be in use as well.  The three most common formats are
-the "*.msg" format as used by the original Fido program (and a host of
-programs since), also commonly referred to as the "single message per
-file format"; the "Hudson" format, used by QuickBBS, Remote Access, and
-some other products; and the "Squish" format used by the Maximus BBS
-and the "Squish" echomail processor.
-
-Because there are so many message formats, some other programs have
-taken the approach of trying to convert UseNet news into echomail,
-creating *.PKT files which can theoretically be processed by any
-FidoNet system.  However, since the *.PKT files are processed by the
-echomail processor, all the limitations and pitfalls associated with
-converting newsgroup messages to echomail come into play.
-
-The preferred way of handling incoming messages would be to have the
-BBS (or message reader/editor) software directly read batched newsgroup
-files.  In this way, the files would not have to be "processed" per se.
-As new batched newsgroup files arrived on a system, they could simply
-be concatenated to the existing message base, and then a utility could
-be run that would build an index to the message base, in a manner
-somewhat similar to the way "flat file" message bases are currently
-implemented on some BBS's.  Of course, you'd need to occasionally run a
-utility to delete old messages in order to keep the message base from
-growing too large, and new messages entered on the system would have to
-be exported from the system in a separate batched newsgroup file.
-However, at this writing no FidoNet-compatible BBS or message editor is
-capable of directly reading a batched newsgroup file.
-
-The second most preferable method is to convert news messages directly
-to the message format used by that system.  At this writing the
-DoveMail software includes utilities (NewsToss and NewsScan) that can
-convert batched newsgroup files to and from messages in the *.msg
-(single message per file) format.  It should be possible to convert
-batched newsgroup files to and from other FidoNet message formats as
-well.
-
-The method in which messages are stored on a BBS, and the method in
-which it is determined which new (locally-entered) messages need to be
-exported from the system will necessarily be implementation-specific.
-One method that can be used with *.msg type message bases is to
-maintain a "high water mark" in 1.msg, similar to the "high water mark"
-used for echomail messages, and additionally to mark messages received
-from other nodes as "sent" when they arrive, and locally-entered
-messages as "sent" when they have been exported, and to never re-send a
-message marked as "sent".
-
-When tossing incoming messages, duplicate messages can be detected by
-comparing the contents of the "Message-ID:" line with those of
-previously received messages.  This may be slow processing
-considerably, however, and would require storage of a history file of
-"previously seen" messages.  Another method is to look in the "Path"
-line and see if we are already listed in the path; if so, the message
-is a duplicate and should be deleted.  This method is faster and does
-not require maintenance of a history file, but will not guard against
-duplicate messages arriving from one's feed that have not passed
-through the system twice (for example, a message that arrived from two
-different paths).  Fortunately, UseNet folks seem to understand the
-need for proper topology, so those types of dupes are relatively rare.
-FidoNet sysops taking UseNet feeds must understand that it is
-IMPERATIVE that a feed of any one newsgroup be obtained from only ONE
-source, especially if they are then passing that newsgroup to any
-"downstream" nodes.  This absolutely does NOT imply that geographic
-restrictions on newsgroup distribution are necessary or desirable!
-
-Additional comments on preventing "loops" can be found in section 5 of
-RFC-1036, in the discussion of the News Propagation Algorithm.  Please
-note that only two methods of loop prevention are included in this
-standard:
-
-1) The history mechanism.  Each host keeps track of all messages it has
-seen (by their Message-ID) and whenever a message comes in that it has
-already seen, the incoming message is discarded immediately.
-
-2) Not sending a message to a system listed in the "Path" line of the
-header, or to the system that originated the message (which, in
-practice, should be listed in the Path line).
-
-No other methods of dupe loop prevention are acceptable.  In
-particular, checksums of portions of the message header or message
-itself are NOT permitted to be used for loop prevention, except perhaps
-as a method to quickly identify POTENTIAL duplicate messages before
-doing a full string comparison with the Message-ID data in the history
-file.  In no case should a checksum be used as the SOLE method of
-determining whether a message is a duplicate.
-
-When newsgroup messages are created for transmission to other systems,
-or when received messages are transmitted other systems, the individual
-messages must conform to the specifications of section 2 of RFC-1036.
-However, in order to simply programming of software designed to handle
-such messages, the following modifications to the standard are proposed
-for use within FidoNet.  Please note that these are slightly more
-restrictive than the standard permitted by RFC-1036:
-
-a. The "old format" or "A format" described in section 2 of RFC-1036 is
-NOT supported in FidoNet.  Only the format detailed in RFC-1036
-(sometimes referred to as the "B" News format) is supported.  The vast
-majority of UseNet sites currently use the "B" News format.
-
-b. The UseNet standard permits the use of "white space" to separate
-certain items in the message header, with "white space" defined as
-blanks or tabs.  It also states that "the Internet convention of
-continuation header lines (beginning with a blank or tab) is allowed."
-However, it should NOT be ASSUMED that "continuation header lines" will
-be used in any message.  It is suggested that when creating newsgroup
-messages for transmission to other systems, the use of tab characters
-be avoided in header lines, and that "continuation header lines" NOT be
-used, even if this means that a header line will be considerably longer
-than the length of a screen line.  Software that creates FidoNet-format
-messages (for display to BBS callers) from batched newsgroup files
-(that is, newsgroup message tossers) should break up such extra-long
-header lines, using a single space character ONLY (NOT a tab!) at the
-start of "continuation header lines."  Since batched newsgroup files
-received from a UseNet site may contain "continuation header lines"
-and/or tabs as "white space" in header lines, it is necessary to be
-able to decode such header lines properly, but it is strongly suggested
-that FidoNet software not CREATE messages with tabs or "continuation
-header lines" for transmission through the network.
-
-c. All lines in news messages, including header lines, shall be
-terminated with a LINE FEED (ASCII 10 decimal) ONLY.  Under NO
-circumstances shall a CARRIAGE RETURN (ASCII 13 decimal) appear in news
-messages transmitted through FidoNet (if a Carriage Return is found in
-an in-transit message it MAY be changed to a Line Feed, this being the
-sole exception to the rule about not changing the body of a message,
-but the expectation is that no Carriage Returns will appear in a news
-message).  Also, spaces appearing at the end of lines (just prior to
-the Line Feed character) are strongly discouraged since they convey no
-useful information.  Finally, there should be only a single line feed
-at the end of each message (blank lines following the last line of a
-message are not allowed, again because they convey no useful
-information).  Please note that the use of the Line Feed as a line
-terminator is fairly standard throughout UseNet, and when a news
-message is converted to a FidoNet format message it is a simple matter
-to replace Line Feeds with Carriage Returns so that the message will
-display properly.
-
-d. When constructing or adding to "Path" lines, RFC-1036 (section
-2.1.6) states that "The names may be separated by any punctuation
-character or characters (except '.' which is considered part of the
-hostname)."  However, in actual practice, only the "!" (exclamation
-point or "bang" character) is commonly used to separate names.
-Therefore, the "!" character will be considered the "standard"
-separator for system names in Path lines in messages generated in
-FidoNet.  Also, RFC-1036 states that "Normally, the rightmost name will
-be the name of the originating system.  However, it is also permissible
-to include an extra entry on the right, which is the name of the
-sender.  This is for upward compatibility with older systems." In
-actual practice, it appears that most Path lines originating in UseNet
-have a user name as the rightmost entry.  Therefore, when a Path line
-is created for a message originating in FidoNet, it is suggested that
-the following format be used (assuming a message entered by user John
-Smith at node 1:123/456):
-
-     Path: f456.n123.z1.fidonet.org!john.smith
-
-When a user name is placed in the path, all spaces in the user name
-must be replaced with periods, and all uppercase characters in the name
-should be converted to lowercase.  It is permissible to use an alias in
-place of a user's real name if the originating system runs software
-that will recognize that alias in incoming netmail messages, and remap
-such messages to the proper user if necessary.  Also, note the
-restrictions on prohibited characters in the user name as specified in
-RFC-1036 section 2.1.1.  Although section 2.1.1. deals with the "From"
-line, common sense would indicate that these same restrictions on
-prohibited characters should apply if the user name is placed in the
-Path line (with the obvious exception of the use of the period to
-replace spaces in the user name, which is required).
-
-e. Header lines defined as "optional" may be more or less optional
-depending on the keyword.  For example, the "Reply-To" and
-"Followup-To" lines should be automatically honored, if at all
-possible, when reply messages are created, and the "References" line,
-even though listed as an "optional" line, is "required for all
-follow-up messages" (replies).  On the other hand, lines such as
-"Control" and "Distribution" may have little meaning to FidoNet nodes
-(in particular, "Distribution" is meant to control distribution of a
-message along hierarchial lines, but since FidoNet topology has little
-relation to UseNet hierarchies, it is probably best to just ignore
-"Distribution" lines on in-transit messages).
-
-Additional specifications for messages, including required and optional
-header lines, are detailed in section 2 of RFC-1036.
-
-When a newsgroup is moderated, it is the responsibility of the sysop of
-each participating BBS to prevent users from entering messages in that
-area (unless the message exporting software is capable of sending any
-locally-entered messages to the conference moderator via MAIL).
-However, if a software newsgroup processor is written that both imports
-(tosses) messages to a FidoNet-format message base, and exports locally
-entered messages, and if the software does not have a way to send
-replies to the moderator via mail, then some mechanism must be provided
-to prevent the export of messages from a moderated area, so that in the
-unlikely event that there is no easy way to prevent users from posting
-messages in the moderated area, such messages will still not be sent
-out.  Since this standard does not deal with the transport of UseNet
-MAIL within FidoNet, the method for transmission of replies in
-moderated newsgroups is undefined by this document.  However, software
-authors are encouraged to provide some mechanism for private mail
-replies to newsgroup messages, in both moderated and unmoderated areas.
-
-Note that if a moderated newsgroup is carried on a system, it is the
-responsibility of the sysop to provide mail access to users so that
-replies can be (manually) sent to the conference moderator, especially
-if replies in the newsgroup area cannot be automatically routed to the
-conference moderator.
-
-One point that needs to be emphasized is there is NO message length
-limit on UseNet messages.  If a FidoNet node passes newsgroup messages
-to, or on behalf of other FidoNet nodes, it is NOT permissible to
-discard or truncate messages that exceed a preset length limit.  Note
-that in a batched newsgroup file, each message is preceded by a header
-of the form "#! rnews <length in bytes>".  Since the message text
-length is never changed in processing, it is possible to determine the
-length of a message after processing by reading in all the header
-lines, calculating the combined length of the header lines prior to
-making changes in the header (e.g. the Path line), then calculating the
-combined length of the header lines after making changes.  The
-difference between the original and the new length of the header lines
-can then be applied to the value given in the "#! rnews" line to
-determine the new message length, when is then used in the "#! rnews"
-header of the modified message.  Also, the number of bytes given in the
-"#! rnews" line, MINUS the length of the message header lines, is the
-length of the body of the message.  Once this length is known, the body
-of the message can be copied from the input file to the output file(s)
-in "chunks" small enough to fit in memory, until the end of the message
-is reached.
-
-The following comments are implementation suggestions applicable to
-current FidoNet-compatible BBS systems, though not necessarily to
-software that may be written in the future:
-
-It should be noted that when a BBS user enters a reply message, most
-FidoNet BBS software will "link" the reply message to the original by
-placing the message number of the original message in the message
-header (this is almost always the case if messages are stored in the
-"*.msg" format, in which case the number of the message being replied
-to is found at bytes 185-186 in the message header).  If the
-appropriate header lines have been stored in the text of the original
-message, it is possible to construct a reply message that meets all
-RFC-1036 specifications.  For example, a "References" line can be
-constructed from the "Message-ID" line (and the "References" line, if
-any) of the original message.  Similarly, if the original message
-contains a "Followup-To:" line, the reply can be posted to the
-newsgroup(s) specified in that line.  This may not work as expected if
-a message renumbering program or similar program messes with the
-message base before reply message is exported, so it is highly
-recommended that locally-entered newsgroup messages be exported as soon
-as practicable after they are entered.
-
-Since the user of a BBS may reply to a message entered by another user
-of the same BBS, it is recommended that when a message is exported, any
-UseNet format header lines created for the exported message also be
-written back to the original message if possible.  This will permit
-reply linking to remain intact even if two or more users of the same
-BBS participate in the same message thread.
-
-If a message is received that specifies more than one newsgroup in the
-"Newsgroups" header line, and corresponding message areas are available
-on the local system, one copy of the message should be placed in each
-such area.  For example, if the message is posted to four different
-newsgroups, and two of those groups are carried on the local BBS, then
-a copy of the message should be placed in the message base for each of
-those groups.  If users of a BBS are allowed to post a message to
-multiple newsgroups, then any message thus posted should be copied to
-the message bases of any of the other areas that are also carried on
-that system (and that the message was posted to) at the time the
-message is exported.
-
-Corrections and Additions to this document:
-
-Proposed corrections and additions to this document should be submitted
-to Jack Decker at 1:154/8, or jack.decker@f8.n154.z1.fidonet.org
-
- -
- -
-Network Working Group                                          M. Horton
-Request for Comments:  1036                       AT&T Bell Laboratories
-Obsoletes: RFC-850                                              R. Adams
-                                              Center for Seismic Studies
-                                                           December 1987
-
-
-              Standard for Interchange of USENET Messages
-
-
-
-STATUS OF THIS MEMO
-
-    This document defines the standard format for the interchange of
-    network News messages among USENET hosts.  It updates and replaces
-    RFC-850, reflecting version B2.11 of the News program.  This memo is
-    disributed as an RFC to make this information easily accessible to
-    the Internet community.  It does not specify an Internet standard.
-    Distribution of this memo is unlimited.
-
-1.  Introduction
-
-    This document defines the standard format for the interchange of
-    network News messages among USENET hosts.  It describes the format
-    for messages themselves and gives partial standards for transmission
-    of news.  The news transmission is not entirely in order to give a
-    good deal of flexibility to the hosts to choose transmission
-    hardware and software, to batch news, and so on.
-
-    There are five sections to this document.  Section two defines the
-    format.  Section three defines the valid control messages.  Section
-    four specifies some valid transmission methods.  Section five
-    describes the overall news propagation algorithm.
-
-2.  Message Format
-
-    The primary consideration in choosing a message format is that it
-    fit in with existing tools as well as possible.  Existing tools
-    include implementations of both mail and news.  (The notesfiles
-    system from the University of Illinois is considered a news
-    implementation.)  A standard format for mail messages has existed
-    for many years on the Internet, and this format meets most of the
-    needs of USENET.  Since the Internet format is extensible,
-    extensions to meet the additional needs of USENET are easily made
-    within the Internet standard.  Therefore, the rule is adopted that
-    all USENET news messages must be formatted as valid Internet mail
-    messages, according to the Internet standard RFC-822.  The USENET
-    News standard is more restrictive than the Internet standard,
-
-
-
-Horton & Adams                                                  [Page 1]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    placing additional requirements on each message and forbidding use
-    of certain Internet features.  However, it should always be possible
-    to use a tool expecting an Internet message to process a news
-    message.  In any situation where this standard conflicts with the
-    Internet standard, RFC-822 should be considered correct and this
-    standard in error.
-
-    Here is an example USENET message to illustrate the fields.
-
-              From: jerry@eagle.ATT.COM (Jerry Schwarz)
-              Path: cbosgd!mhuxj!mhuxt!eagle!jerry
-              Newsgroups: news.announce
-              Subject: Usenet Etiquette -- Please Read
-              Message-ID: <642@eagle.ATT.COM>
-              Date: Fri, 19 Nov 82 16:14:55 GMT
-              Followup-To: news.misc
-              Expires: Sat, 1 Jan 83 00:00:00 -0500
-              Organization: AT&T Bell Laboratories, Murray Hill
-
-              The body of the message comes here, after a blank line.
-
-      Here is an example of a message in the old format (before the
-      existence of this standard). It is recommended that
-      implementations also accept messages in this format to ease upward
-      conversion.
-
-               From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
-               Newsgroups: news.misc
-               Title: Usenet Etiquette -- Please Read
-               Article-I.D.: eagle.642
-               Posted: Fri Nov 19 16:14:55 1982
-               Received: Fri Nov 19 16:59:30 1982
-               Expires: Mon Jan 1 00:00:00 1990
-
-               The body of the message comes here, after a blank line.
-
-      Some news systems transmit news in the A format, which looks like
-      this:
-
-                Aeagle.642
-                news.misc
-                cbosgd!mhuxj!mhuxt!eagle!jerry
-                Fri Nov 19 16:14:55 1982
-                Usenet Etiquette - Please Read
-                The body of the message comes here, with no blank line.
-
-    A standard USENET message consists of several header lines, followed
-    by a blank line, followed by the body of the message.  Each header
-
-
-
-Horton & Adams                                                  [Page 2]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    line consist of a keyword, a colon, a blank, and some additional
-    information.  This is a subset of the Internet standard, simplified
-    to allow simpler software to handle it.  The "From" line may
-    optionally include a full name, in the format above, or use the
-    Internet angle bracket syntax.  To keep the implementations simple,
-    other formats (for example, with part of the machine address after
-    the close parenthesis) are not allowed.  The Internet convention of
-    continuation header lines (beginning with a blank or tab) is
-    allowed.
-
-    Certain headers are required, and certain other headers are
-    optional.  Any unrecognized headers are allowed, and will be passed
-    through unchanged.  The required header lines are "From", "Date",
-    "Newsgroups", "Subject", "Message-ID", and "Path".  The optional
-    header lines are "Followup-To", "Expires", "Reply-To", "Sender",
-    "References", "Control", "Distribution", "Keywords", "Summary",
-    "Approved", "Lines", "Xref", and "Organization".  Each of these
-    header lines will be described below.
-
-2.1.  Required Header lines
-
-2.1.1.  From
-
-    The "From" line contains the electronic mailing address of the
-    person who sent the message, in the Internet syntax.  It may
-    optionally also contain the full name of the person, in parentheses,
-    after the electronic address.  The electronic address is the same as
-    the entity responsible for originating the message, unless the
-    "Sender" header is present, in which case the "From" header might
-    not be verified.  Note that in all host and domain names, upper and
-    lower case are considered the same, thus "mark@cbosgd.ATT.COM",
-    "mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent.
-    User names may or may not be case sensitive, for example,
-    "Billy@cbosgd.ATT.COM" might be different from
-    "BillY@cbosgd.ATT.COM".  Programs should avoid changing the case of
-    electronic addresses when forwarding news or mail.
-
-    RFC-822 specifies that all text in parentheses is to be interpreted
-    as a comment.  It is common in Internet mail to place the full name
-    of the user in a comment at the end of the "From" line.  This
-    standard specifies a more rigid syntax.  The full name is not
-    considered a comment, but an optional part of the header line.
-    Either the full name is omitted, or it appears in parentheses after
-    the electronic address of the person posting the message, or it
-    appears before an electronic address which is enclosed in angle
-    brackets.  Thus, the three permissible forms are:
-
-
-
-
-
-Horton & Adams                                                  [Page 3]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-              From: mark@cbosgd.ATT.COM
-              From: mark@cbosgd.ATT.COM (Mark Horton)
-              From: Mark Horton <mark@cbosgd.ATT.COM>
-
-    Full names may contain any printing ASCII characters from space
-    through tilde, except that they may not contain "(" (left
-    parenthesis), ")" (right parenthesis), "<" (left angle bracket), or
-    ">" (right angle bracket).  Additional restrictions may be placed on
-    full names by the mail standard, in particular, the characters ","
-    (comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "="
-    (equal), and ";" (semicolon) are inadvisable in full names.
-
-2.1.2.  Date
-
-    The "Date" line (formerly "Posted") is the date that the message was
-    originally posted to the network.  Its format must be acceptable
-    both in RFC-822 and to the getdate(3) routine that is provided with
-    the Usenet software.  This date remains unchanged as the message is
-    propagated throughout the network.  One format that is acceptable to
-    both is:
-
-                      Wdy, DD Mon YY HH:MM:SS TIMEZONE
-
-    Several examples of valid dates appear in the sample message above.
-    Note in particular that ctime(3) format:
-
-                          Wdy Mon DD HH:MM:SS YYYY
-
-    is not acceptable because it is not a valid RFC-822 date.  However,
-    since older software still generates this format, news
-    implementations are encouraged to accept this format and translate
-    it into an acceptable format.
-
-    There is no hope of having a complete list of timezones.  Universal
-    Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST,
-    CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should be
-    supported.  It is recommended that times in message headers be
-    transmitted in GMT and displayed in the local time zone.
-
-2.1.3.  Newsgroups
-
-    The "Newsgroups" line specifies the newsgroup or newsgroups in which
-    the message belongs.  Multiple newsgroups may be specified,
-    separated by a comma.  Newsgroups specified must all be the names of
-    existing newsgroups, as no new newsgroups will be created by simply
-    posting to them.
-
-
-
-
-
-Horton & Adams                                                  [Page 4]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    Wildcards (e.g., the word "all") are never allowed in a "News-
-    groups" line.  For example, a newsgroup comp.all is illegal,
-    although a newsgroup rec.sport.football is permitted.
-
-    If a message is received with a "Newsgroups" line listing some valid
-    newsgroups and some invalid newsgroups, a host should not remove
-    invalid newsgroups from the list.  Instead, the invalid newsgroups
-    should be ignored.  For example, suppose host A subscribes to the
-    classes btl.all and comp.all, and exchanges news messages with host
-    B, which subscribes to comp.all but not btl.all.  Suppose A receives
-    a message with Newsgroups: comp.unix,btl.general.
-
-    This message is passed on to B because B receives comp.unix, but B
-    does not receive btl.general.  A must leave the "Newsgroups" line
-    unchanged.  If it were to remove btl.general, the edited header
-    could eventually re-enter the btl.all class, resulting in a message
-    that is not shown to users subscribing to btl.general.  Also,
-    follow-ups from outside btl.all would not be shown to such users.
-
-2.1.4.  Subject
-
-    The "Subject" line (formerly "Title") tells what the message is
-    about.  It should be suggestive enough of the contents of the
-    message to enable a reader to make a decision whether to read the
-    message based on the subject alone.  If the message is submitted in
-    response to another message (e.g., is a follow-up) the default
-    subject should begin with the four characters "Re:", and the
-    "References" line is required.  For follow-ups, the use of the
-    "Summary" line is encouraged.
-
-2.1.5.  Message-ID
-
-    The "Message-ID" line gives the message a unique identifier.  The
-    Message-ID may not be reused during the lifetime of any previous
-    message with the same Message-ID.  (It is recommended that no
-    Message-ID be reused for at least two years.)  Message-ID's have the
-    syntax:
-
-                     <string not containing blank or ">">
-
-    In order to conform to RFC-822, the Message-ID must have the format:
-
-                          <unique@full_domain_name>
-
-    where full_domain_name is the full name of the host at which the
-    message entered the network, including a domain that host is in, and
-    unique is any string of printing ASCII characters, not including "<"
-    (left angle bracket), ">" (right angle bracket), or "@" (at sign).
-
-
-
-Horton & Adams                                                  [Page 5]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    For example, the unique part could be an integer representing a
-    sequence number for messages submitted to the network, or a short
-    string derived from the date and time the message was created.  For
-    example, a valid Message-ID for a message submitted from host ucbvax
-    in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>".
-    Programmers are urged not to make assumptions about the content of
-    Message-ID fields from other hosts, but to treat them as unknown
-    character strings.  It is not safe, for example, to assume that a
-    Message-ID will be under 14 characters, that it is unique in the
-    first 14 characters, nor that is does not contain a "/".
-
-    The angle brackets are considered part of the Message-ID.  Thus, in
-    references to the Message-ID, such as the ihave/sendme and cancel
-    control messages, the angle brackets are included.  White space
-    characters (e.g., blank and tab) are not allowed in a Message-ID.
-    Slashes ("/") are strongly discouraged.  All characters between the
-    angle brackets must be printing ASCII characters.
-
-2.1.6.  Path
-
-    This line shows the path the message took to reach the current
-    system.  When a system forwards the message, it should add its own
-    name to the list of systems in the "Path" line.  The names may be
-    separated by any punctuation character or characters (except "."
-    which is considered part of the hostname).  Thus, the following are
-    valid entries:
-
-                   cbosgd!mhuxj!mhuxt
-                   cbosgd, mhuxj, mhuxt
-                   @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
-                   teklabs, zehntel, sri-unix@cca!decvax
-
-    (The latter path indicates a message that passed through decvax,
-    cca, sri-unix, zehntel, and teklabs, in that order.) Additional
-    names should be added from the left.  For example, the most recently
-    added name in the fourth example was teklabs.  Letters, digits,
-    periods and hyphens are considered part of host names; other
-    punctuation, including blanks, are considered separators.
-
-    Normally, the rightmost name will be the name of the originating
-    system.  However, it is also permissible to include an extra entry
-    on the right, which is the name of the sender.  This is for upward
-    compatibility with older systems.
-
-    The "Path" line is not used for replies, and should not be taken as
-    a mailing address.  It is intended to show the route the message
-    traveled to reach the local host.  There are several uses for this
-    information.  One is to monitor USENET routing for performance
-
-
-
-Horton & Adams                                                  [Page 6]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    reasons.  Another is to establish a path to reach new hosts.
-    Perhaps the most important use is to cut down on redundant USENET
-    traffic by failing to forward a message to a host that is known to
-    have already received it.  In particular, when host A sends a
-    message to host B, the "Path" line includes A, so that host B will
-    not immediately send the message back to host A.  The name each host
-    uses to identify itself should be the same as the name by which its
-    neighbors know it, in order to make this optimization possible.
-
-    A host adds its own name to the front of a path when it receives a
-    message from another host.  Thus, if a message with path "A!X!Y!Z"
-    is passed from host A to host B, B will add its own name to the path
-    when it receives the message from A, e.g., "B!A!X!Y!Z".  If B then
-    passes the message on to C, the message sent to C will contain the
-    path "B!A!X!Y!Z", and when C receives it, C will change it to
-    "C!B!A!X!Y!Z".
-
-    Special upward compatibility note:  Since the "From", "Sender", and
-    "Reply-To" lines are in Internet format, and since many USENET hosts
-    do not yet have mailers capable of understanding Internet format, it
-    would break the reply capability to completely sever the connection
-    between the "Path" header and the reply function.  It is recognized
-    that the path is not always a valid reply string in older
-    implementations, and no requirement to fix this problem is placed on
-    implementations.  However, the existing convention of placing the
-    host name and an "!"  at the front of the path, and of starting the
-    path with the host name, an "!", and the user name, should be
-    maintained when possible.
-
-2.2.  Optional Headers
-
-2.2.1.  Reply-To
-
-    This line has the same format as "From".  If present, mailed replies
-    to the author should be sent to the name given here.  Otherwise,
-    replies are mailed to the name on the "From" line. (This does not
-    prevent additional copies from being sent to recipients named by the
-    replier, or on "To" or "Cc" lines.)  The full name may be optionally
-    given, in parentheses, as in the "From" line.
-
-2.2.2.  Sender
-
-    This field is present only if the submitter manually enters a "From"
-    line.  It is intended to record the entity responsible for
-    submitting the message to the network.  It should be verified by the
-    software at the submitting host.
-
-
-
-
-
-Horton & Adams                                                  [Page 7]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    For example, if John Smith is visiting CCA and wishes to post a
-    message to the network, using friend Sarah Jones' account, the
-    message might read:
-
-              From: smith@ucbvax.Berkeley.EDU (John Smith)
-              Sender: jones@cca.COM (Sarah Jones)
-
-    If a gateway program enters a mail message into the network at host
-    unix.SRI.COM, the lines might read:
-
-              From: John.Doe@A.CS.CMU.EDU
-              Sender: network@unix.SRI.COM
-
-    The primary purpose of this field is to be able to track down
-    messages to determine how they were entered into the network.  The
-    full name may be optionally given, in parentheses, as in the "From"
-    line.
-
-2.2.3.  Followup-To
-
-    This line has the same format as "Newsgroups".  If present, follow-
-    up messages are to be posted to the newsgroup or newsgroups listed
-    here.  If this line is not present, follow-ups are posted to the
-    newsgroup or newsgroups listed in the "Newsgroups" line.
-
-    If the keyword poster is present, follow-up messages are not
-    permitted.  The message should be mailed to the submitter of the
-    message via mail.
-
-2.2.4.  Expires
-
-    This line, if present, is in a legal USENET date format.  It
-    specifies a suggested expiration date for the message.  If not
-    present, the local default expiration date is used.  This field is
-    intended to be used to clean up messages with a limited usefulness,
-    or to keep important messages around for longer than usual.  For
-    example, a message announcing an upcoming seminar could have an
-    expiration date the day after the seminar, since the message is not
-    useful after the seminar is over.  Since local hosts have local
-    policies for expiration of news (depending on available disk space,
-    for instance), users are discouraged from providing expiration dates
-    for messages unless there is a natural expiration date associated
-    with the topic.  System software should almost never provide a
-    default "Expires" line.  Leave it out and allow local policies to be
-    used unless there is a good reason not to.
-
-
-
-
-
-
-Horton & Adams                                                  [Page 8]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-2.2.5.  References
-
-    This field lists the Message-ID's of any messages prompting the
-    submission of this message.  It is required for all follow-up
-    messages, and forbidden when a new subject is raised.
-    Implementations should provide a follow-up command, which allows a
-    user to post a follow-up message.  This command should generate a
-    "Subject" line which is the same as the original message, except
-    that if the original subject does not begin with "Re:" or "re:", the
-    four characters "Re:" are inserted before the subject.  If there is
-    no "References" line on the original header, the "References" line
-    should contain the Message-ID of the original message (including the
-    angle brackets).  If the original message does have a "References"
-    line, the follow-up message should have a "References" line
-    containing the text of the original "References" line, a blank, and
-    the Message-ID of the original message.
-
-    The purpose of the "References" header is to allow messages to be
-    grouped into conversations by the user interface program.  This
-    allows conversations within a newsgroup to be kept together, and
-    potentially users might shut off entire conversations without
-    unsubscribing to a newsgroup.  User interfaces need not make use of
-    this header, but all automatically generated follow-ups should
-    generate the "References" line for the benefit of systems that do
-    use it, and manually generated follow-ups (e.g., typed in well after
-    the original message has been printed by the machine) should be
-    encouraged to include them as well.
-
-    It is permissible to not include the entire previous "References"
-    line if it is too long.  An attempt should be made to include a
-    reasonable number of backwards references.
-
-2.2.6.  Control
-
-    If a message contains a "Control" line, the message is a control
-    message.  Control messages are used for communication among USENET
-    host machines, not to be read by users.  Control messages are
-    distributed by the same newsgroup mechanism as ordinary messages.
-    The body of the "Control" header line is the message to the host.
-
-    For upward compatibility, messages that match the newsgroup pattern
-    "all.all.ctl" should also be interpreted as control messages.  If no
-    "Control" header is present on such messages, the subject is used as
-    the control message.  However, messages on newsgroups matching this
-    pattern do not conform to this standard.
-
-
-
-
-
-
-Horton & Adams                                                  [Page 9]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    Also for upward compatibility, if the first 4 characters of the
-    "Subject:" line are "cmsg", the rest of the "Subject:" line should
-    be interpreted as a control message.
-
-2.2.7.  Distribution
-
-    This line is used to alter the distribution scope of the message.
-    It is a comma separated list similar to the "Newsgroups" line.  User
-    subscriptions are still controlled by "Newsgroups", but the message
-    is sent to all systems subscribing to the newsgroups on the
-    "Distribution" line in addition to the "Newsgroups" line.  For the
-    message to be transmitted, the receiving site must normally receive
-    one of the specified newsgroups AND must receive one of the
-    specified distributions.  Thus, a message concerning a car for sale
-    in New Jersey might have headers including:
-
-                   Newsgroups: rec.auto,misc.forsale
-                   Distribution: nj,ny
-
-    so that it would only go to persons subscribing to rec.auto or misc.
-    for sale within New Jersey or New York.  The intent of this header
-    is to restrict the distribution of a newsgroup further, not to
-    increase it.  A local newsgroup, such as nj.crazy-eddie, will
-    probably not be propagated by hosts outside New Jersey that do not
-    show such a newsgroup as valid.  A follow-up message should default
-    to the same "Distribution" line as the original message, but the
-    user can change it to a more limited one, or escalate the
-    distribution if it was originally restricted and a more widely
-    distributed reply is appropriate.
-
-2.2.8.  Organization
-
-    The text of this line is a short phrase describing the organization
-    to which the sender belongs, or to which the machine belongs.  The
-    intent of this line is to help identify the person posting the
-    message, since host names are often cryptic enough to make it hard
-    to recognize the organization by the electronic address.
-
-2.2.9.  Keywords
-
-    A few well-selected keywords identifying the message should be on
-    this line.  This is used as an aid in determining if this message is
-    interesting to the reader.
-
-2.2.10.  Summary
-
-    This line should contain a brief summary of the message.  It is
-    usually used as part of a follow-up to another message.  Again, it
-
-
-
-Horton & Adams                                                 [Page 10]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    is very useful to the reader in determining whether to read the
-    message.
-
-2.2.11.  Approved
-
-    This line is required for any message posted to a moderated
-    newsgroup.  It should be added by the moderator and consist of his
-    mail address.  It is also required with certain control messages.
-
-2.2.12.  Lines
-
-    This contains a count of the number of lines in the body of the
-    message.
-
-2.2.13.  Xref
-
-    This line contains the name of the host (with domains omitted) and a
-    white space separated list of colon-separated pairs of newsgroup
-    names and message numbers.  These are the newsgroups listed in the
-    "Newsgroups" line and the corresponding message numbers from the
-    spool directory.
-
-    This is only of value to the local system, so it should not be
-    transmitted.  For example, in:
-
-               Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
-               From: reid@decwrl.DEC.COM (Brian Reid)
-               Newsgroups: news.lists,news.groups
-               Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
-               Message-ID: <5658@decwrl.DEC.COM>
-               Date: 1 Oct 86 11:26:15 GMT
-               Organization: DEC Western Research Laboratory
-               Lines: 441
-               Approved: reid@decwrl.UUCP
-               Xref: seismo news.lists:461 news.groups:6378
-
-    the "Xref" line shows that the message is message number 461 in the
-    newsgroup news.lists, and message number 6378 in the newsgroup
-    news.groups, on host seismo.  This information may be used by
-    certain user interfaces.
-
-3.  Control Messages
-
-    This section lists the control messages currently defined.  The body
-    of the "Control" header line is the control message.  Messages are a
-    sequence of zero or more words, separated by white space (blanks or
-    tabs).  The first word is the name of the control message, remaining
-    words are parameters to the message.  The remainder of the header
-
-
-
-Horton & Adams                                                 [Page 11]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    and the body of the message are also potential parameters; for
-    example, the "From" line might suggest an address to which a
-    response is to be mailed.
-
-    Implementors and administrators may choose to allow control messages
-    to be carried out automatically, or to queue them for annual
-    processing.  However, manually processed messages should be dealt
-    with promptly.
-
-    Failed control messages should NOT be mailed to the originator of
-    the message, but to the local "usenet" account.
-
-3.1.  Cancel
-
-                     cancel <Message-ID>
-
-
-    If a message with the given Message-ID is present on the local
-    system, the message is cancelled.  This mechanism allows a user to
-    cancel a message after the message has been distributed over the
-    network.
-
-    If the system is unable to cancel the message as requested, it
-    should not forward the cancellation request to its neighbor systems.
-
-    Only the author of the message or the local news administrator is
-    allowed to send this message.  The verified sender of a message is
-    the "Sender" line, or if no "Sender" line is present, the "From"
-    line.  The verified sender of the cancel message must be the same as
-    either the "Sender" or "From" field of the original message.  A
-    verified sender in the cancel message is allowed to match an
-    unverified "From" in the original message.
-
-3.2.  Ihave/Sendme
-
-                   ihave <Message-ID list> [<remotesys>]
-                   sendme <Message-ID list> [<remotesys>]
-
-    This message is part of the ihave/sendme protocol, which allows one
-    host (say A) to tell another host (B) that a particular message has
-    been received on A.  Suppose that host A receives message
-    "<1234@ucbvax.Berkeley.edu>", and wishes to transmit the message to
-    host B.
-
-    A sends the control message "ihave <1234@ucbvax.Berkeley.edu> A" to
-    host B (by posting it to newsgroup to.B).  B responds with the
-    control message "sendme <1234@ucbvax.Berkeley.edu> B" (on newsgroup
-    to.A), if it has not already received the message.  Upon receiving
-
-
-
-Horton & Adams                                                 [Page 12]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    the sendme message, A sends the message to B.
-
-    This protocol can be used to cut down on redundant traffic between
-    hosts.  It is optional and should be used only if the particular
-    situation makes it worthwhile.  Frequently, the outcome is that,
-    since most original messages are short, and since there is a high
-    overhead to start sending a new message with UUCP, it costs as much
-    to send the ihave as it would cost to send the message itself.
-
-    One possible solution to this overhead problem is to batch requests.
-    Several Message-ID's may be announced or requested in one message.
-    If no Message-ID's are listed in the control message, the body of
-    the message should be scanned for Message-ID's, one per line.
-
-3.3.  Newgroup
-
-                      newgroup <groupname> [moderated]
-
-    This control message creates a new newsgroup with the given name.
-    Since no messages may be posted or forwarded until a newsgroup is
-    created, this message is required before a newsgroup can be used.
-    The body of the message is expected to be a short paragraph
-    describing the intended use of the newsgroup.
-
-    If the second argument is present and it is the keyword moderated,
-    the group should be created moderated instead of the default of
-    unmoderated.  The newgroup message should be ignored unless there is
-    an "Approved" line in the same message header.
-
-3.4.  Rmgroup
-
-                            rmgroup <groupname>
-
-    This message removes a newsgroup with the given name.  Since the
-    newsgroup is removed from every host on the network, this command
-    should be used carefully by a responsible administrator.  The
-    rmgroup message should be ignored unless there is an "Approved:"
-    line in the same message header.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horton & Adams                                                 [Page 13]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-3.5.  Sendsys
-                           sendsys (no arguments)
-
-    The sys file, listing all neighbors and the newsgroups to be sent to
-    each neighbor, will be mailed to the author of the control message
-    ("Reply-To", if present, otherwise "From").  This information is
-    considered public information, and it is a requirement of membership
-    in USENET that this information be provided on request, either
-    automatically in response to this control message, or manually, by
-    mailing the requested information to the author of the message.
-    This information is used to keep the map of USENET up to date, and
-    to determine where netnews is sent.
-
-    The format of the file mailed back to the author should be the same
-    as that of the sys file.  This format has one line per neighboring
-    host (plus one line for the local host), containing four colon
-    separated fields.  The first field has the host name of the
-    neighbor, the second field has a newsgroup pattern describing the
-    newsgroups sent to the neighbor.  The third and fourth fields are
-    not defined by this standard.  The sys file is not the same as the
-    UUCP L.sys file.  A sample response is:
-
-      From: cbosgd!mark  (Mark Horton)
-      Date: Sun, 27 Mar 83 20:39:37 -0500
-      Subject: response to your sendsys request
-      To: mark@cbosgd.ATT.COM
-
-      Responding-System: cbosgd.ATT.COM
-      cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,
-            test
-      ucbvax:world,comp,to.ucbvax:L:
-      cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews
-            /cbosg
-      cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
-      sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews
-            /sescent
-      npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
-      mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
-
-3.6.  Version
-
-                           version (no arguments)
-
-    The name and version of the software running on the local system is
-    to be mailed back to the author of the message ("Reply-to" if
-    present, otherwise "From").
-
-3.7.  Checkgroups
-
-
-
-Horton & Adams                                                 [Page 14]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    The message body is a list of "official" newsgroups and their
-    description, one group per line.  They are compared against the list
-    of active newsgroups on the current host.  The names of any obsolete
-    or new newsgroups are mailed to the user "usenet" and descriptions
-    of the new newsgroups are added to the help file used when posting
-    news.
-
-4.  Transmission Methods
-
-    USENET is not a physical network, but rather a logical network
-    resting on top of several existing physical networks.  These
-    networks include, but are not limited to, UUCP, the Internet, an
-    Ethernet, the BLICN network, an NSC Hyperchannel, and a BERKNET.
-    What is important is that two neighboring systems on USENET have
-    some method to get a new message, in the format listed here, from
-    one system to the other, and once on the receiving system, processed
-    by the netnews software on that system.  (On UNIX systems, this
-    usually means the rnews program being run with the message on the
-    standard input. <1>)
-
-    It is not a requirement that USENET hosts have mail systems capable
-    of understanding the Internet mail syntax, but it is strongly
-    recommended.  Since "From", "Reply-To", and "Sender" lines use the
-    Internet syntax, replies will be difficult or impossible without an
-    Internet mailer.  A host without an Internet mailer can attempt to
-    use the "Path" header line for replies, but this field is not
-    guaranteed to be a working path for replies.  In any event, any host
-    generating or forwarding news messages must have an Internet address
-    that allows them to receive mail from hosts with Internet mailers,
-    and they must include their Internet address on their From line.
-
-4.1.  Remote Execution
-
-    Some networks permit direct remote command execution.  On these
-    networks, news may be forwarded by spooling the rnews command with
-    the message on the standard input.  For example, if the remote
-    system is called remote, news would be sent over a UUCP link
-    with the command:
-
-                              uux - remote!rnews
-
-    and on a Berknet:
-
-                              net -mremote rnews
-
-
-
-
-
-
-
-Horton & Adams                                                 [Page 15]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    It is important that the message be sent via a reliable mechanism,
-    normally involving the possibility of spooling, rather than direct
-    real-time remote execution.  This is because, if the remote system
-    is down, a direct execution command will fail, and the message will
-    never be delivered.  If the message is spooled, it will eventually
-    be delivered when both systems are up.
-
-4.2.  Transfer by Mail
-
-    On some systems, direct remote spooled execution is not possible.
-    However, most systems support electronic mail, and a news message
-    can be sent as mail.  One approach is to send a mail message which
-    is identical to the news message: the mail headers are the news
-    headers, and the mail body is the news body.  By convention, this
-    mail is sent to the user newsmail on the remote machine.
-
-    One problem with this method is that it may not be possible to
-    convince the mail system that the "From" line of the message is
-    valid, since the mail message was generated by a program on a
-    system different from the source of the news message.  Another
-    problem is that error messages caused by the mail transmission
-    would be sent to the originator of the news message, who has no
-    control over news transmission between two cooperating hosts
-    and does not know whom to contact.  Transmission error messages
-    should be directed to a responsible contact person on the
-    sending machine.
-
-    A solution to this problem is to encapsulate the news message into a
-    mail message, such that the entire message (headers and body) are
-    part of the body of the mail message.  The convention here is that
-    such mail is sent to user rnews on the remote system.  A mail
-    message body is generated by prepending the letter N to each line of
-    the news message, and then attaching whatever mail headers are
-    convenient to generate.  The N's are attached to prevent any special
-    lines in the news message from interfering with mail transmission,
-    and to prevent any extra lines inserted by the mailer (headers,
-    blank lines, etc.) from becoming part of the news message.  A
-    program on the receiving machine receives mail to rnews, extracting
-    the message itself and invoking the rnews program.  An example in
-    this format might look like this:
-
-
-
-
-
-
-
-
-
-
-
-Horton & Adams                                                 [Page 16]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-                Date: Mon, 3 Jan 83 08:33:47 MST
-                From: news@cbosgd.ATT.COM
-                Subject: network news message
-                To: rnews@npois.ATT.COM
-
-                NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
-                NFrom: derek@sask.UUCP (Derek Andrew)
-                NNewsgroups: misc.test
-                NSubject: necessary test
-                NMessage-ID: <176@sask.UUCP>
-                NDate: Mon, 3 Jan 83 00:59:15 MST
-                N
-                NThis really is a test.  If anyone out there more than 6
-                Nhops away would kindly confirm this note I would
-                Nappreciate it.  We suspect that our news postings
-                Nare not getting out into the world.
-                N
-
-    Using mail solves the spooling problem, since mail must always be
-    spooled if the destination host is down.  However, it adds more
-    overhead to the transmission process (to encapsulate and extract the
-    message) and makes it harder for software to give different
-    priorities to news and mail.
-
-4.3.  Batching
-
-    Since news messages are usually short, and since a large number of
-    messages are often sent between two hosts in a day, it may make
-    sense to batch news messages.  Several messages can be combined into
-    one large message, using conventions agreed upon in advance by the
-    two hosts.  One such batching scheme is described here; its use is
-    highly recommended.
-
-    News messages are combined into a script, separated by a header of
-    the form:
-
-
-                   #! rnews 1234
-
-    where 1234 is the length of the message in bytes.  Each such line is
-    followed by a message containing the given number of bytes.  (The
-    newline at the end of each line of the message is counted as one
-    byte, for purposes of this count, even if it is stored as <CARRIAGE
-    RETURN><LINE FEED>.)  For example, a batch of message might look
-    like this:
-
-
-
-
-
-
-Horton & Adams                                                 [Page 17]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-                #! rnews 239
-                From: jerry@eagle.ATT.COM (Jerry Schwarz)
-                Path: cbosgd!mhuxj!mhuxt!eagle!jerry
-                Newsgroups: news.announce
-                Subject: Usenet Etiquette -- Please Read
-                Message-ID: <642@eagle.ATT.COM>
-                Date: Fri, 19 Nov 82 16:14:55 EST
-                Approved: mark@cbosgd.ATT.COM
-
-                Here is an important message about USENET Etiquette.
-                #! rnews 234
-                From: jerry@eagle.ATT.COM (Jerry Schwarz)
-                Path: cbosgd!mhuxj!mhuxt!eagle!jerry
-                Newsgroups: news.announce
-                Subject: Notes on Etiquette message
-                Message-ID: <643@eagle.ATT.COM>
-                Date: Fri, 19 Nov 82 17:24:12 EST
-                Approved: mark@cbosgd.ATT.COM
-
-                There was something I forgot to mention in the last
-                message.
-
-    Batched news is recognized because the first character in the
-    message is #.  The message is then passed to the unbatcher for
-    interpretation.
-
-    The second argument (in this example rnews) determines which
-    batching scheme is being used.  Cooperating hosts may use whatever
-    scheme is appropriate for them.
-
-5.  The News Propagation Algorithm
-
-    This section describes the overall scheme of USENET and the
-    algorithm followed by hosts in propagating news to the entire
-    logical network.  Since all hosts are affected by incorrectly
-    formatted messages and by propagation errors, it is important
-    for the method to be standardized.
-
-    USENET is a directed graph.  Each node in the graph is a host
-    computer, and each arc in the graph is a transmission path from
-    one host to another host.  Each arc is labeled with a newsgroup
-    pattern, specifying which newsgroup classes are forwarded along
-    that link.  Most arcs are bidirectional, that is, if host A
-    sends a class of newsgroups to host B, then host B usually sends
-    the same class of newsgroups to host A.  This bidirectionality
-    is not, however, required.
-
-    USENET is made up of many subnetworks.  Each subnet has a name, such
-
-
-
-Horton & Adams                                                 [Page 18]
-
-RFC 1036              Standard for USENET Messages         December 1987
-
-
-    as comp or btl.  Each subnet is a connected graph, that is, a path
-    exists from every node to every other node in the subnet.  In
-    addition, the entire graph is (theoretically) connected.  (In
-    practice, some political considerations have caused some hosts to be
-    unable to post messages reaching the rest of the network.)
-
-    A message is posted on one machine to a list of newsgroups. That
-    machine accepts it locally, then forwards it to all its neighbors
-    that are interested in at least one of the newsgroups of the
-    message.  (Site A deems host B to be "interested" in a newsgroup if
-    the newsgroup matches the pattern on the arc from A to B.  This
-    pattern is stored in a file on the A machine.)  The hosts receiving
-    the incoming message examine it to make sure they really want the
-    message, accept it locally, and then in turn forward the message to
-    all their interested neighbors.  This process continues until the
-    entire network has seen the message.
-
-    An important part of the algorithm is the prevention of loops.  The
-    above process would cause a message to loop along a cycle forever.
-    In particular, when host A sends a message to host B, host B will
-    send it back to host A, which will send it to host B, and so on.
-    One solution to this is the history mechanism.  Each host keeps
-    track of all messages it has seen (by their Message-ID) and
-    whenever a message comes in that it has already seen, the incoming
-    message is discarded immediately.  This solution is sufficient to
-    prevent loops, but additional optimizations can be made to avoid
-    sending messages to hosts that will simply throw them away.
-
-    One optimization is that a message should never be sent to a machine
-    listed in the "Path" line of the header.  When a machine name is
-    in the "Path" line, the message is known to have passed through the
-    machine.  Another optimization is that, if the message originated
-    on host A, then host A has already seen the message.  Thus, if a
-    message is posted to newsgroup misc.misc, it will match the pattern
-    misc.all (where all is a metasymbol that matches any string), and
-    will be forwarded to all hosts that subscribe to misc.all (as
-    determined by what their neighbors send them).  These hosts make up
-    the misc subnetwork.  A message posted to btl.general will reach all
-    hosts receiving btl.all, but will not reach hosts that do not get
-    btl.all.  In effect, the messages reaches the btl subnetwork.  A
-    messages posted to newsgroups misc.misc,btl.general will reach all
-    hosts subscribing to either of the two classes.
-
-Notes
-
-    <1>  UNIX is a registered trademark of AT&T.
-
-
-
-
-
-Horton & Adams                                                 [Page 19]
-
-BackGo Back - - - - diff --git a/html/ftsc/fsc-0062.html b/html/ftsc/fsc-0062.html deleted file mode 100755 index 53d5bdab..00000000 --- a/html/ftsc/fsc-0062.html +++ /dev/null @@ -1,364 +0,0 @@ - - - -A Proposed Nodelist flag indicating Online Times of a Node. - - - - -
- | Document: FSC-0062
- | Version:  003
- | Date:     April 14, 1996
- | Author:   David J. Thomas
-
-
-
-
-	  A Proposed Nodelist flag indicating Online Times of a Node
-                               David J. Thomas
-                            2:442/600@fidonet.org
-
-
-
-
-Status of this document:
-
-     This FSC suggests a proposed protocol for the FidoNet(r) community,
-     and requests discussion and suggestions for improvements.
-     Distribution of this document is unlimited.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-  Note
-  ----
-
-  Changes in content between the previous edition of this document, and this
-  edition, are signified by bars (|) in the left margin, except where
-  otherwise specified. I have changed the format of the document slightly to
-  allow this. Where the format of the document has changed, but the actual
-  text has not, bars are not present.
-
-  Purpose
-  -------
-
-  There are currently several systems within FidoNet that offer file request
-  or mail holding capabilities but are not continuously online. The only time
-  during which these nodes can be contacted with reference to the nodelist is
-  currently the Zone Mail Hour of the zone to which the systems belong. In
-  theory, mailers can only use the zone mail hour(s) specified by the system
-  in question to contact these nodes, which does not provide for any method
-  of file requesting or calling for echomail that does not conflict with the
-  Policy requirement that no echomail or files be transferred during the zone
-  mail hour. This means that, in practice, if it is known that a particular
-  node is online for more time than ZMH alone, but less than 24 hours a day,
-  it is necessary to "kludge," or set this up as a special situation, in most
-  mailers whenever a node has to be contacted a number of times, whether
-  regularly or irregularly. The proposed flag would benefit the mailers in
-  such a way as to provide for them the online times that the node is usually
-  online for, thus cutting on the costs of calling a non-continuous mail
-  node, only to find that it is not available; and also, hopefully preventing
-  annoyance for a sysop whose mailer is being called whilst it is not online,
-  for example in the case of a voice/data shared line.
-
-  Compatibility
-  -------------
-
-  Since the current nodelist format is always being extended and nodelist
-  processors look only for the flags that they know about, there are no
-  expected compatibility problems with the suggestion outlined below.
-
-  Format of additional nodelist flag
-  ----------------------------------
-
-  The proposed nodelist flag has the following form:
-
-    Txy
-
-  where x represents the startup time, and y the end time, in the following
-  format:
-
-   +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
-   |Letter|Time|  |Letter|Time|  |Letter|Time|  |Letter|Time|  |Letter|Time|
-   +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
-   |   A  |0000|  |   F  |0500|  |   K  |1000|  |   P  |1500|  |   U  |2000|
-   |   a  |0030|  |   f  |0530|  |   k  |1030|  |   p  |1530|  |   u  |2030|
-   |   B  |0100|  |   G  |0600|  |   L  |1100|  |   Q  |1600|  |   V  |2100|
-   |   b  |0130|  |   g  |0630|  |   l  |1130|  |   q  |1630|  |   v  |2130|
-   |   C  |0200|  |   H  |0700|  |   M  |1200|  |   R  |1700|  |   W  |2200|
-   |   c  |0230|  |   h  |0730|  |   m  |1230|  |   r  |1730|  |   w  |2230|
-   |   D  |0300|  |   I  |0800|  |   N  |1300|  |   S  |1800|  |   X  |2300|
-   |   d  |0330|  |   i  |0830|  |   n  |1330|  |   s  |1830|  |   x  |2330|
-   |   E  |0400|  |   J  |0900|  |   O  |1400|  |   T  |1900|  |      |    |
-   |   e  |0430|  |   j  |0930|  |   o  |1430|  |   t  |1930|  |      |    |
-   +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
-
-| This flag is not intended to be a user flag. The flag is intended to provide
-| information to computerised mailer processes, and is not easily read by
-| human beings (although they can of course interpret the meaning of the
-| flag); most mailers however do not attempt to interpret any information that
-| is specified as a user flag, assuming that it is there for the benefit of
-| human beings. Such mailers would not be able to make use of the information
-| provided, which is the purpose of the flag.
-
-| This flag is of course not specified in FTS-0005 at the time of writing, but
-| this is not regarded by FidoNet as a problem because other flags in current
-| use are not specified in FTS-0005.
-
-  The case of the letter could be relevant. Whereas the case is currently not
-  used by any flags in the document describing the current format of the
-  nodelist, there exists the potential for the case of a letter to have
-  relevant meaning. The case has to be correct for the CRC check calculation
-  to prove correct, and this would be a good use for the case of the letter.
-  If it is necessary to ignore the case, then the upper on-the-hour time
-  should be used, i.e. the time that is listed after the upper-case letter.
-
-| These times are expressed in UTC so that the flag is useful for systems all
-  around the world, without the need for specific time zone information to be
-  included in the nodelist. They do not adjust with daylight saving time for a
-  similar reason. Note the section on daylight saving time for information
-  about handling adjustments without changing the flag; this is important.
-
-  Where necessary, the times can wrap around midnight, so for example, for a
-| node that is online between the hours of 1800 and 0600 UTC, the flag TSG
-  would be a valid indication of this time.
-
-  This nodelist entry is not required by any node. It is supplementary to the
-  #01, #02, #08, #09, #18, #20 flags and their !xx counterparts, though its
-  meaning is different. It has been suggested to me about the possibility of
-  an additional flag with the same meaning, but having a W as the first
-  letter, indicating that the node is also available for all hours during
-  weekends; however, I believe that the simple inclusion of the single flag
-  indicated above will solve most problems, as it does indicate a period for
-  non-CM nodes during which the node is available, which is all that is
-  really required.
-
-  Daylight saving time
-  --------------------
-
-  If a node changes online times with respect to UTC when daylight saving
-  time becomes effective (which would be the case with most part time nodes),
-  then this is to be taken into account when assigning this flag. An online
-  times flag assigned to a node should not be altered for the specific
-  purpose of adjusting due to daylight saving time, since large difference
-  files (NODEDIFF's) would result if every node was allowed to do this, e.g.
-  my node used to be online from 2300 to 0800 in local time, which in winter
-| is UTC, but in the summer it becomes BST (British Summer Time). This is one
-| hour ahead of UTC, and the corresponding availability times of my node
-| during the summer period were 2200 to 0700 UTC. Therefore my online times
-  flag would have indicated availability between the hours of 2300 and 0700
-| UTC, the daily time period encompassing both times, so the flag would be
-  TXH.
-
-  Policy considerations
-  ---------------------
-
-  This is a technical document. However, since the flag could make for an
-  increase in the size of difference files, the author feels that the
-  following guidelines should be adopted concerning the use of the flag.
-
-  The online times flag does not replace the requirement for exclusivity of
-  zone mail hour to be maintained. It is still annoying behaviour to have
-  this flag and be unavailable during ZMH, just as it is annoying behaviour
-  to have the CM (continuous mail) flag in one's entry, and disregard ZMH.
-
-  Except for during ZMH, the sysop of a node using this flag finding that
-  they need to take their mailer offline during the specified times to
-  perform system maintenance, or for any other reason, would not be acting in
-  an annoying manner to do so, unless the practice is found to be continuous,
-  in which case the flag's times could be reduced, or the flag itself could
-  be removed from their node entry.
-
-  It should be noted that this flag is present for the benefit of mailers,
-  not human beings. This means that the flag should be used only to indicate
-  when a mailer is ready to receive calls. A system that uses a FidoNet-
-  technology mailer in ZMH, and a human-access only system during other
-  period(s) of the day that cannot receive mail, should not use this flag.
-  This flag does not explicitly specify online times of a public access BBS,
-  although for presumably most nodes with FidoNet-capable software, a public
-  access BBS will be available during the times indicated.
-
-  Where the flag is used, it should not often be changed. If a situation
-  exists, for example, where a node uses a certain set of times during the
-  first two weeks of a month, and a different set of times during the
-  remainder period, the flag should be set to a time during each day of the
-  month when the node is online. For example, if a node is online during
-  1800-0800 for the first two weeks, and then during 2200-1000 for the
-  remainder, the time flag should specify 2200-0800 only. If there is no such
-  time (other than ZMH) then no flag should be used. Of course, any permanent
-  changes, and any necessary reductions in the times, should be permitted at
-  any time, but changes owing only to daylight saving time should certainly
-  be expressly forbidden.
-
-  File requests and user access are of course permitted during the online
-  times indicated (except ZMH).
-
-  The above list may seem rather frightening! Please note that they are
-  guidelines rather than rules, unless FidoNet policy has included them as
-  rules. In the vast majority of situations where a node is online for a
-  fixed set of hours per day, the only thing to watch out for is that you get
-  the daylight saving time period right. Then you don't have to worry about
-  changing it at any time, except when your own online times change.
-
-  Example
-  -------
-
-  With regard to time zones now; this is a complicated topic, so I wish to
-  express an example. Imagine a node in Indiana, USA. It is online for the
-  time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800).
-  This changes with daylight saving time, so the times expressed effectively
-| become an hour earlier with respect to UTC during daylight saving time.
-
-| Indiana is in the Central time zone, which is 6 hours behind UTC. Therefore,
-| the online times in UTC can be expressed as 0000-1400 UTC during winter.
-| During daylight saving time, however, the local time for Indiana is 5 hours
-| behind UTC. The online times during this period are 0100-1500 UTC. The
-| subset should be used, so that the online times flag for the node should
-| indicate availability between 0100 and 1400 UTC, which is indicated
-| by the flag TBO.
-
-| (Thanks to a few people for pointing out that the previous example was in
-| error; it assumed that Indiana was ahead of UTC, and not behind as is
-| actually the case.)
-
-  ANSI C routines to Calculate the Online Times Flag
-  --------------------------------------------------
-
-  These were not provided in the first edition. Change bars will not be used
-  here, since they would interfere with the syntax of the presented routines.
-
-  The first program calculates the online times flag from the user's entry of
-  the online times of a system, expressed in the local time zone, and the
-  offset to UTC used by the user's country. It takes into account that the
-  clock is put forward and back once a year by reducing the end time by one
-  hour. The program should work on any platform, and has been tested.
-
-=== start of code ===
-/* TIMEFLAG.C
-   Calculates FSC-0062 time flag requirement from user input */
-
-#include <stdio.h>
-
-char *onlineflag(char *on, char *off, int utc_diff);
-
-void main()
-{
-   char on[6], off[6]; int utc_diff;
-
-   printf("\nPlease specify the time you come online [HH:MM]: ");
-   scanf("%s", on);
-   printf("\nPlease specify the time you come offline [HH:MM]: ");
-   scanf("%s", off);
-   printf("\nSpecify the difference between your local time zone in winter\n"
-      "time and UTC (e.g. if your time zone is 6 hours behind UTC,\n"
-      "enter 6): ");
-   scanf("%d", &utc_diff);
-   printf("\nYour online time flag is %s\n\n",
-      onlineflag(on, off, utc_diff));
-}
-
-char *onlineflag(char *ontime, char *offtime, int utcdiff)
-{
-   int onhour, onmin, offhour, offmin;
-   static char flag[4]="T  ";
-
-   sscanf(ontime, "%d:%d", &onhour, &onmin);
-   sscanf(offtime, "%d:%d", &offhour, &offmin);
-
-   if(onmin>30) ++onhour;
-   --offhour; /* to correct for daylight saving time */
-   onhour = (onhour+24+utcdiff) % 24;
-   offhour = (offhour+24+utcdiff) % 24;
-
-   flag[1]='A'+onhour;
-   flag[2]='A'+offhour;
-
-   if(onmin>0 && onmin<31) flag[1] += 'a'-'A';
-   if(offmin>29) flag[2] += 'a'-'A';
-
-   return flag;
-}
-=== end of code ===
-
-  The second program calculates the online times from the time flag, input
-  as a pointer to char to the routine (this being of the format "Txy"). It
-  returns a pointer to a structure which contains the on- and off-times in
-  UTC. This is not a complete program; it is designed to be used by mailers
-  to determine the valid online times. It has also been tested.
-
-=== start of code ===
-/* INTFLAG.C
-   Interprets online time flags and converts them to a set of UTC times */
-
-struct TIMES {
-   int on_hour;
-   int on_min;
-   int off_hour;
-   int off_min;
-};
-
-struct TIMES *interpret_flag(char *time_flag);
-
-struct TIMES *interpret_flag(char *timeflag)
-{
-   static struct TIMES times;
-
-   times.on_min=0;
-   times.off_min=0;
-
-   times.on_hour=timeflag[1]-'A';
-   if(times.on_hour>23) {
-      times.on_hour -= 'a'-'A';
-      times.on_min=30;
-   }
-   times.off_hour=timeflag[2]-'A';
-   if(times.off_hour>23) {
-      times.off_hour -= 'a'-'A';
-      times.off_min=30;
-   }
-   return ×
-}
-=== end of code ===
-
-| The above routines can be copied and re-used as desired. I am now an
-| amazing C programmer, but I still make no guarantees about them! :-)
-
-  Summary
-  -------
-
-  I believe this to be a neat and compact solution to, what is in my opinion,
-  one of the gravest problems currently facing FidoNet. In FidoNet, most
-  nodes are continuous mail, but it is important for the growth and
-  popularity of FidoNet that non-CM nodes do not receive many mailer calls at
-  times when they are off line. Users are bad enough in this respect. It is
-  also useful for people wishing to contact hubs that are non-CM with mail
-  for a downlink, and for people wishing to file request from a node that is
-  not CM. There is no need for systems that are only online in zone mail hour
-  to adopt this flag; also, there is no need for CM systems to adopt this
-  flag.
-
-  Contacting the Author
-  ---------------------
-
-  My board is now online continuously, except for periods of down time during
-| which the board is maintained (few and far between now that Linux is used).
-  Netmail contact is therefore possible at any time. I went CM because of a
-  certain number of nodes calling at the wrong times, and also users. Users
-  weren't too bad, but I dislike 0600 am wake-up calls, repeated at regular
-  three-minute intervals for an hour, by mailers, rather intensely :-)
-
-End of document.
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0070.html b/html/ftsc/fsc-0070.html deleted file mode 100755 index f3c8d2ef..00000000 --- a/html/ftsc/fsc-0070.html +++ /dev/null @@ -1,123 +0,0 @@ - - - -Improving FidoNet/UseNet gating and Dupe Checking. - - - - -
-Document:   FSC-0070
-Date:       15-Jul-94
-Revision:   002
-
-              Improving Fidonet/Usenet gating and Dupe Checking
-                              
-                    Franck Arnaud, Fidonet 2:320/213.666
-
-
-
-  Status of this document
-  -----------------------
-
- This FSC suggests a proposed standard for the FidoNet(r) community,
- and invites discussion and suggestions for improvements. Distribution of
- this document is unlimited.
-
- Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
-   
-
-  Introduction
-  ------------
-
- The complexity of Usenet/Fidonet gating and the large number of gateways
- has led to a non-negligible quantity of duplicates appearing regularly in 
- both the Usenet and Fidonet worlds. This proposal defines a standard method 
- for gateway software to deal with conversion of message identifiers between 
- both worlds, so that we can improve the reliability of Usenet/Fidonet 
- gateways.
-
- In this document "^" means <control-A> (character 01h).
-
-
-  History
-  -------
-
- Revision 002 adds details and makes the Fidonet to Usenet sheme FTS-0009
- compliant.
-
-
-  Usenet To Fidonet Message Identifier Conversion
-  -----------------------------------------------
-
- A major problem is preventing messages gated into Fidonet from RFC822 from
- being gated back to Usenet at another gateway with a new message id. The
- easy way to solve that is simply to store the RFC message ID in a kludge 
- line. This kludge line could also allow identifying messages gated from 
- Usenet (this could be used by message editors to allow private replies to 
- the nearest uucp gateway for example).
-
- It is proposed that the ^RFCID: kludge is used to store the RFC Message-ID:
- in Fidonet messages. Of course, the use of the RFCID kludge doesn't replace
- the standard fts-0009 Message-ID:.
-
-       (Usenet)  Message-ID: <92_feb_10_19192012901@prep.ai.mit.edu>
-    to (Fido)    ^MSGID: 2:300/400.5 6789fedc
-                 ^RFCID: 92_feb_10_19192012901@prep.ai.mit.edu
-
- Note ^RFCID does not include the Message-ID enclosing "<" and ">".
-
- Then if a gateway finds a ^RFCID line in a Fido message, it will use it in
- the Usenet message ID, instead of converting the ^MSGID.
-
-
-  Fidonet to Usenet Message Identifiers Conversion
-  ------------------------------------------------
-
- The dupe checking in Usenet is based on the message ID. Fidonet now has its
- own standard message identification standard (fts-0009).
-
- So it would be interesting if the same Fidonet message gated at different
- gateways had the same ID in Usenet to help news processing programs in
- stopping dupes.
-
- The proposed fido ^MSGID: to RFC1036 Message-ID: conversion method is 
- defined as below:
-
- The ^MSGID: value (a string) is not parsed and converted as below to the ID
- part of Usenet's Message-ID. The Message-ID domain is the fidonet domain,
- "fidonet.org" if the gated echomail comes from the Fidonet(tm) network.
-
- To convert the MSGID string, the following rules are applied:
- - Alphanumeric (a-z,A-Z,0-9) characters are kept intact (case preserved).
- - Non-alphanumeric characters - including the space beetwen the origin
-   address and the serial number - are converted to '-'.
-
- Some examples:
-
-    (Fido)   ^MSGID: 2:300/400 12345AbC
- to (Usenet) Message-ID: <2-300-400-12345AbC@fidonet.org>
-
-    (Fido)   ^MSGID: 15:300/400.50@somenet abcd6789
- to (Usenet) Message-ID: <15-300-400-50-somenet-abcd6789@fidonet.org>
-
-    (Fido)   ^MSGID: Internet.Domain.org aBcD1234
- to (Usenet) Message-ID: <Internet-Domain-org-aBcD1234@fidonet.org>
-
-    (Fido)   ^MSGID: "LZKkoe$1982 98a" 45678bcd
- to (Usenet) Message-ID: <-LZKkoe-1982-98a--45678bcd@fidonet.org>
-
-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0072.html b/html/ftsc/fsc-0072.html deleted file mode 100755 index 54b14be4..00000000 --- a/html/ftsc/fsc-0072.html +++ /dev/null @@ -1,1926 +0,0 @@ - - - -The HYDRA file transfer protocol. - - - - -
-Document: FSC-0072
-Version:  001
-Date:     21-Feb-1993
-
-
-
-
-                    The HYDRA file transfer protocol
-
-               Joaquim H. Homrighausen and Arjen G. Lentz
-
-
-
-
-Status of this document:
-
-     This FSC suggests a proposed protocol for the FidoNet(r) community,
-     and requests discussion and suggestions for improvements.
-     Distribution of this document is subject to the restrictions listed
-     below.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-
-
-
-    ---------------------------------------------------------------------
-     Copyright 1991-1993 Joaquim H. Homrighausen. All rights reserved.
-     Copyright 1991-1993 Lentz Software Development. All rights reserved.
-    ---------------------------------------------------------------------
-
-
-    Restrictions
-    =====================================================================
-    You are granted a license to implement the HYDRA file transfer
-    protocol, HYDRA hereafter, in your own programs and/or use the sample
-    source code and adapt these to your particular situation and needs;
-    subject to the following conditions:
-
-    o You must refer to it as the HYDRA file transfer protocol, and you
-      must give credit to the authors of HYDRA in any information screens
-      or literature pertaining to your programs that contains other such
-      information (credits, your own copyrights, etc.).
-
-    o HYDRA will always remain backwards compatible with previous
-      revisions. HYDRA allows for expansion of its features without
-      interfering with previous revisions. It is, however, important that
-      different people do not expand the protocol in different directions.
-      We therefore ask you to contact us if you have any needs/ideas
-      regarding HYDRA, so development can be synchronized and beneficial
-      to all.
-
-    o If your implementation cannot converse with past or future revisions
-      as supplied by us, then you must refer to it as "HYDRA derived", or
-      as "a variation of HYDRA", or words to that effect.
-
-    Permission is hereby granted to the FTSC (FidoNet Technical Standards
-    Committee) and other technical organisations to republish this
-    document in its entirety. Librarians may change the title page and
-    page headers to match their library format as long as all copyrights
-    and body text remain unaltered. The original document name and source
-    must be mentioned in any republished versions of this document.
-
-    No organization, company, person, or other being may impose any fees
-    for any reason for providing this document. This document may not be
-    sold or otherwise transferred for personal or company gain under any
-    circumstances.
-
-
-    Disclaimer
-    =====================================================================
-    This information is provided "as is" and comes with no warranties of
-    any kind, either expressed or implied. There is no support available
-    for this package. It's intended to be used by programmers and
-    developers.
-
-    In no event shall the authors be liable to you or anyone else for any
-    damages, including any lost profits, lost savings or other incidental
-    or consequential damages arising out of the use or inability to use
-    this information.
-
-
-    Revision timestamps
-    =====================================================================
-    001                           0x2b1aab00                 Dec 01, 1992
-
-
-    Introduction
-    =====================================================================
-    This document will not attempt to convince the reader that HYDRA is
-    of value to him/her or that it is better than other file transfer
-    protocols, it will simply describe the protocol. Just to get it out
-    of the way, HYDRA is not the ultimate file transfer protocol.
-
-    The authors do, however, feel that it offers an significant
-    improvement over those file transfer protocols available today. HYDRA
-    is a bi-directional protocol with the ability to receive and send
-    files simultaneously. There are other bi-directional file transfer
-    protocols, but to the authors' knowledge no public specifications
-    exist.
-
-    HYDRA owes much to Zmodem and its designer, Chuck Forsberg as well as
-    to Janus, designed by Rick Huebner. We would like to think of HYDRA
-    as a combination of both with a few extra options installed.
-
-    The basic concept of a bi-directional file transfer protocol is
-    simple. Both data channels are utilized to transmit and receive files
-    simultaneously. I.e. two 100 kb files can be exchanged between two
-    parties in the time it takes a fully streaming uni-directional file
-    transfer protocol to transmit one of the files.
-
-
-    Protocol design
-    =====================================================================
-    The ultimate goal when designing HYDRA was to design a protocol that
-    is as simple and robust as possible; complexity increase the problem
-    of faulty implementations.
-
-    The obvious function of a file transfer protocol is to transport a
-    collection of data from its source to its destination as efficient
-    possible and without jeopardizing the integrity of the data.
-
-    The lack of data compression and lost packet management (as used in
-    Kermit and Super Kermit) is intentional. The authors feel that this
-    unnecessarily increases the complexity of the protocol.
-
-    While HYDRA performs to its best on full duplex links, it should be
-    possible to use it on links using proprietary protocols such as the
-    US Robotics HST protocol which features one 14.4 kbps data channel
-    and one 450 bps back channel.
-
-    The protocol design should be flexible enough for future enhancements
-    while maintaining backward compatibility.
-
-
-    Protocol requirements and restrictions
-    =====================================================================
-    HYDRA require that the link can handle ASCII character 24 (DLE) as
-    well as all ASCII characters in the range 32 through 126. All other
-    characters can be escaped or encoded by the protocol as required by
-    the link.
-
-    Capability of the computer to perform simultaneous serial I/O as well
-    as simultaneous serial I/O combined with disk access is preferred,
-    but can be circumvented by opting for windowed transmission instead
-    of full streaming.
-
-    HYDRA calls for the ability to check whether there is anything in the
-    serial input buffer (i.e. "peek-ahead"), but it doesn't mind if it
-    has to wait for a second if there is no data available (using for
-    instance the UNIX alarm() mechanism).
-
-    The protocol is extremely tolerant with timeouts (i.e. satellite or
-    network delays) while still maintaining maximum reliability,
-    robustness, and throughput.
-
-
-    Terms and definitions
-    =====================================================================
-    A BYTE                   An 8-bit unsigned character.
-    A WORD                   A 16-bit unsigned integer.
-    A DWORD                  A 32-bit unsigned integer.
-    A LONG                   A 32-bit SIGNED integer.
-    FILE OFFSETS (position)  A long.
-    NUL                      The ASCII character 0.
-    BS                       The ASCII character 8.
-    CR                       The ASCII character 13.
-    XOFF                     The ASCII character 17.
-    XON                      The ASCII character 19.
-    H_DLE                    The HYDRA link escape character, ASCII 24
-                             (^X).
-    SP or SPACE              The ASCII character 32.
-    UNIX timestamp           A specific time and date expressed as the
-                             number of seconds since midnight, January
-                             1st, 1970. All UNIX timestamps used in HYDRA
-                             are expressed in local time.
-
-    Multi-byte items are transmitted in "low-byte first" order, so big-
-    endian CPUs (like 680xx) need to do some byteswapping, depending on
-    the implementation.
-
-    Values preceded by '0x' are in hexadecimal notation (base 16, 0..9
-    a..f). All values transmitted in hexadecimal notation must be
-    converted to lowercase characters and left-padded to their full
-    size with '0' prior to transmission. E.g. a WORD with the value 255
-    (decimal) is expressed as 00ff. A LONG with the value 255 (decmial)
-    is expressed as 000000ff.
-
-    In formulas, "AND" means bitwise AND, "XOR" means bitwise Exclusive
-    OR, "NOT" is ones complement (i.e. all zeros become ones, all ones
-    become zeros). The ">>" is a shift operation to the right, "R >> 3"
-    means shift R three bits to the right.
-
-
-    General packet format
-    =====================================================================
-    All data exchange is done with framed packets protected by 16 or 32
-    bit CRC values appended to the packet data and packet type (low-
-    byte first). The only exception to this is the cancel sequence of 5
-    consecutive H_DLE characters.
-
-    All packets except those with the type DATA are followed by a CR
-    (ASCII 13) to help get through some buffered environments and aid
-    possible debugging and/or tracing. If requested by the other side in
-    its INIT packet, packets can also be prefixed by a specific data
-    string which can include NULs, delays or break signals. Refer to the
-    section on the INIT packet for more information.
-
-
-                          Format of unframed packet
-
-                +------------------------------------------+
-                ~ Zero or more bytes packet dependent data ~
-                +------------------------------------------+
-                | Packet type byte                         |
-                +------------------------------------------+
-                | CRC-16/32 of packet data and packet type |
-                +------------------------------------------+
-
-
-                            Table of packet types
-
-         +--------+---------+-----+--------------------------------+
-         |Name    |Character|ASCII|Description                     |
-         +--------+---------+-----+--------------------------------+
-         |START   |   'A'   |  65 |Startup sequence                |
-         |INIT    |   'B'   |  66 |Session initialisation          |
-         |INITACK |   'C'   |  67 |Response to INIT packet         |
-         |FINFO   |   'D'   |  68 |File information                |
-         |FINFOACK|   'E'   |  69 |Response to FINFO packet        |
-         |DATA    |   'F'   |  70 |File data packet                |
-         |DATAACK |   'G'   |  71 |File data position ACK packet   |
-         |RPOS    |   'H'   |  72 |Reposition request packet       |
-         |EOF     |   'I'   |  73 |End of file packet              |
-         |EOFACK  |   'J'   |  74 |Response to EOF packet          |
-         |END     |   'K'   |  75 |End of session                  |
-         |IDLE    |   'L'   |  76 |Idle (just saying I'm alive)    |
-         |DEVDATA |   'M'   |  77 |Data to specified device     (1)|
-         |DEVDACK |   'N'   |  78 |Response to DEVDATA packet   (1)|
-         +--------+---------+-----+--------------------------------+
-
-    (1) Support for DEVDATA and DEVDACK types is optional and indicated
-        in INIT state of a HYDRA session.
-
-
-                           Format of framed packet
-
-               +----------------------+--------------------+
-               |        H_DLE         |Packet format byte  |
-               +----------------------+--------------------+
-               ~               Encoded packet              ~
-               +----------------------+--------------------+
-               |        H_DLE         |End of framed packet|
-               +----------------------+--------------------+
-
-
-                            Table of packet formats
-
-           +----+---------+-----+--------------------------------+
-           |Name|Character|ASCII|Description                     |
-           +----+---------+-----+--------------------------------+
-           |END |   'a'   |  97 |End of framed packet            |
-           |BIN |   'b'   |  98 |Binary packet                   |
-           |HEX |   'c'   |  99 |Hex encoded packet              |
-           |ASC |   'd'   | 100 |Shifted 7-bit encoded packet (1)|
-           |UUE |   'e'   | 101 |UUencoded packet             (1)|
-           +----+---------+-----+--------------------------------+
-
-    (1) Support for ASC and/or UUE formats is optional and indicated in
-        the INIT state of a HYDRA session.
-
-
-    Packet sender and receiver state charts
-    ---------------------------------------------------------------------
-
-TXPKT (Sender)
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+-+----------------------------+--------------------------+----------+
-|Begin   |1|pkttype == START or         |format = HEXPKT           |Format    |
-|        | |pkttype == INIT or          |                          |          |
-|        | |pkttype == INITACK or       |                          |          |
-|        | |pkttype == END or           |                          |          |
-|        | |pkttype == IDLE             |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|Escape 8th bit (7 bit link) |                          |Coding    |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (no spc.pkt, 8bit link)|format = BINPKT           |Format    |
-+--------+-+----------------------------+--------------------------+----------+
-|Coding  |1|escape all control chars &  |format = UUEPKT           |Format    |
-|        | |UUENCODED packets allowed   |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|ASCII packets allowed       |format = ASCPKT           |Format    |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|7 bit link &                |format = HEXPKT           |Format    |
-|        | |escape all control chars &  |                          |          |
-|        | |UUE/ASC pkts not allowed    |                          |          |
-+--------+-+----------------------------+--------------------------+----------+
-|Format  |                              |Append format byte to data|CRC       |
-+--------+-+----------------------------+--------------------------+----------+
-|CRC     |1|format != HEXPKT &          |Calc CRC-32 (data,pkttype)|Encode    |
-|        | |CRC-32 allowed              |Append one's complement of|          |
-|        | |                            |CRC to data, lowbyte first|          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (HEXPKT or no CRC-32)  |Calc CRC-16 (data,pkttype)|Encode    |
-|        | |                            |Append one's complement of|          |
-|        | |                            |CRC to data, lowbyte first|          |
-+--------+-+----------------------------+--------------------------+----------+
-|Encode  |1|format == BINPKT            |BIN escape databuf        |Prefix    |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|format == HEXPKT            |HEX encode databuf        |Prefix    |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|format == ASCPKT            |ASC encode/escape databuf |Prefix    |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|format == UUEPKT            |UUE encode databuf        |Prefix    |
-+--------+-+----------------------------+--------------------------+----------+
-|Prefix  |1|No more prefix characters   |                          |Transmit  |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|Prefix character ASCII 221  |Send 1 second break signal|          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|Prefix character ASCII 222  |1 second delay            |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|Prefix character ASCII 223  |Transmit NUL (ASCII 0)    |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|else (any other character)  |Transmit character        |          |
-+--------+-+----------------------------+--------------------------+----------+
-|Transmit|                              |Transmit H_DLE,format byte|Suffix    |
-|        |                              |Transmit encoded buffer   |          |
-|        |                              |Transmit H_DLE,pktend byte|          |
-+--------+-+----------------------------+--------------------------+----------+
-|Suffix  |1|pkttype != DATA &           |Transmit CR,LF (ASC 13,10)|Done      |
-|        | |pktformat != BINPKT         |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (pkttype == DATA or    |                          |Done      |
-|        | |      pktformat == BINPKT)  |                          |          |
-+--------+-+----------------------------+--------------------------+----------+
-
-
-RXPKT (Receiver)
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+------------------------------+--------------------------+----------+
-|Reset   |                              |rxdle = 0                 |NextByte  |
-|        |                              |format = 0                |          |
-|        |                              |pktlen = 0                |          |
-+--------+-+----------------------------+--------------------------+----------+
-|NextByte|1|User wishes to abort session|Report reason for abort   |Abort     |
-|        | |or carrier lost             |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|Byte available in inputbuf  |                          |StripIn   |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|braintimer expired          |Report braindead situation|Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|Any other timer expired     |Tell responsible party    |          |
-+--------+-+----------------------------+--------------------------+----------+
-|StripIn |1|Escape 8th bit (7 bit link) |c = c AND 0x7f (strip 8th)|StripC    |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (8 bit link)           |                          |StripC    |
-+--------+-+----------------------------+--------------------------+----------+
-|StripC  |1|Escape ctlchars with 8th set|n = c AND 0x7f (strip 8th)|Process   |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (let 8 bit ctl through)|n = c                     |Process   |
-+--------+-+----------------------------+--------------------------+----------+
-|Process |1|c == H_DLE                  |increment rxdle           |DLE       |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|Escape XON/XOFF &           |Eat these                 |NextByte  |
-|        | |n == XON or n == XOFF       |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|Escape all control chars &  |Eat these                 |NextByte  |
-|        | |n < 32 or n == 127          |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|rxdle > 0                   |                          |Escape    |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|else (no eating or escaping)|                          |Store     |
-+--------+-+----------------------------+--------------------------+----------+
-|DLE     |1|rxdle == 5                  |Report remote wants abort |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (rxdle < 5)            |                          |NextByte  |
-+--------+-+----------------------------+--------------------------+----------+
-|Escape  |1|c == PKTEND                 |                          |PktEnd    |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|c == BINPKT                 |format = BINPKT           |PktStart  |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|c == HEXPKT                 |format = HEXPKT           |PktStart  |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|c == ASCPKT                 |format = ASCPKT           |PktStart  |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|c == UUEPKT                 |format = UUEPKT           |PktStart  |
-|        +-+----------------------------+--------------------------+----------+
-|        |6|else (normal escaped char)  |c = c XOR 0x40            |Store     |
-|        | |                            |rxdle = 0                 |Store     |
-+--------+-+----------------------------+--------------------------+----------+
-|Store   |1|format == 0                 |Garbage                   |NextByte  |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|pktlen >= maximum           |Pkt too long / lost PKTEND|Reset     |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (fmt > 0 & len < max)  |Append c to databuffer    |NextByte  |
-|        | |                            |increment pktlen          |          |
-+--------+-+----------------------------+--------------------------+----------+
-|PktStart|                              |rxdle = 0                 |NextByte  |
-|        |                              |pktlen = 0                |          |
-+--------+-+----------------------------+--------------------------+----------+
-|PktEnd  |1|format == 0                 |End without start, garbage|Reset     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|format == BINPKT            |(No more decoding needed) |CalcCRC   |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|format == HEXPKT            |ok = Decode HEXPKT        |CheckDec  |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|format == ASCPKT            |ok = Decode ASCPKT        |CheckDec  |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|format == UUEPKT            |ok = Decode UUEPKT        |CheckDec  |
-+--------+-+----------------------------+--------------------------+----------+
-|CheckDec|1|ok (no errors during decode)|                          |CalcCRC   |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (errors in decoding)   |Bad encoding, ignore pkt  |Reset     |
-+--------+-+----------------------------+--------------------------+----------+
-|CalcCRC |1|format != HEXPKT &          |Calc CRC-32 over databuf  |CheckCRC  |
-|        | |CRC-32 allowed              |ok = (crc == 0xdebb20e3)  |          |
-|        | |                            |pktlen = pktlen - 4       |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (HEXPKT or no CRC-32)  |Calc CRC-16 over databuf  |CheckCRC  |
-|        | |                            |ok = (crc == 0xf0b8)      |          |
-|        | |                            |pktlen = pktlen - 2       |          |
-+--------+-+----------------------------+--------------------------+----------+
-|CheckCRC|1|ok (CRC matched magic)      |pkttype = last byte of buf|Reset     |
-|        | |                            |pktlen = pktlen - 1       |          |
-|        | |                            |Hand pkt to higher level  |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (CRC check failed)     |Bad CRC, ignore packet    |Reset     |
-+--------+-+----------------------------+--------------------------+----------+
-
-
-
-    BIN packet format
-    ---------------------------------------------------------------------
-    The binary packet format require an 8-bit data channel. If requested
-    by either side, one or more sets of control characters are escaped.
-    In this case, when one of these characters appears in an unframed
-    packet, a H_DLE is sent followed by the character XOR 0x40. The H_DLE
-    character itself is always transmitted in this fashion. On the
-    receiver side, if the character after a H_DLE is not one of the
-    packet format bytes, this character is decoded using XOR 0x40 again.
-
-
-BINPKT Escaping
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+------------------------------+--------------------------+----------+
-|Begin   |                              |txlastc = 0               |NextByte  |
-+--------+-+----------------------------+--------------------------+----------+
-|NextByte|1|No more bytes to process    |                          |Done      |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|Escape ctlchars with 8th set|n = c AND 0x7f (strip 8th)|Escape    |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (let 8 bit ctl through)|n = c                     |Escape    |
-+--------+-+----------------------------+--------------------------+----------+
-|Escape  |1|n == H_DLE                  |Output H_DLE              |Output    |
-|        | |                            |c = c XOR 0x40            |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|Escape XON/XOFF &           |Output H_DLE              |Output    |
-|        | |n == XON or n == XOFF       |c = c XOR 0x40            |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|Escape Telenet &            |Output H_DLE              |Output    |
-|        | |n == CR &                   |c = c XOR 0x40            |          |
-|        | |txlasc == '@'               |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|Escape all control chars &  |Output H_DLE              |Output    |
-|        | |n < 32 or n == 127          |c = c XOR 0x40            |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|else (any other character)  |                          |Output    |
-+--------+-+----------------------------+--------------------------+----------+
-|Output  |                              |Store c                   |NextByte  |
-|        |                              |txlastc = c               |          |
-+--------+------------------------------+--------------------------+----------+
-
-
-
-    HEX packet format
-    ---------------------------------------------------------------------
-    Supported by all implementations, this packet format is used in
-    worst-case situations and upon startup of a session when it is not
-    yet known what restrictions the line and the other side will place on
-    the link.
-
-    Packet types always transmitted in HEX format are: START, INIT,
-    INITACK, IDLE, END.
-
-    HEX format packets always use a 16-bit CRC.
-
-    HEX packets assume a 7-bit link, escaping all control characters and
-    filtering all control characters upon receipt.
-
-    ASCII characters in the range 128-255 (high bit set) are encoded by
-    first transmitting a backslash ('\') character (ASCII 92), followed
-    by the character in two lowercase hex-digits (bits 4-7 in first
-    digit, bits 0-3 in second).
-
-    Uppercase hex-digits are not permitted.
-
-    The backslash character itself is transmitted as two backslashes.
-
-    ASCII characters in the range 0-31 and 127 (all control characters)
-    are escaped with H_DLE in the same fashion as in binary (BIN)
-    packets.
-
-    Decoded  byte 1
-            +------+
-            76543210
-            +--++--+
-    Encoded  h1  h2
-
-
-HEXPKT Encoding/Escaping
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+-+----------------------------+--------------------------+----------+
-|NextByte|1|No more bytes to process    |                          |Done      |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|High bit of c set           |Output \ (backslash)      |          |
-|        | |                            |Output hexdigit(c bit 4-7)|          |
-|        | |                            |Output hexdigit(c bit 0-3)|          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|c < 32 or c == 127          |Output H_DLE              |          |
-|        | |                            |Output (c XOR 0x40)       |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|c == \ (backslash)          |Output \ (backslash)      |          |
-|        | |                            |Output \ (backslash)      |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|else (any other character)  |Output c                  |          |
-+--------+-+----------------------------+--------------------------+----------+
-
-
-HEXPKT Decoding
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+-+----------------------------+--------------------------+----------+
-|NextByte|1|No more bytes to process    |                          |Done OK   |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|c == \ (backslash)          |                          |Escape    |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (any other character)  |Output c                  |Escape    |
-+--------+-+----------------------------+--------------------------+----------+
-|Escape  |1|No more bytes to process    |Premature end of data     |Error     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|c == \ (backslash)          |Output \ (backslash)      |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|c == lowercase hexdigit     |Save c, move ptr to next  |NextHex   |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|else (all other characters) |Invalid character         |Error     |
-+--------+-+----------------------------+--------------------------+----------+
-|NextHex |1|No more bytes to process    |Premature end of data     |Error     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|c == lowercase hexdigit     |Output (1st << 4 OR 2nd)  |NextByte  |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (all other characters) |Invalid character         |Error     |
-+--------+-+----------------------------+--------------------------+----------+
-
-
-    ASC packet format
-    ---------------------------------------------------------------------
-    Support of this packet format is optional and signalled in the INIT
-    packet with the ASC flag in the "Supported options" field. 8-bit data
-    is transformed into 7-bit data by a simple shift operation. Each byte
-    is inserted at the top of a shift register, the lower seven bits are
-    moved out. So seven 8-bit bytes are encoded into eight 7-bit
-    characters.
-
-    The end of the packet is padded by a maximum of six bits of 0 to make
-    the number of bits a multiple of seven and thereby creating
-    complete characters (so the receiver stops decoding when there are
-    less than seven bits left). The output can contain control
-    characters, so if escaping of these characters is required, this is
-    done as in BIN packets using the H_DLE method.
-
-
-    Decoded  byte 7  byte 6  byte 5  byte 4  byte 3  byte 2  byte 1
-            +------++------++------++------++------++------++------+
-            76543210765432107654321076543210765432107654321076543210
-            +-----++-----++-----++-----++-----++-----++-----++-----+
-    Encoded   c8     c7      c6    c5     c4     c3     c2     c1
-
-
-ASCPKT Encoding/Escaping
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+------------------------------+--------------------------+----------+
-|Reset   |                              |n = 0 (16 bit wide!)      |NextByte  |
-|        |                              |bitshift = 0              |          |
-+--------+-+----------------------------+--------------------------+----------+
-|NextByte|1|No more bytes to process    |                          |Flush     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (more bytes to process)|n = n OR (c << bitshift)  |Shift     |
-|        | |                            |BINPKT escape (n & 0x7f)  |          |
-|        | |                            |n = n >> 7                |          |
-|        | |                            |increment bitshift        |          |
-+--------+-+----------------------------+--------------------------+----------+
-|Shift   |1|bitshift == 7               |BINPKT escape (n & 0x7f)  |Reset     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (bitshift < 7)         |                          |NextByte  |
-+--------+-+----------------------------+--------------------------+----------+
-|Flush   |1|bitshift > 0                |BINPKT escape (n & 0x7f)  |Done      |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (bitshift == 0)        |                          |Done      |
-+--------+-+----------------------------+--------------------------+----------+
-
-ASCPKT Decoding
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+------------------------------+--------------------------+----------+
-|Begin   |                              |n = 0 (16 bit wide!)      |NextByte  |
-|        |                              |bitshift = 0              |          |
-+--------+-+----------------------------+--------------------------+----------+
-|NextByte|1|No more bytes to process    |                          |Done OK   |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (more bytes to process)|c = c AND 0x7f            |Shift     |
-|        | |                            |n = n OR (c << bitshift)  |          |
-|        | |                            |bitshift = bitshift + 7   |          |
-+--------+-+----------------------------+--------------------------+----------+
-|Shift   |1|bitshift >= 8               |Output (n AND 0xff)       |NextByte  |
-|        | |                            |n = n >> 8                |          |
-|        | |                            |bitshift = bitshift - 8   |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (bitshift < 8)         |                          |NextByte  |
-+--------+-+----------------------------+--------------------------+----------+
-
-
-
-    UUE packet format
-    ---------------------------------------------------------------------
-    Support of this packet format is optional and signalled in the INIT
-    packet with the UUE flag in the "Supported options" field. The 8-bit
-    data is transformed into printable ASCII using the UUENCODE
-    algorithm. Three 8-bit bytes are encoded into four printable ASCII
-    characters. This done by taking the bottom six bits left and adding
-    '!' (ASCII 33) to move this character value into printable ASCII
-    range.
-
-    The end of the packet is padded by a maximum of five bits of 0 to
-    make the number of bits a multiple of six and thereby creating 
-    complete characters (so the receiver stops decoding when there are
-    less than six bits left). The output of this coding scheme does not
-    need any further escaping before transmission.
-
-    Decoded  byte 3  byte 2  byte 1
-            +------++------++------+
-            765432107654321076543210
-            +----++----++----++----+
-    Encoded   c4    c3    c2    c1
-
-
-UUEPKT Encoding
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+-+----------------------------+--------------------------+----------+
-|NextByte|1|Less than three bytes left  |                          |Flush     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (three or more left)   |UUE(in[0]>>2)             |          |
-|        | |                            |UUE(in[0]<<4 OR in[1]>>4) |          |
-|        | |                            |UUE(in[1]<<2 OR in[2]>>6) |          |
-|        | |                            |UUE(in[2])                |          |
-|        | |                            |(UUE: (c AND 0x3f) + '!') |          |
-+--------+-+----------------------------+--------------------------+----------+
-|Flush   |1|No more bytes left          |                          |Done      |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|One byte left               |UUE(in[0]>>2)             |Done      |
-|        | |                            |UUE(in[0]<<4)             |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|Two bytes left              |UUE(in[0]>>2)             |Done      |
-|        | |                            |UUE(in[0]<<4 OR in[1]>>4) |          |
-|        | |                            |UUE(in[1]<<2)             |          |
-+--------+-+----------------------------+--------------------------+----------+
-
-UUEPKT Decoding
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+-+----------------------------+--------------------------+----------+
-|NextByte|1|Less than four bytes left   |                          |Flush     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (four or more left) &  |UD(i[0])<<2 OR UD(i[1])>>4|          |
-|        | |(c AND 0x7f) is in UUE range|UD(i[1])<<4 OR UD(i[2])>>2|          |
-|        | |                            |UD(i[2])<<6 OR UD(i[3])   |          |
-|        | |                            |(UD: (c - '!') AND 0x3f)  |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (all other characters) |Invalid character(s)      |Error     |
-+--------+-+----------------------------+--------------------------+----------+
-|Flush   |1|No bytes left or            |                          |Done OK   |
-|        | |Less than two bytes left    |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|Two bytes left &            |UD(i[0])<<2 OR UD(i[1])>>4|Done OK   |
-|        | |(c AND 0x7f) is in UUE range|                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|Three bytes left &          |UD(i[0])<<2 OR UD(i[1])>>4|Done OK   |
-|        | |(c AND 0x7f) is in UUE range|UD(i[1])<<4 OR UD(i[2])>>2|          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|else (all other characters) |Invalid character(s)      |Error     |
-+--------+-+----------------------------+--------------------------+----------+
-
-
-
-    START packet                                             (HEX format)
-    ---------------------------------------------------------------------
-    This packet is sent to tell the remote to initiate a HYDRA session.
-
-    The complete framed packet as transmitted looks like:
-
-        ASCII values   24    99  65  92 102  53  92  97  51    24    97
-                    +-------+---+---+---+---+---+---+---+---+-------+---+
-        Characters  | H_DLE | c | A | \ | f | 5 | \ | a | 3 | H_DLE | a |
-                    +-------+---+---+---+---+---+---+---+---+-------+---+
-
-    Applications may scan for this sequence to automatically start HYDRA
-    when the remote transmits this packet (AutoStart). Prior to the START
-    packet, a special string is transmitted to enable remote starting
-    from a command prompt, hydra (the word hydra in lowercase):
-
-        ASCII values 104 121 100 114  97  13
-                    +---+---+---+---+---+----+
-        Characters  | h | y | d | r | a | CR |
-                    +---+---+---+---+---+----+
-
-    The special string combined with the START packet is transmitted at
-    five second intervals until either a START or INIT packet is received
-    from the remote, or the maximum number of retries is reached. Any
-    other packet types received in this stage must be ignored as they
-    could be remains of a previous session.
-
-
-    INIT packet                                              (HEX format)
-    ---------------------------------------------------------------------
-    The INIT packet contains file transfer session options. The remote
-    acknowledges this packet by returning an INITACK packet.
-
-
-                              INIT packet data
-
-                 +---------------------------------------+
-                 ~ Application ID string, NUL terminated ~
-                 +---------------------------------------+
-                 ~ Supported options, NUL terminated     ~
-                 +---------------------------------------+
-                 ~ Desired options, NUL terminated       ~
-                 +---------------------------------------+
-                 | Desired transmitter window size or 0  |
-                 +---------------------------------------+
-                 | Desired receiver window size or 0     |
-                 +---------------------------------------+
-                 ~ Other general options, NUL terminated ~
-                 +---------------------------------------+
-                 ~ Packet prefix string, NUL terminated  ~
-                 +---------------------------------------+
-
-    The application ID string contains a printable ASCII string with the
-    document revision date, product name, product revision number, and
-    optionally the product serial number. The format of the string is:
-
-        <RevDate><ProductName><,><ProductRevision>[<,><ProductSerial#>]
-
-    RevDate is the UNIX timestamp (the hour, minute, and second portion
-    is assumed to be zero), in hexadecimal notation, of the HYDRA
-    document that the application is supposed to support. None of the
-    following three fields should exceed thirty characters in length and
-    must not contain any control characters (ASCII 0-31) or the comma
-    character (ASCII 44). The field separator is a comma (ASCII 44)
-    character.
-
-    Capability flags
-
-        XON        Escape <XON> and <XOFF> characters.
-        TLN        Escape the <CR>@<CR> sequence (Telenet escape).
-        CTL        Escape ASCII characters 0-31 and 127.
-        HIC        Escape above three with high bit set.
-        HI8        Escape ASCII characters 128-255 and strip the high bit.
-        BRK        Can transmit a break signal.
-        ASC        Can handle ASC packets.
-        UUE        Can handle UUE packets.
-        C32        Can receive packets with 32-bit CRC error detection.
-        DEV        Can receive device packets.
-        FPT        Can receive filenames with paths.
-
-    Capability flags are always three characters long, in uppercase, and
-    seperated by a comma character (ASCII 44). Please note that the first
-    five flags must be supported by all applications that implement the
-    HYDRA specifications.
-
-    The "Supported options" string contain the capability flags of the
-    options that the application support. The "Desired options" string
-    contain the capability flags of the options that the application
-    would like to use/enable for the session. Some flags do not have to
-    be specified in both strings. E.g. if the C32 flag is present in the
-    "Supported options" string and the remote system indicates support
-    for the same flag, 32-bit CRC error detection will be used. An
-    application may not ask for an option it does not support.
-
-    Escaping certain characters or bits also means filtering any
-    occurrence of them in the incoming data stream. At the start of a
-    session, it is assumed that the first five capability flags are in
-    effect, i.e. the high bit is stripped off every received character
-    and all control characters are filtered out.
-
-    The "Desired transmitter/receiver window size" fields are long
-    integers expressed in hexadecimal notation. With these options each
-    side tells the other to use window management of the requested size
-    when transmitting file data, instead of using full streaming (0).
-    The window setting is completely seperate for both directions.
-    If one side requests a smaller window size than the other, that
-    smaller size will be used for that direction; also, a window of any
-    size takes precedence over no window (0).
-    Please note that the terms 'transmitter' and 'receiver' used for the
-    fields in the INIT packet are from the view of the side transmitting
-    that packet, so the other side should merge the 'transmitter' window
-    field from the received INIT packet with its own 'receiver' window
-    field.
-
-    The "General options" string currently has no other fields than
-    "Desired tx/rx window size"; the string is NUL terminated.
-
-    The packet prefix string is normally empty, but may be provided by
-    the remote if required. The maximum length of a packet prefix string
-    is 30 characters. All characters should be transmitted as specified,
-    with the following exceptions:
-
-    
-                Table of special packet prefix string chars
-
-               +-----+--------------------------------------+
-               |ASCII|Description                           |
-               +-----+--------------------------------------+
-               | 221 |Transmit a break signal for one second|
-               | 222 |Delay one second before next character|
-               | 223 |Transmit a NUL (ASCII 0) character    |
-               +-----+--------------------------------------+
-
-
-    INITACK packet                                           (HEX format)
-    ---------------------------------------------------------------------
-    The INITACK packet is used to acknowledge the receipt of the remote's
-    INIT packet.
-
-    Duplicate INIT packets should be acknowledged too, as the remote may
-    have missed previous INITACK packets; the reception of such a
-    duplicate packet should not however reset the braindead timer, as it
-    does not mean a change of state and is not actual file data.
-
-
-    FINFO packet
-    ---------------------------------------------------------------------
-    File information packet, sent to notify the remote that another file
-    is to be transmitted, or to signal end of batch. After the FINFO
-    packet has been transmitted, the timer is set to the normal timeout
-    value. The sender then waits for an FINFOACK packet from the remote
-    or for the timer to expire. In the event of a timeout, the transmit/
-    wait sequence is repeated with half the normal timeout value until
-    the maximum number of retries has been reached.
-
-
-                              FINFO packet data
-                   +-------------------------------------+
-                   ~ File information, NUL terminated    ~
-                   +-------------------------------------+
-
-
-                   File information        End of batch
-                  +-----------------+   +-----------------+
-                  | Timestamp or 0  |   |       NUL       | 
-                  +-----------------+   +-----------------+ 
-                  | Filesize or 0   |
-                  +-----------------+
-                  | Reserved (0)    |
-                  +-----------------+
-                  | Transaction #   |
-                  +-----------------+
-                  | File count or 0 |
-                  +-----------------+
-                  ~ Short filename  ~
-                  +-----------------+
-                  ~ Real filename   ~
-                  +-----------------+
-                  |     NUL         |
-                  +-----------------+
-                     
-    End of batch is signalled by an empty string (only the terminating
-    NUL).
-
-    The first five fields are long integers expressed in hexadecimal
-    notation.
-
-    Timestamp is a UNIX timestamp representing the creation time of the
-    file. If the creation time is not known, this is zero.
-
-    Filesize is the size of the file in bytes. If the size of the file is
-    not known, this is zero. This field should not be used as an exact
-    measure of the size of the file. It is safe to assume that you should
-    not receive less data than specified in this field, but the file may
-    grow while it is being transferred (e.g. the result of a background
-    process).
-
-    Transaction # is a unique number for each set of files being sent
-    during the session. This is primarily used to allow the receiving
-    application to group several files together and store them in
-    specific directories as a result of automated file requests. If the
-    file being sent is not a result of an automated file request, this
-    field must be set to zero.
-
-    File count is the session file counter. For the first file in a
-    session, this field contains the total number of files to be sent
-    during the session; for subsequent files, it contains the file number
-    in the session, starting with two (2). If the total number of files
-    is not known, this field contains zero for all files.
-
-    The first filename field must be specified in lowercase characters.
-    It must conform to MS-DOS filename conventions and not exceed 12
-    characters in length (excluding the terminating NUL character). The
-    second field, real filename, is the actual filename on the sending
-    system. If this field is not present, the short filename field is
-    used.
-
-    No directory paths may be specified in the short filename. Directory
-    paths may be specified in the real filename field if the "Desired
-    options" of the receiver contains FPT. If the real filename field
-    contains a path, it may include any ASCII character in the range 32
-    (0x20) through 255 (0xff) with \ characters translated to /. A drive
-    specifier may be present in the <Drive>: (e.g. c:) format. If both
-    the short and real filename fields are present, they are separated
-    by a NUL character. There is never more than one NUL character
-    terminating the packet.
-    
-
-    FINFOACK packet
-    ---------------------------------------------------------------------
-    Sent in response to an FINFO packet. If the FINFO packet contained
-    file information, the FINFOACK packet is also used to instruct the
-    remote how to proceed with the transfer.
-
-
-                            FINFOACK packet data
-                 +---------------------------------------+
-                 | Long file offset, special code, or 0  |
-                 +---------------------------------------+
-
-    The only data in this packet is a long integer. In response to an
-    an end of batch FINFO packet, the file offset is set to zero (0). In
-    all other cases, file offset is one of the following:
-
-
-                       File offsets and special values
-           +------+----------------------------------------------+
-           |Offset|Description                                   |
-           +------+----------------------------------------------+
-           | >=0  |Seek to specified offset and start sending (1)|
-           |  -1  |Already have file                          (2)|
-           |  -2  |Send file during another batch (not now)      |
-           +------+----------------------------------------------+
-
-    (1) This can only be something other than zero if the FINFO packet
-        specified a filesize other than zero (i.e. the size of the file
-        is known to the receiver).
-
-    (2) The sending application should consider the file as having been
-        sent successfully. This is primarily used to prevent duplicate
-        files from being transmitted.
-
-
-    DATA packet
-    ---------------------------------------------------------------------
-    Packet containing actual file data.
-
-
-                                  DATA packet
-                  +-----------------------------------------+
-                  | Long file offset of file data block     |
-                  +-----------------------------------------+
-                  ~ Variable length data block 0-2048 bytes ~
-                  +-----------------------------------------+
-
-    If the file offset corresponds with what is expected by the receiver,
-    the data block is saved and the file position increased accordingly.
-    If the file offset is not correct, DATA packets may have been lost or
-    failed the CRC check. Bad packets are ignored because it is not
-    certain that the bad packet was an actual DATA packet and not some
-    other type of packet. The file offset comparison is therefore the
-    only way to find out about lost or bad data.
-
-    When a bad data packet is detected, an RPOS packet is transmitted by
-    the receiver to force the sender to seek to the desired file offset
-    and resume transmission from it. After transmitting the RPOS packet,
-    the receiver initializes a timer and continues to monitor received
-    DATA packets while comparing their file offset with its desired
-    offset.
-
-    If the offset of a newly received DATA packet is greater than the
-    offset received in the last DATA packet prior to transmitting the
-    RPOS packet, the sender has not yet seen the RPOS packet, or the
-    DATA packet was already in the data stream when the RPOS packet was
-    transmitted.
-
-    If the received offset matches the requested offset, the transfer is
-    resumed, otherwise, a new RPOS packet is transmitted by the receiver
-    and the timer restarted.
-
-    If the timer expires, another RPOS packet is transmitted by the
-    receiver. This is repeated until the maximum number of retries has
-    been reached.
-
-    If the receiver encounters more missing or invalid DATA packets at
-    the same offset than it finds acceptable and it is not the originator
-    of the session, it may decide to revert to a one-way transfer and
-    wait with sending the remainder of its own files until the remote has
-    transmitted its end of batch signal. It is possible that some hard-
-    ware is not capable or well suited for a bi-directional file transfer
-    involving large volumes of data (see description of the IDLE packet).
-
-
-    DATAACK packet
-    ---------------------------------------------------------------------
-    Transmitted by the receiver with its current file offset after
-    receiving a valid DATA packet.
-
-
-                              DATAACK packet data
-                          +------------------------+
-                          |    Long file offset    |
-                          +------------------------+
-
-    This packet is only transmitted if there is a window in operation
-    for that direction (selected in the INIT stage of the session), in
-    which case the sender uses the DATAACK file offsets to manage its
-    transmit window. If the sender's file offset is greater than or equal
-    to the last DATAACK offset received plus the window size, no more
-    data is transmitted by the sender until a DATAACK packet is received
-    which allows the sender to proceed without exceeding the window size.
-
-    While waiting for the DATAACK packet, the sender checks its timer
-    and retry counter. If the timer expires before a valid DATAACK packet
-    is received, the next DATA packet is transmitted, the retry counter
-    incremented, and the timer restarted with half the normal timeout.
-    This system ensures that the two sides do not end up waiting for
-    each other in case packets are lost; the receiver will respond with
-    either a DATAACK or RPOS packet. Receipt of a DATAACK packet does not
-    reset the braindead timer.
-
-    There are two windowing systems the receiver can use: sliding window
-    or segmented streaming.
-
-    If the receiver is capable of simultaneous serial and disk I/O, it
-    will transmit a DATAACK packet for every received DATA packet, or
-    every few DATA packets if it wants to be more economical with line
-    capacity.
-    Sliding window transmission is just a method of keeping the runahaid
-    of the transmitter within reasonable limits (for sattelite or network
-    links with long delays), thereby allowing for faster error recovery.
-    Because of Hydra's tolerancy to delays and method of error recovery,
-    sliding windows transmission is not normally required and full
-    streaming can be used.
-
-    If however the receiver is not capable of simultaneous serial and
-    disk I/O, it will will process received DATA packets until the window
-    size is reached (or slightly exceeded), write the received packets to
-    disk, and then transmit one DATAACK packet to signal that it can
-    receive the next segment of data.
-
-    If the sender cannot handle simultaneous serial and disk I/O, it can
-    apply the segmented streaming technique for reading data segments of
-    the negotiated window size from disk.
-
-
-    RPOS packet
-    ---------------------------------------------------------------------
-    Transmitted by the receiver to force the sender to seek to a specific
-    position in the file and resume the transfer (as described above).
-
-    The RPOS packet is also used by the receiver to skip a file once the
-    transfer has been initiated. This is done by transmitting a RPOS
-    packet with -2 as the desired offset and then waiting for a EOF
-    packet with the same offset (-2). Once the EOF packet is received,
-    the receiver responds to it by transmitting a EOFACK packet and then
-    proceeds to wait for the next FINFO packet.
-
-
-                          RPOS packet dependent data
-                  +----------------------------------------+
-                  | Long file offset                       |
-                  +----------------------------------------+
-                  | Desired datablock size (word, 64-2048) |
-                  +----------------------------------------+
-                  | Long RPOS packet ID                    |
-                  +----------------------------------------+
-
-
-                                 File offsets 
-             +------+-------------------------------------------+
-             |Offset|Description                                |
-             +------+-------------------------------------------+
-             | >=0  |Seek to specified offset and resume sending|
-             |  -2  |Send file during another batch (not now)   |
-             +------+-------------------------------------------+
-
-    The desired data blocksize field tells the sender what blocksize
-    to use when it resumes transmitting from the specified file offset.
-
-    Each new RPOS packet should be given a different packet ID. This
-    allows the sender to identify and ignore duplicate RPOS packets.
-    The ID need not be sequential, but it must not have the same value as
-    any other RPOS packet sent during the transmission of the same file.
-    A RPOS ID value of zero (0) is not permitted. The same ID value is
-    only used when sending multiple RPOS packets due to an expired RPOS
-    packet timer as described above (DATA packet).
-
-
-    EOF packet
-    ---------------------------------------------------------------------
-    Indicates that the end of the file has been reached by the sender.
-    The packet is transmitted after the last DATA packet with file data.
-    The EOF packet only contains one field which holds the current file
-    offset of the sender (i.e. the actual size of the file).
-
-    After the EOF packet has been transmitted, the timer is set to the
-    normal timeout value. The sender then waits for an EOFACK packet
-    from the remote or for the timer to expire. In the event of a
-    timeout, the transmit/wait sequence is repeated with half the normal
-    timeout value until the maximum number of retries has been reached.
-
-    In the event that the receiver requests to skip the file by
-    transmitting a RPOS(-2) packet (see RPOS packet), the EOF packet
-    contains the same value (-2). If the sender wants to skip the file
-    currently being transmitted, it issues an EOF packet with -2 as the
-    offset value.
-
-    EOF packets with an incorrect offset should be treated by the
-    receiver as if it was an incorrect DATA packet (i.e. transmitting an
-    RPOS packet). Accepted EOF packets are acknowledged by transmitting
-    an EOFACK packet.
-
-
-                                EOF packet data
-                     +----------------------------------+
-                     | Long file offset or special code |
-                     +----------------------------------+
-
-
-                         File offsets and special value
-               +------+----------------------------------------+
-               |Offset|Description                             |
-               +------+----------------------------------------+
-               | >=0  |Final offset in file (size of file)     |
-               |  -2  |Send file during another batch (not now)|
-               +------+----------------------------------------+
-
-
-    EOFACK packet
-    ---------------------------------------------------------------------
-    Transmitted in response to an accepted EOF packet. After transmitting
-    this packet, the receiver waits for the FINFO packet of the next file
-    or end of batch.
-
-
-    END packet                                               (HEX format)
-    ---------------------------------------------------------------------
-    Once all files have been transmitted by both sides and no device
-    packets remain to be transmitted, the end of session sequence is
-    initiated. END packets are always sent in HEX format.
-
-    Two END packets are transmitted and the transmit timer set to half
-    the normal timeout. The application then waits for an END packet from
-    the remote or for the transmit timer to expire. In the event of a
-    timeout, the transmit/wait sequence is repeated until the maximum
-    number of retries has been reached. At this point, the HYDRA session
-    may be considered to be successful as both batches were completed.
-
-    If an END packet is received before timeout, another three (3) END
-    packets are transmitted and the protocol exits. Both sides need to
-    transmit END packets and receive at least one from the remote.
-
-
-    IDLE packet                                              (HEX format)
-    ---------------------------------------------------------------------
-    The IDLE packet is used to let the remote know that the application
-    is still alive. This is only applicable in uni-directional transfer
-    mode to let the remote know that your application is still alive when
-    it is receiving files, and after having transmitted an end of batch
-    signal to the remote and not having any more files to send for the
-    remainder of the session.
-
-    When applicable, the IDLE packet is transmitted every 20 seconds. The
-    remote resets its braindead timer upon receipt of an IDLE packet. If
-    an application receives an IDLE packet while it is in a state where
-    it is transmitting IDLE packets to the remote, something is wrong.
-    This could occur if both sides have accidentally switched to one-way
-    mode waiting for the remote to finish its batch. In this situation,
-    one-way should be disabled to prevent a complete deadlock. Note that
-    if both sides have finished their batch, the end of session sequence
-    (see END packet) should be initiated.
-
-
-    DEVDATA packet
-    ---------------------------------------------------------------------
-    Support for the DEVDATA and DEVDACK packets is optional and indicated
-    in the INIT packet with the DEV flag in the "Supported options"
-    field. The ID value is a long, different for each new device data
-    packet sent. A value of zero (0) is not permitted.
-
-    Only one DEVDATA packet may be transmitted at a time; the side
-    issuing it then waits either for a timeout of the device transmit
-    timer, or for a DEVDACK packet with the correct ID value to be
-    received from the remote. If the timer expires before a correct
-    DEVDACK packet is received, the DEVDATA packet is again transmitted,
-    and the nnumber of device transmit retries incremented. If the
-    maximum number of retries is reached, the HYDRA session is aborted;
-    apparently the other is not functioning properly, or data is not
-    getting through. In either case, the normal operation of the
-    protocol (transferring files) will also fail.
-
-    The name of the device to which the data is addressed is transmitted
-    as an uppercase fixed-length three character NUL terminated string.
-    There are two pre-defined device names as described below. If an
-    unknown device name is specified, or a duplicate DEVDATA packet is
-    received (one with the same ID value as a previously received and
-    acknowledged DEVDATA packet), the packet is simply discarded after
-    transmitting a DEVDACK packet with the corresponding ID value.
-
-    DEVDATA and DEVDACK packets do not reset the braindead timer. They
-    operate independently from the normal protocol. Device packets may
-    only be transmitted after the initialization sequence, and before
-    both sides have completed their batch. If a DEVDATA packet has not
-    yet been acknowledged, the end of session sequence is delayed until
-    a DEVDACK packet has been sent in response.
-
-
-                       DEVDATA packet dependent data
-           +--------------------------------------------------+
-           | Long DEVDATA packet ID value                     |
-           +--------------------------------------------------+
-           | 3 character uppercase device name, NUL terminated|
-           +--------------------------------------------------+
-           ~ Variable length device data block (0-2048)       ~
-           +--------------------------------------------------+
-
-
-                           Predefined device names
-                +---+-------------------------------------+
-                |Dev|Description                          |
-                +---+-------------------------------------+
-                |MSG|Print data in protocol message window|
-                |CON|Print data to user console           |
-                +---+-------------------------------------+
-
-    The MSG device may be used to notify the remote of protocol-specific
-    issues, i.e. "One-way transfer mode". Such messages may be logged,
-    but should not be considered to be machine-readable.
-
-    The CON device may be used to implement a "chat" or conversation
-    feature. This is a special case in which a session *can* be prolonged
-    after end of batch, but not against the remote's will.
-    While chat is enabled, there is no transition from the REND to the
-    END transmitter state. When a CON device packet is transmitted in
-    chat mode and the txstate is REND, the own braindead timer is reset.
-    If the other side does initiate the end sequence by sending an END
-    packet, the chat mode is immediately terminated and the session ended
-    in a clean manner. If one side does not want to (continue) chat, and
-    the other side does not comply, the one side will abort after a
-    braindead timeout, so this chat system does not mean a security flaw.
-    Each side is responsible for keeping the session going on his end
-    until its own user has finished chatting. It is suggested that the
-    software apply a timeout of say 1 minute to keyboard input, ending
-    the chat automatically if the user stops typing but does not exit
-    chat mode. Also, the chat mode should be initiated with a special key
-    so that it can not erronously be started or prolonged.
-
-
-    DEVDACK packet
-    ---------------------------------------------------------------------
-    Transmitted in response to a DEVDATA packet. The device data ID value
-    must correspond to the ID of the previously received DEVDATA packet.
-
-
-                              DEVDACK packet data
-                         +---------------------------+
-                         | Long device data ID value |
-                         +---------------------------+
-
-
-
-DEVICE sender (devtxstate HTD_...)
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+------------------------------+--------------------------+----------+
-|Begin   |                              |devtxid = 0               |DONE      |
-|        |                              |reset devtxtimer          |          |
-+--------+-+----------------------------+--------------------------+----------+
-|DONE    |1|wish to send device data &  |increase devtxid          |DATA      |
-|        | |other side allows DEV pkts  |devtxretries = 0          |          |
-|        | |                            |reset devtxtimer          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|wish to send device data &  |Tell calling function     |          |
-|        | |other doesn't allow DEV pkts|it's not on...            |          |
-+--------+-+----------------------------+--------------------------+----------+
-|DATA    |1|devtxretries == 10          |Report too many errors    |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (devtxretries < 10)    |txpkt DEVDATA(id,dev,data)|DACK      |
-|        | |                            |devtxtimer = timeout      |          |
-+--------+-+----------------------------+--------------------------+----------+
-|DACK    |1|rxpkt DACK &                |reset devtxtimer          |DONE      |
-|        | |DACK(id) == devtxid         |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|devtxtimer expired          |Report devtx timeout      |DATA      |
-|        | |                            |increase devtxretries     |          |
-+--------+-+----------------------------+--------------------------+----------+
- 
-DEVICE RECEIVER
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+------------------------------+--------------------------+----------+
-|Begin   |                              |devrxid = 0               |DONE      |
-+--------+-+----------------------------+--------------------------+----------+
-|DONE    |1|rxpkt DEVDATA               |txpkt DEVDACK(id)         |CheckID   |
-+--------+-+----------------------------+--------------------------+----------+
-|CheckID |1|DEVDATA(id) != devrxid      |devrxid = DEVDATA(id)     |Process   |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (apparent duplicate)   |                          |DONE      |
-+--------+-+----------------------------+--------------------------+----------+
-|Process |1|DEVDATA(dev) == MSG         |Print protocol message    |DONE      |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|DEVDATA(dev) == CON         |Output to user console    |DONE      |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|DEVDATA(dev) == known&ok    |Call processing routine   |DONE      |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|else (unknown/not-ok device)|One-way into bitbucket    |DONE      |
-+--------+-+----------------------------+--------------------------+----------+
-
- 
-    Packet length and data block size
-    ---------------------------------------------------------------------
-    The maximum length of a source data block (i.e. raw, non processed
-    input file or device data) is 2048 bytes. The maximum allowed length
-    of the packet data is 2048 + 8 = 2056 bytes. The eight bytes are to
-    provide sufficient room for the additional fields in the DATA and
-    DEVDATA packets. Packetizing adds an additional three to five bytes.
-    The maximum length of a framed packet being transmitted can be three
-    times the size of its source data depending on what type of encoding
-    scheme is used (ASC, HEX, UUE, BIN). The minimum length of a data
-    block is 64 bytes.
-
-    The block size of DATA packets is based on the physical (DCE) link
-    speed and is established as follows:
-
-            +---------+------------------+-------------------+
-            |DCE speed|Maximum block size|Starting block size|
-            +---------+------------------+-------------------+
-            |  300 bps|     256 bytes    |     256 bytes     |
-            | 1200 bps|     512 bytes    |     256 bytes     |
-            | 2400 bps|    1024 bytes    |     512 bytes     |
-            |>2400 bps|    2048 bytes    |     512 bytes     |
-            +---------+------------------+-------------------+
-
-    The blocksize is initialized to the starting blocksize when a session
-    is first started. After each kilobyte of file data transmitted, the
-    blocksize is doubled until it reaches the maximum allowed blocksize.
-
-    When the maximum allowed blocksize has been reached, the variable
-    keeping track of how many bytes are needed to increase the blocksize
-    is reset to zero.
-
-    If a request for retransmission (RPOS packet) is received from the
-    receiver, the blocksize is immediately set to that specified in the
-    retransmission request. Every time this occurs, the number of bytes
-    needed to double the blocksize is increased by 1024 with a maximum of
-    of 8192 bytes. The end result is that more data has to be
-    successfully transmitted before the blocksize is increased for each
-    error that occurs.
-
-    The length of a data block is dynamic and always in the range 0-2048
-    bytes. A data block is never padded. If there is insufficient data
-    to fill a block of the current blocksize, the blocksize is adjusted
-    to the amount of remaining data.
-
-    The blocksize logic is not reset between files in a session.
-
-
-    Timers and retry counters
-    =====================================================================
-    Each process in the protocol (transmit, receive and device transmit)
-    has its own timer and retry counter, and there is one overall
-    braindead timer. Allowed are 10 tries, the braindead timeout is 120
-    seconds, and the other timeouts are based on the speed of the line
-    and the state of the protocol. It can be calculated as (40960/DCE
-    rate), with a minimum of 10 seconds and a maximum of 60 seconds.
-
-                     +---------+----------+----------+
-                     |DCE speed|Timeout   |Half      |
-                     +---------+----------+----------+
-                     |  300 bps|60 seconds|30 seconds|
-                     | 1200 bps|34 seconds|17 seconds|
-                     | 2400 bps|17 seconds| 8 seconds|
-                     |>2400 bps|10 seconds| 5 seconds|
-                     +---------+----------+----------+
-
-    If the output buffer is empty, the timeout value is halved. In
-    general, this is the case if the number of tries is greater than zero
-    and during the init and end sequences. These timeouts are not fatal
-    situations, they just give the remote a reasonable amount of time to
-    receive and respond to a packet before a retry occurs. Duplicate
-    packets are always identified and ignored. A retry counter is reset
-    if there is a change of state, or a reposition different from the
-    previous file offset occurs.
-
-    The braindead timer monitors useful data from the other side: a first
-    response to a transmitted supervisiory packet, or a received packet
-    with file data at the correct offset. Device packets and packets that
-    do not signify any progress of the protocol do not affect the
-    braindead timer.
-
-    No other timers (such as one between characters in a packet) are
-    necessary.
-
-
-    Aborting a session
-    =====================================================================
-    A session is aborted with five consequetive CAN (^X or ASCII 24)
-    characters. Whenever a state table mentions "Abort", the following
-    procedure is to be followed:
-
-    Clear the output buffer and transmit eight CAN characters followed by
-    ten BS (^H or ASCII 8) characters; wait a few seconds for the data to
-    be transmitted to the remote, purge the input buffer and exit the
-    protocol code.
-
-
-GENERAL sender (txstate HTX_...)
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+------------------------------+--------------------------+----------+
-|Begin   |                              |txretries = 0             |START     |
-|        |                              |reset txtimer             |          |
-|        |                              |blksize = startblksize    |          |
-|        |                              |goodbytes = 0             |          |
-|        |                              |goodneeded = 1024         |          |
-|        |                              |braintimer = 120          |          |
-+--------+-+----------------------------+--------------------------+----------+
-|START   |1|txretries == 10             |Report too many errors    |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (txretries < 10)       |txstr AutoStart           |SWAIT     |
-|        | |                            |txpkt START               |          |
-|        | |                            |txtimer = 5               |          |
-+--------+-+----------------------------+--------------------------+----------+
-|SWAIT   |1|rxpkt START or              |txretries = 0             |INIT      |
-|        | |rxpkt INIT                  |reset txtimer             |          |
-|        | |                            |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|txtimer expired             |Report tx timeout         |START     |
-|        | |                            |increment txretries       |          |
-+--------+-+----------------------------+--------------------------+----------+
-|INIT    |1|txretries == 10             |Report too many errors    |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (txretries < 10)       |txpkt INIT(linkinfo)      |INITACK   |
-|        | |                            |txtimer = timeout/2       |          |
-+--------+-+----------------------------+--------------------------+----------+
-|INITACK |1|rxpkt INITACK               |txretries = 0             |RINIT     |
-|        | |                            |reset txtimer             |          |
-|        | |                            |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|txtimer expired             |Report tx timeout         |INIT      |
-|        | |                            |increment txretries       |          |
-+--------+-+----------------------------+--------------------------+----------+
-|RINIT   |1|rxstate != INIT             |                          |NextFile  |
-+--------+-+----------------------------+--------------------------+----------+
-|NextFile|1|No files left?              |Report end of batch       |ToFName   |
-|        | |                            |Set NULL fileinfo         |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|Can access next file?       |Set up fileinfo           |ToFName   |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|Can't access file?          |Report access failure     |NextFile  |
-+--------+-+----------------------------+--------------------------+----------+
-|ToFName |                              |txsyncid = 0              |FINFO     |
-|        |                              |txretries = 0             |          |
-|        |                              |reset txtimer             |          |
-+--------+-+----------------------------+--------------------------+----------+
-|FINFO   |1|txretries == 10             |Report too many errors    |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|txretries > 0               |txpkt FINFO(fileinfo)     |FINFOACK  |
-|        | |                            |txtimer = timeout/2       |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (txretries == 0)       |txpkt FINFO(fileinfo)     |FINFOACK  |
-|        | |                            |txtimer = timeout         |          |
-+--------+-+----------------------------+--------------------------+----------+
-|FINFOACK|1|NULL fname (end of batch) & |txtimer = idletimeout     |REND      |
-|        | |rxpkt FINFOACK              |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|rxpkt FINFOACK &            |txpos = FINFOACK(pos)     |DATA      |
-|        | |FINFOACK(pos) >= 0          |txretries = 0             |          |
-|        | |                            |txlastack = 0             |          |
-|        | |                            |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|rxpkt FINFOACK &            |They already have file    |NextFile  |
-|        | |FINFOACK(pos) == -1)        |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|rxpkt FINFOACK &            |Skip this file for now    |NextFile  |
-|        | |FINFOACK(pos) == -2)        |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|txtimer expired             |Report tx timeout         |FINFO     |
-|        | |                            |inrease txretries         |          |
-+--------+-+----------------------------+--------------------------+----------+
-|DATA    |1|rxstate != Done &           |txtimer = idletimeout     |XWAIT     |
-|        | |hdxlink == True             |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|rxpkt DATAACK &             |txlastack = DATAACK(pos)  |          |
-|        | |DATAACK(pos) > txlastack    |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|rxpkt RPOS &                |Skip this file for now    |SkipFile  |
-|        | |RPOS(pos) < 0               |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|rxpkt RPOS &                |Report too many errors    |Abort     |
-|        | |RPOS(id) == txsyncid &      |                          |          |
-|        | |inc txretries == 10         |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|rxpkt RPOS &                |txpos = RPOS(pos)         |          |
-|        | |RPOS(id) != txsyncid &      |txsyncid = RPOS(id)       |          |
-|        | |RPOS(pos) >= 0              |txretries = 1             |          |
-|        | |                            |blksize = RPOS(blksize)   |          |
-|        | |                            |goodbytes = 0             |          |
-|        | |                            |inc goodneeded + 1024     |          |
-|        | |                            |if (goodneeded > 8192)    |          |
-|        | |                            |   goodneeded = 8192      |          |
-|        | |                            |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |6|File seek/read error or     |Skip this file for now    |SkipFile  |
-|        | |user wishes to skip file    |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |7|txwindow &                  |if (txretries > 0)        |DATAACK   |
-|        | |txpos >= txlastack+txwindow |   txtimer = timeout/2    |          |
-|        | |                            |else                      |          |
-|        | |                            |   txtimer = timeout      |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |8|Enough room in output &     |txpkt DATA(pos,data)      |          |
-|        | |more filedata(blksize) to go|txpos += datalen          |          |
-|        | |                            |inc goodbytes + datalen   |          |
-|        | |                            |if goodbytes > goodneeded |          |
-|        | |                            |   Store txpos,blksize    |          |
-|        | |                            |   blksize * 2 (max.2048) |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |9|End of filedata reached     |                          |EOF       |
-+--------+-+----------------------------+--------------------------+----------+
-|SkipFile|                              |txpos = -1                |EOF       |
-|        |                              |txretries = 0             |          |
-+--------+-+----------------------------+--------------------------+----------+
-|DATAACK |1|txretries == 10             |Report too many errors    |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|rxpkt DATAACK &             |txlastack = DATAACK(pos)  |DATA      |
-|        | |DATAACK(pos) > txlastack &  |txretries = 0             |          |
-|        | |txpos < DATAACK(pos) + txwin|reset txtimer             |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|rxpkt RPOS                  |Handle RPOS in state DATA |          |
-|        | |                            |but stay in this state    |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|txtimer expired             |Report tx timeout         |DATA      |
-|        | |                            |increment txretries       |          |
-+--------+-+----------------------------+--------------------------+----------+
-|XWAIT   |1|rxstate == Done             |reset txtimer             |DATA      |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|rxpkt DATAACK &             |txlastack = DATAACK(pos)  |          |
-|        | |DATAACK(pos) > txlastack    |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|rxpkt RPOS                  |Handle RPOS in state DATA |          |
-|        | |                            |but stay in this state    |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|rxpkt IDLE                  |hdxlink = False           |DATA      |
-|        | |                            |reset txtimer             |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|txtimer expired             |txpkt IDLE                |          |
-|        | |                            |txtimer = idletimeout     |          |
-+--------+-+----------------------------+--------------------------+----------+
-|EOF     |1|txretries == 10             |Report too many errors    |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|txretries > 0               |txpkt EOF(txpos)          |EOFACK    |
-|        | |                            |txtimer = timeout/2       |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (txretries == 0)       |txpkt EOF(txpos)          |EOFACK    |
-|        | |                            |txtimer = timeout         |          |
-+--------+-+----------------------------+--------------------------+----------+
-|EOFACK  |1|rxpkt EOFACK                |braintimer = 120          |NextFile  |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|rxpkt DATAACK &             |txlastack = DATAACK(pos)  |          |
-|        | |DATAACK(pos) > txlastack    |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|rxpkt RPOS &                |rxpos == -2               |EOF       |
-|        | |RPOS(pos) == -2 &           |                          |          |
-|        | |rxpos != -2                 |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|rxpkt RPOS &                |Handle as in state DATA   |DATA      |
-|        | |RPOS(pos) >= 0              |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|txtimer expired             |Report tx timeout         |EOF       |
-|        | |                            |increment txretries       |          |
-+--------+-+----------------------------+--------------------------+----------+
-|REND    |1|rxstate == DONE &           |txretries = 0             |END       |
-|        | |devtxstate == DONE          |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|txtimer expired             |txpkt IDLE                |          |
-|        | |                            |txtimer = idletimeout     |          |
-+--------+-+----------------------------+--------------------------+----------+
-|END     |1|txretries == 10             |                          |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (txretries < 10)       |txpkt END (twice)         |ENDACK    |
-|        | |                            |txtimer = timeout/2       |          |
-+--------+-+----------------------------+--------------------------+----------+
-|ENDACK  |1|rxpkt END                   |txpkt END (thrice)        |Done      |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|txtimer expired             |Report tx timeout         |END       |
-|        | |                            |increment txretries       |          |
-+--------+-+----------------------------+--------------------------+----------+
-
- 
- 
-GENERAL RECEIVER (rxstate HRX_...)
-+--------+------------------------------+--------------------------+----------+
-|State   |Predicate(s)                  |Action(s)                 |Next state|
-+--------+------------------------------+--------------------------+----------+
-|Begin   |                              |reset rxtimer             |START     |
-|        |                              |lastrxdlen = startblksize |          |
-|        |                              |(tx handles braintimer)   |          |
-+--------+-+----------------------------+--------------------------+----------+
-|INIT    |1|rxpkt INIT &                |txpkt INITACK             |FINFO     |
-|        | |INIT(options) are compatible|Set options               |          |
-|        | |                            |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|INIT(options) not compatible|Report link failure       |Abort     |
-+--------+-+----------------------------+--------------------------+----------+
-|FINFO   |1|rxpkt INIT (apparent dup)   |txpkt INITACK             |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|rxpkt FINFO &               |Report end of batch       |          |
-|        | |FINFO(fileinfo) == Empty    |txpkt FINFOACK            |DONE      |
-|        | |                            |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|rxpkt FINFO &               |do not want this file     |          |
-|        | |we already have file        |txpkt FINFOACK(-1)        |          |
-|        | |                            |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|rxpkt FINFO &               |Skip this file for now    |          |
-|        | |open/diskspace error        |txpkt FINFOACK(-2)        |          |
-|        | |                            |braintimer = 120          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|rxpkt FINFO &               |rxpos = resume offset     |ToData    |
-|        | |file we want to resume      |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |6|rxpkt FINFO &               |rxpos = 0                 |ToData    |
-|        | |new file for us             |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |7|rxpkt EOF (apparent dup)    |txpkt EOFACK              |          |
-+--------+-+----------------------------+--------------------------+----------+
-|ToData  |                              |txpkt FINFOACK(rxpos)     |DATA      |
-|        |                              |rxsyncid = 0              |          |
-|        |                              |rxlastsync = 0;           |          |
-|        |                              |rxretries = 0             |          |
-|        |                              |reset rxtimer             |          |
-|        |                              |braintimer = 120          |          |
-+--------+-+----------------------------+--------------------------+----------+
-|DATA    |1|rxpkt FINFO (apparent dup)  |txpkt FINFOACK(rxpos)     |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|rxpkt DATA &                |Store data                |          |
-|        | |DATA(pos) == rxpos          |rxpos += datalen          |          |
-|        | |                            |rxretries = 0             |          |
-|        | |                            |rxlastsync = rxpos        |          |
-|        | |                            |reset rxtimer             |          |
-|        | |                            |braintimer = 120          |          |
-|        | |                            |if (rxwindow)             |          |
-|        | |                            |   txpkt DATAACK(rxpos)   |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|rxpkt DATA &                |Report bad rxpos          |BadPos    |
-|        | |DATA(pos) != rxpos          |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |4|rxpkt EOF &                 |Close file, received ok   |OkEOF     |
-|        | |EOF(pos) == rxpos           |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |5|rxpkt EOF &                 |Close, save for resume    |OkEOF     |
-|        | |EOF(pos) == -2              |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |6|rxpkt EOF &                 |Report bad EOF            |BadPos    |
-|        | |EOF(pos) != rxpos           |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |7|File write error or         |Close, save for resume    |          |
-|        | |user wishes to skip file    |rxpos = -2                |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |8|rxpkt IDLE &                |braintimer = 120          |          |
-|        | |hdxlink == False            |                          |          |
-+--------+-+----------------------------+--------------------------+----------+
-|BadPos  |1|DATA/EOF(pos) <= rxlastsync |rxretries = 0             |Timer     |
-|        | |                            |reset rxtimer             |          |
-|        | |                            |rxlastsync = pos          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|DATA/EOF(pos) > rxlastsync  |rxlastsync = pos          |Timer     |
-+--------+-+----------------------------+--------------------------+----------+
-|Timer   |1|rxtimer expired             |                          |HdxLink   |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (rxtimer not expired)  |                          |DATA      |
-+--------+-+----------------------------+--------------------------+----------+
-|HdxLink |1|rxretries > 4 &             |hdxlink = True            |Retries   |
-|        | |txstate < REND &            |rxretries = 0             |          |
-|        | |originator == False &       |                          |          |
-|        | |hdxlink == False            |                          |          |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|else (above not the case)   |                          |Retries   |
-+--------+-+----------------------------+--------------------------+----------+
-|Retries |1|inc rxretries == 10         |Report too many errors    |Abort     |
-|        +-+----------------------------+--------------------------+----------+
-|        |2|rxretries == 1              |increase rxsyncid         |RPos      |
-|        +-+----------------------------+--------------------------+----------+
-|        |3|else (rxretries > 1)        |                          |RPos      |
-+--------+-+----------------------------+--------------------------+----------+
-|RPos    |                              |lastrxdatalen/=2 (min.64) |DATA      |
-|        |                              |txpkt RPOS (rxpos,        |          |
-|        |                              |   lastrxdatalen,rxsyncid)|          |
-|        |                              |rxtimer = timeout         |          |
-+--------+------------------------------+--------------------------+----------+
-|OkEOF   |                              |txpkt EOFACK              |FINFO     |
-|        |                              |reset rxtimer             |          |
-|        |                              |braintimer = 120          |          |
-+--------+-+----------------------------+--------------------------+----------+
-|DONE    |1|rxpkt FINFO (apparent dup)  |txpkt FINFOACK(-2)        |          |
-+--------+-+----------------------------+--------------------------+----------+
-
-
-    HYDRA in FidoNet technology mailers
-    =====================================================================
-    HYDRA is suitable for use in FidoNet mailers. It can be implemented
-    for EMSI and FTS-6 mail sessions. The FTS-6 (YooHoo) capability bit
-    for HYDRA is 0x0020 (DOES_HYDRA). The EMSI and IEMSI protocol
-    capability flag is HYD.
-
-    When utilizing HYDRA in a mail session, two complete batches are
-    always performed. Little else differs from a normal FTS-6 ZedZap mail
-    session. The first batch is used to transmit all mail, files, and
-    file requests by both sides. The second batch is always performed,
-    sending nothing if there are no file requests to honor. The data
-    buffers are not purged between the two batches since HYDRA ignores
-    any leftovers from the previous batch (END packets, etc.).
-
-    To integrate HYDRA into an existing mailer, the same code used for
-    the ZedZap session flow can be used, but instead of one transmit and
-    one receive session, two transmit sessions (or batches) are used.
-    When the HYDRA end of batch is initiated it will not be terminated
-    until an end of batch has been received from the remote and the end
-    of session sequence has been finished.
-
-    Fido and FidoNet are registered marks of Tom Jennings and Fido
-    Software.
-
-
-    Error detection using CRCs
-    =====================================================================
-    CRC (Cyclic Redundancy Check) values only provide their promised
-    maximum error detection capability when properly applied, which
-    involves calculating and transmitting low-bit first, presetting the
-    CRC with all ones, and transmitting the ones' complement of the
-    result. The receiver also initializes to all ones, processes all of
-    the data AND the following CRC, and the result should match a "magic
-    value" which is 0xf0b8 for the 16-bit CRC and 0xdebb20e3 for the
-    32-bit CRC.
-
-    The easiest and fastest way to perform CRC calculations is by using a
-    table that does the algorithm's shift-operations in 8-bits at a time.
-
-
-    CRC-16 error detection
-    ---------------------------------------------------------------------
-    16-bit CRC using the CCITT CRC-16 polynomial. This is the default at
-    startup, and always used for HEX packets even if both sides are
-    capable of handling 32-bit CRCs.
-
-    This CRC-16 is not identical to the one used by the Xmodem and Zmodem
-    file transfer protocols. The polynomial is the same
-    (X^16+X^12+X^5+X^0 or 0x8408) but the bit-ordering is the opposite,
-    and preconditioning and postconditioning is used as in 32-bit CRCs.
-    This method is also used by the European version of X.25.
-
-    The 16-bit CRC table is created as follows (pseudocode, the variable
-    CRC16 and the table of 256 entries are 16-bit unsigned integers):
-
-        FOR (i=0 TO 255)
-            {
-            CRC16=i
-            FOR (N=1 TO 8)
-                {
-                IF (CRC16 AND 1)
-                    CRC16=(CRC16 >> 1) XOR 0x8408
-                ELSE
-                    CRC16=CRC16 >> 1
-                }
-            CRC16TAB[i]=CRC16;
-            }
-
-    When processing data, each byte is run through the CRC calculation
-    routine as follows (variable CRC stores the 16-bit CRC value/result,
-    C is the next 8-bit char):
-
-        CRC=CRC16TAB[(CRC XOR C) AND 0xff] XOR ((CRC>>8) AND 0x00ff)
-
-
-    CRC-32 error detection
-    ---------------------------------------------------------------------
-    32-bit CRC using the CCITT CRC-32 polynomial. Support of CRC-32 is
-    optional and signalled in the INIT packet.
-
-    If both sides indicate they can handle CRC-32, all packets except
-    those transmitted in HEX format use this algorithm instead of CRC-16
-    to improve error detection.
-
-    This CRC-32 is identical to the one used by the Zmodem protocol.
-    The polynomial is (0xedb88320):
-
-    X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0
-
-    The principal method of calculation, transmission, and checking is
-    identical to CRC-16 as described above, but the "magic value" for
-    32-bit CRC is 0xdebb20e3.
-
-    The CRC-32 table is created as follows (pseudocode, the variable
-    CRC32 and the table of 256 entries are 32-bit unsigned integers):
-
-    FOR (i=0 TO 255)
-        {
-        CRC32=i
-        FOR (N=1 TO 8)
-            {
-            IF (CRC32 AND 1)
-                CRC32 = (CRC32 >> 1) XOR 0xedb88320
-            ELSE
-                CRC32 = CRC32 >> 1
-            }
-        CRC32TAB[i] = CRC32;
-        }
-
-    When processing data, each byte is run through the CRC calculation
-    routine as follows (variable CRC stores the 32-bit CRC value/result,
-    C is the next 8-bit character):
-
-        CRC=CRC32TAB[(CRC XOR C) AND 0xFF] XOR ((CRC>>8) AND 0x00ffffff)
-
-
-    The authors
-    =====================================================================
-    The authors can be reached at the following addresses:
-
-    Joaquim H. Homrighausen                    Arjen G. Lentz
-    389, route d'Arlon                         Lentz Software Development
-    L-8011 Strassen                            Langegracht 7B
-    Luxembourg                                 3811 BT Amersfoort
-                                               The Netherlands
-	joho@ae.lu
-    FidoNet 2:270/17                           aglentz@fido.lu
-                                               FidoNet 2:283/512
-
-
-    The name HYDRA
-    =====================================================================
-    Hydra is a greek mythological creature (the watersnake). Like the
-    Nemeic lion, Hydra is the daughter of the giant Typhon and the snake
-    Echidna.
-
-    She grew up in the marshes of Lerna near/in Argolis (Argos). There
-    she ate entire herds of cattle and destroyed large cropfields. Later,
-    she lived in caves on a hill near the spring of Amymone.
-
-    Hydra is a monstrous large snake with nine heads: eight mortal ones,
-    and one (the middle one) immortal. She was defeated and killed by
-    Heracles (Hercules) - son of Zeus and Alcemene, grandson of Perseus -
-    as the second of his twelve tasks, with the help of his cousin
-    Iolaos. Every time he cut of one of the heads with his sword, two new
-    heads grew in its place. So Iolaos scorched the wound of each cut off
-    head with burning branches so the head couldn't grow on again.
-
-    Heracles buried the last and immortal head under a stone nearby. He
-    also dipped his arrows in Hydra's poisonous blood, thereafter the
-    wounds caused by those arrows were incurable.
-
-
-    Also star constellation (sign of the watersnake) in the equatorial
-    zone.
-
-
-    Also a type of sweetwater polip (the Hydroidea Thin, tubeshaped body
-    can be full contracted, just like the six (or more) tentacles. There
-    is no generation change, the gender-products grow directly on the
-    body.
-
-    The animals catch their prey with nettlecells, and are very verocious.
-    They can be found in various stilstanding and flowing water and were
-    first described by Anthonie van Leeuwenhoek in the year 1704.
-
-
-    Also small island (spelled Idhra in modern Greek) of the Sargonic
-    group in the Aegean Sea, just of the eastern tip of the Argolis
-    peninsula of the Peloponesus (Attika). Its length (NE/SW) is 21 km,
-    with a total area of 49,6 square km. Its highest point is 597 meters
-    above sea level. Population of 2794 (latest census: 1981). Only one
-    real city with the same name as the island. Once quite wooded and
-    well watered, now denuded and dry, with almost no arable land
-    (infertile limestone). Certain times of the year the people have to
-    ship in water from the main land. Its Turkish name is Camliza which
-    means "Place of Pines".
-
-    References:
-         Dutch:  Oosthoeks Encyclopedie
-                 Grote Winklerprins Encyclopedie
-       English:  Encyclopaedia Brittannica
-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0087.html b/html/ftsc/fsc-0087.html deleted file mode 100755 index 238844a4..00000000 --- a/html/ftsc/fsc-0087.html +++ /dev/null @@ -1,306 +0,0 @@ - - - -File Forwarding in Fidonet Technology Networks. - - - - -
-  | Document: FSC-0087
-  | Version:  001
-  | Date:     31 October, 1995
-  |
-  | Robert Williamson FidoNet#1:167/104.0
-
-    File Forwarding in Fidonet Technology Networks
-    Robert Williamson FidoNet#1:167/104.0  robert@ecs.mtlnet.org
-
-    Purpose: 
-        To  document  current practices in File Forwarding and the minimum
-    requirements and known extensions of the TIC file format.
-
-    Acknowledgements:
-        The  TIC  file  format  was introduced by Barry Geller, in the MSDOS
-    File Forwarder, Tick.  Useful extensions to this format were introduced
-    by Harald Helms, in the MSDOS FileForwarder, AllFix.
-    
-    Terminology:
-    FTN - Fidonet Technolgy Network, such as FIDONET, AMIGANET or IBMNET.
-          Sometimes used interchangably with the term DOMAIN.
-
-    FNC - FileName Conversion, process of converting filenames to msdos 8.3
-          format for transmission.
-
-    FQFA - Fully Qualified FTN Address, the format is
-              FTN#Zone:Net/Node.Point
-
-    CRC - Cyclic Redundancy Check, method to determine whether some data
-          has been altered. CRC-32 is used in File Forwarding.
-
-    TIC - a file that contains control information for the File Forwarding
-        system.   These  files  are  named  xxSTAMP.TIC,  where  xx  is  an
-        abbreviation  representing  the  File  Forwarding  program name and
-        stamp  is  a  unixdate  stamp  truncated  to 6 characters.  
-
-    UTC  -  Universal  Time  Coordinated,  the  time  at  the  0o  meridian
-        (Greenwich); previously called GMT
-
-
-    forwarding  -  the  process  of  creating and sending tic files and the
-                   associated  file to one's downlinks.
-
-    ticking - the processing of reading and verifying a tic file and it's
-              associated file.
-
-    hatching - the process of introducing a new file into a fileecho
-
-    cross-hatching - the process of forwarding a file from one fileecho
-                     (ususally restricted) to another
-
-    Associated File - The file listed in the FILE field of the TIC file.
-
-
-        Note that use of UPPERCASE on tic file keywords in this document in
-        for display purposes only.
-
-  Format of a TIC file:
-
-    Addressing:
-        In  a  tic  file  any form of FTN address representation from 3d to
-        FQFA  may  be  used.   All  File  Forwarders  must  understand  the
-        following formats:
-          zone:net/node                 - 3D 
-          zone:net/node.point           - 4D
-          zone:net/node@ftn             - 5D - point 0 assumed
-          zone:net/node.point@ftn       - 5D 
-          ftn#zone:net/node.point       - fqfa
-
-        File Forwarders should have configurable options per site as to the
-        type of addressing each of it's downlinks can understand.
-
-    Dates:
-        All dates are expressed in UTC.
-
-    TimeDateStamps:
-        All  TimeDateStamps are unix TimeDateStamps (# of seconds since Jan
-        1, 1960) in UTC and expressed in hexadecimal notation.
-
-    Case Insensitivity:
-        the  format is completely case-insensitive.  It is general practice
-        that  the  first  letter  of a keyword is uppercase.  This is not a
-        requirement.
-
-    Order Dependancy:
-        keywords are not order dependant.
-        Order  dependancy  is required in some groupings of a keyword, such
-        as PATH, VIA, DESC and APP.
-
-    Modification of address fields on PassThrough:
-        The  forwarding  site may modify the addresses in any keyword field
-        to  make  them  compliant  with  the addressing limitations of each
-        downlink.  
-
-    Stripping of SeenBys:
-        The  forwarding site may strip seenbys to current FTN, ZONE or NET,
-        when not forwarding outside of current FTN, ZONE or NET.  This does
-        not imply nor permit the stripping of of a direct downlink which is
-        outside the current strip filter.
-
-
-    Keywords:
-      There are no colons on keywords.
-
-      Each keyword line is terminated with CR LF pair.
-
-      The maximum length of a keyword line is 256 characters, including the
-      CRLF termination. Some keyword lines may have a shorter limit.
-
-      Keywords  are  separated from their data by a single space.  There is
-      no space if there is no data associated with the keyword.
-        eg:  ReturnReceipt
-
-      Keywords are case-insensitive and order independant.
-
-      Keywords not understood are to be passed-though.
-
-      Known Keywords that are blank should not be passed though.
-        For  example,  an  empty  AREADESC,  could be either dropped or the
-        blank  replaced with the proper description.
-
-      Most Keywords are passed through when processing.
-        There  are  exceptions.  In some cases, a site-specific replacement
-        may be created.
-        Keywords marked with a ^ should not be passed-through.
-
-      Keywords marked with a * are REQUIRED when processing a TIC file.
-        If  any  of these are missing, the tic file should be considered as
-        BAD and the associated file not forwarded to downlinks.
-
-      Keywords marked with a # are CREATED when hatching or forwarding.
-
-
-    *#  AREA [AreaName]
-          the TagName of the file area.
-
-        AREADESC [description of area]                    OPTIONAL
-          a  short  (80 chars) description of the file area.  This could be
-          the description found in FileBone.NA
-
-    *#  FILE [File being sent]
-          the name of the file being sent, no path
-          the filename must conform to msdos 8.3 format, unless it is known
-          that the receiving site can handle longer filenames.
-     
-    ^#  FULLNAME [original filename before FNC]           OPTIONAL FNC only
-          the original filename (no path) before FileName Conversion    
-
-    *#  CRC [CRC-32 in hex]
-          crc of the file being sent, 8 hexadecimal characters
-
-    ^   MAGIC [MagicName]               OPTIONAL
-          Name  under  which the file can be FREQed from the site listed in
-          FROM.   This  is  NOT  passed  though when forwarding, unless the
-          MAGIC  name  is  the  same  on  the  forwarding  site.  It can be
-          replaced by the appropriate name.
-
-        REPLACES [FileName]               OPTIONAL
-          Filename  (no  path)  of  a  file  hatched  in  the AREA that the
-          associated file replaces.  If the site expects FNC files, and the
-          filename  does  not confrom to msdos 8.3 convention, the REPLACES
-          name should also be FNC.
-
-     #  DESC [Description]
-          Description of the file, limited to 80 characters per line,
-          including CRLF termination.
-          If  multiple LDESC lines are used, the DESC line must provide the
-          maximum information.  No File Forwadrer is required to passthough
-          or make use of any extra DESC line after the first.
-
-     # LDESC [multiple lines]
-          A  long description of the file.  LDESC does NOT replace DESC, it
-          is  used IN ADDITION to the short description.  No File Forwarder
-          is required make use of LESC lines.
-
-     #  SIZE [Bytes]              OPTIONAL, SHOULD be required
-          Length of the file in bytes
-
-        DATE [TimeDateStamp]
-          TimeDateStamp of the file. Can be date of creation of archive.
-
-       RELEASE [TimeDateStamp]
-          Date  when file is TO BE released.  Usually used by SDS, but can
-          be used by ADS as well.
-
-       AUTHOR [name]
-          Name  of  the author of the software package being hatched.  This
-          field  is  obviously not applicable to Newsletters, Nodelists and
-          Diffs and the like.
-
-       SOURCE [authors_address]
-          FTN  address of the Author of the software package being hatched.
-          Not  necessary  the same as the ORIGIN hatch site.  Does not have
-          to be an FTN address.
-
-     ^ APP [program] [Application Specific Information]
-          The  APP  keyword  is  a  keyword  known  to programs of the name
-          indicated.  APP'S are order dependent and must be passed though.
-  
-    *#  ORIGIN [Address]
-          Site where file entered the fileecho
-
-    *^# FROM [Address] [Pwd]
-          Site  that  is  forwarding  the  file  to  the next site.  Pwd is
-          optional and rarely used, IF AT ALL.  Pwd is NEVER passed through.
-
-    ^   TO [Address]                        OPTIONAL
-          Site  to  which  this TIC and the assocaited file are being sent.
-          This keyword is included in the .TIC file when:
-            a)  the file is being routed via another system which permits
-                such routing.  
-            b)  the  platform  in  use  does  not  have  any  FTN  software
-                independant   method   of   associating   a  file  nd  it's
-                destination.   eg.   platforms  that  do not have filenotes
-                that   could  contain  this  information  as  part  of  the
-                filesystem.
-
-          If  the address in the TO line is that of the receiving site, the
-          field  is  not passed through when forwarding.  If the address in
-          the  TO  lines  IS  NOT  that of the receiving site, it should be
-          forwarded to the TO site, if a routing agreement is in place with
-          the sending site.
-
-    *^# CREATED [by] [Program Banner]
-          File  Forwarder which created the TIC file.  This is generally in
-          the form:  
-            Created [by] program_name version [copyright_info]
-
-        VIA [FROM CREATED]                  OPTIONAL (tracking)
-          Copy  of  CREATED  line of FROM, with 'Created [by]' stripped and
-          FROM  prepended.   Always passed though.  The VIA is only created
-          by the receiving site when forwarding. It is never created by the
-          hatching  site.  Therefore, in any TIC file, the addresses in the
-          FROM and VIA should never be the same.
-          examples:
-          Via 1:167/100 ALLFIX+ 4.31 Copyright (C) 1992,95 Harald Harms (2:281/910)
-          Via FIDONET#1:167/104.0 XTick 3 Copyright (c) 1995 Robert Williamson FIDONET#1:167/104.0
-
-    *#  PATH [Address] [TimeDateStamp] [date and time]
-          Address  of  Site  which  has forwarded the file.  TimeDateStamp,
-          date and time is that of when the Site received and Processed the
-          file.
-
-    * # SEENBY [Address]
-          Site  which  has  received the file.  There are multiple lines of
-          Seenby and they are unordered.
-
-    *   PW [password]
-          Site or Area password.  This is case-insensitive and should be at
-          least 5 characters in length. 
-
-        PGP [signature]
-          PrettyGoodPrivacy signature. To be discussed. 
-
-    ^    ReceiptRequest -no data-               OPTIONAL
-          A  request  to the receiving system to generate a IsReturnReceipt
-          (attribute  word bit 13) messsage, in the same manner it would if
-          it  had  received  a message with the FileAttach an ReturnReceipt
-          attributes and a subject of the filename.
-          There  is  NO  requirement  to recognize this keyword.  It should
-          never be passed through.
-
-  Transmission of Files:
-
-    The  associated file, that is, the file Listed in the FILE field of the
-  TIC  file, should always be sent FIRST.  In the case of a failed session,
-  sending  the  FILE  first  prevents  the  orphaning  of  the file that is
-  normally caused by the deletion or movement of the TIC file to BAD. 
-
-    File  Forwarders should not move or delete orphaned TIC files, but this
-  can neither be relied upon nor mandated.
-
-    File  Forwaders  should  be  transparent  to  the  renaming  of file by
-  mailers.   This  means  that  if  the  mailer renames a duplicate file by
-  renaming  or  bumpinmg  a numeric extension, the File Forwarder should be
-  able  to  use  the  size  and  crc fields of the TIC to find and properly
-  rename the associated file referred to in the TIC.
-
-  File  Forwaders  should  always  delete and dequeue unsent TIC files when
-  re-hatching  the  same  or  updated  version  of an associated file.  The
-  implementor  may  wish  to  allow  exceptions  for  periodicals  such  as
-  nodediffs and newsletters.
-
- -to be continued-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0088.html b/html/ftsc/fsc-0088.html deleted file mode 100755 index 0a1a6b80..00000000 --- a/html/ftsc/fsc-0088.html +++ /dev/null @@ -1,327 +0,0 @@ - - - -Compatibility and Link Qualifier Extensions for EMSI Sessions - - - - -
-  | Document: FSC-0088
-  | Version:  001
-  | Date:     31 October, 1995
-  |
-  | Robert Williamson FidoNet#1:167/104.0
-
-    Compatibility and Link Qualifier Extensions for EMSI Sessions
-    Robert Williamson FidoNet#1:167/104.0  robert@ecs.mtlnet.org
-
-    Purpose:
-
-    The  basic  purpose of this document is to start discussions which will
-    hopefully result in an improved handshake negotiation protocol.
-
-    Scope:
-
-    Relation of flags to Types of files transferred:
-
-    The  FSC-0056  EMSI  specification  (hereafter  referred  to as EMSI-I)
-    makes  little  distinction  between  ARCmail/packets and other types of
-    files,  such  as  files attached and TIC'ed files.  In EMSI-I, the term
-    'Mail'  when  not  used  in  conjunction with the term 'compressed', is
-    interpreted to mean ANY file.
-
-    This  extension  (hereafter  referred to as EMSI-II) makes reference to
-    and  allows control of types of files in addition to 'compressed mail'.
-    References  to  'Mail'  are  changed to 'File' where common practice so
-    indicates.   The  additional qualifier flags described provide for more
-    control as to the types of files a system is prepared to receive.
-
-
-    Relation of flags to presented addresses:
-
-    The  EMSI-I  specification does not allow qualification for any address
-    other than the PRIMARY address.  This means that Link flags are limited
-    in  application  to  either  all  presented addresses or to the primary
-    presented address only.
-
-    This  extension  also  allows  application  of  Link  flags to specific
-    addresses other than the primary.
-
-
-    Distinctions between Calling and Answering System:
-
-    In  the EMSI-I spec, the type of flags that may be presented is limited
-    by  the  status  of the site.  Certain flags may only be presented when
-    the  site  is the caller and other flags may only be presented when the
-    site   is   the   answerer.    This  proposed  extension  removes  this
-    distinction.
-
-    In the EMSI-I spec, certain Link and Capability (a.k.a:  Compatibility)
-    flags  are  caller-driven, while others are controlled by the answering
-    system.  This specification attempts to harmonize these discrepancies.
-
-    A  attempt  is made to remain somewhat backwards compatible and to have
-    new  flags  follow the original flag naming convention.  However, IMHO,
-    it  would  be preferable to harmonize the flags; reducing the number of
-    them  while retaining the fine type control, so that the same codes are
-    used in all sessions.
-
-    Under  both  EMSI-I and EMSI-II, any flags that are not understood, are
-    to  be  ignored.   Therfore,  if  a site presents it's flags in EMSI-II
-    format  and  the  other site does not do EMSI-II, it is permissable for
-    that site to interpret all flags according to EMSI-I specifications.
-
-
-    Specifics:
-
-    Compatibility flags:
-
-    Compatibility  flags  consist of a string of codes that specify the
-    PROTOCOL CAPABILITIES and ENABLED FEATURES of the mailer.
-
-    ARC, XMA
-    These  EMSI-I  compatibility  flags  have  no  meaning  relavant to the
-    transfer  of  files  and  are  not  to  be presented under EMSI-II.  If
-    received, they are to be ignored.
-
-
-    FNC    
-    The FNC EMSI-I compatibility flag has been identified as a 'mistake' by
-    the  author  of EMSI-I.  This is agreeable as that specification called
-    for   the   creation   of   a   filename   that  was  ALWAYS  8.3,  not
-    up-to-8.up-to-3.
-    It   is   not  to  be  presented  under  EMSI-II.   If  received  as  a
-    compatibility flag, it is to be ignored.
-
-
-    Protocol Selection:
-
-    In  the EMSI-I spec, a requirement is placed upon the calling system to
-    present  it's  available  protocols  in  order  of preference.  A quote
-    follows:
-
-        The calling system must list supported protocols first and
-        descending order of preference (the most desirable protocol
-        should be listed first).
-        The answering system should only present one protocol and it
-        should be the first item in the compatibility_codes field.
-
-    Some mailer authors have interpreted 'the compatibility_codes field' in
-    the  second  sentence  to  mean  that  of the answering system, thereby
-    making  protocol  selection RECEIVER-PREFS driven.  This interpretation
-    makes  unnecessary  the  'decending  order' requirement placed upon the
-    calling   system,   so  shall  be  considered  in  conflict  with  that
-    requirement.
-
-     Most   mailer  authors  have  interpreted  that  phrase  to  mean  the
-    'compatibility_codes  field'  OF  THE  CALLER,  thereby making protocol
-    selection  CALLER-PREFS  driven.   Since  EMSI-I  was intended to be "a
-    clear  protocol  definition  for  state-of-the-art  E-Mail  systems  to
-    follow",  they  cannot  be  faulted  for  interpretation.  Caller-prefs
-    driven  selection  is state-of-the-art, receiver-prefs driven selection
-    is older technolgy, such as Wazoo.
-
-    This   specification   requires   that   the   second  interpretation,
-    CALLER-PREFS driven, be mandatory.
-
-
-    New Compatibilty Flags:
-    ----------------------
-
-    EII
-    Indicates   that   the   system   will   interpret   flags  under  this
-    specification, if other end also presents this flag.  IF either or both
-    systems  do  not  present  this  flag,  all  interpretations  are  done
-    according to EMSI-I.
-
-    DFB
-    Indicates  that  the  system  presenting  is  capabable of fall-back to
-    FTS1/WAZOO  negotiation  in the case of failure of EMSI handshake or no
-    common  protocol.   Since  ZMO  is  the  minimum required protocol, NCP
-    should  only  occur  if  the  answering  system  presents more than one
-    protocol..  (ie. it's broken)
-
-    FRQ
-    Indicates  that  the  system  will  accept  and  process  file requests
-    received  during  outbound  calls.   In other words, the calling system
-    will  do a second turnaround for uni-directional protocols, to send the
-    files requested, at his cost.
-
-    NRQ
-    NRQ should be presented ONLY IF the mailer does not have a file request
-    server, task or function and cannot accept requests..  It should NOT be
-    used to indicate that the  function  is  temporarly disabled. 
-
-    When  examined,  No  requests will be sent.  It would be advisable that
-    the  mailer  alert  the  system  operator  of this occurance to prevent
-    continued polling of the remote site.
-
-
-    Protocol Capabilities:
-
-    Protocol   capability   flags  are  presented  in  decending  order  of
-    preference  by  the  caller.  The answering system selects and presents
-    the  FIRST  protocol  from  the  callers  list  that  it supports.  The
-    answering system must present only ONE protocol.
-
-    HYD  Hydra bi-directional    (link flags define parameters)
-    JAN  Janus bi-directional
-    TZA  DirectZap               (TrapDoor DirectZap varient)
-    DZA  DirectZap               (Zmodem variant, reduced escape set)
-    ZAP  ZedZap                  (Zmodem variant, upe 8K blocks)
-    ZMO  Zmodem w/1,024 packets  (Wazoo ZedZip)
-    SLK  SeaLink                 (no TYSNC, No MDM7, No TeLink)
-                                 (8-32k window/ReSync/OverDrive/LongNames)
-
-    NCP
-    This  is  presented  if  no compatible protocol can be negotiated under
-    EMSI.   Since  in  most  FTN  networks,  a  common protocol DOES exist,
-    fallback   to  WaZoo  and  FTS1  negotiation  is  expected.   If  these
-    negotiation methods are not available, the session is terminated.
-
-    This  condition  should  never  occur  under  normal circumstances.  It
-    should  be  considered as a problem with the design or configuration of
-    one of the mailers involved.
-
-    Link flags:
-    ----------
-
-    Link  flags  consist  of a string of codes that specify DESIRED CONNECT
-    CONDITIONS.   They  apply  to  the CURRENT SESSION ONLY.  Under EMSI-I,
-    there are four TYPES of link flags:  communications parameters, session
-    parameters, pickup options and hold options.  Under EMSI-II, only three
-    types  are  used,  the communications parameters type is REMOVED, as it
-    serves no purpose whatsoever in FTN operations.
-
-
-    Link Session options:
-
-    FNC
-    If  either  system  presents  this  flag,  it is an indication that the
-    presenting   system   requires   filename   conversion   to  cp/m-msdos
-    conventions.  The other system will convert filenames to cp/m cpm/msdos
-    8.3 conventions before sending. 
-    The   convention   is   defined   as   a  filename  consisting  of  two
-    parts,  the  filepart  and  extension.   The filepart and extension are
-    separated  by a period ".".  The filepart may be from 1 to 8 characters
-    in  length  and  the  extension  may  be  from  0 to 3 characters.  The
-    character set shall be any uppercase character in the range A-Z and any
-    numeric  character  in  the  range  0-9.   If  the extension is of zero
-    length, the period may or may not be present.
-
-
-    RMA
-    Indicates that the presenting site is able to send and process multiple
-    file  requests.   If both sites present this flag, the caller will send
-    any REQ files found for each AKA presented by the answering system.
-    The answering system will process each received REQ.
-
-    RH1
-    Indicates  that  under  the  Hydra  protocol,  batch  one contains file
-    requests only, while batch 2 is reserved for all other files.
-    
-
-    (others to be defined)
-
-    Pickup and Hold Flags:
-
-    Under  the  EMSI-I  specification, Link Pickup flags are only presented
-    when  calling (an Outbound Session) and are examined and processed only
-    when  answering  (an  Inbound  Session)  and  Link  Hold flags are only
-    presented  when  answering  (an  Inbound  Session) and are examined and
-    processed only when calling (an Outbound Session).
-
-    With  EMSI-II,  BOTH  Pickup and Hold flags are presented by both sites
-    during  a  session.   This  allows  more control for those systems, for
-    example,  which  cannot  modify  addresses  presented or rotate akas to
-    change  the  primary  address  presented  on  a per-session or per-site
-    basis.
-
-
-    Link Pickup and Hold:
-
-    Each  system can present one of three (or more) Link options related to
-    application of addresses.  If neither of these flags are presented, PUA
-    is to be assumed.
-
-    Neither  PUA  nor  PUP  is  to  be  presented  if  only one address was
-    presented.
-
-             PUP     Pickup FILES for primary address only
-          /  PUA     Pickup FILES for all presented addresses
-         /   PUn     Pickup FILES for address number n in AKA list
- one of |
-         \
-          \  NPU     No FILE pickup desired. (calling system)
-             HAT     Hold all FILES          (answering system)    
-             HAn     Hold all FILES for address number n in AKA list
-
-
-    Qualifiers:
-
-    Qualifiers  are  processed  in  the  order presented, with any conflict
-    being  resolved  by  subsequent  qualifiers overridding any conflicting
-    previous qualifier in the list.
-
-    Qualifiers may be not be presented with either NPU or HAT and should be
-    ignored if received with NPU or HAT.
-
-    PickUp:
-
-        PMO     PickUp Mail (ARCmail and Packets) ONLY 
-        PMn     PickUp Mail ONLY for address number n in AKA list
-
-        NFE     No TIC'S, associated files or files 
-                attachs desired
-        NFn     No TIC'S, associated files or file attaches, 
-                for address number n in AKA list
-
-        NXP     No compressed mail pickup desired 
-        NXn     No compressed mail pickup desired, 
-                for address number n in AKA list
-
-        NRQ     File requests not accepted by caller
-                This  flag is presented if file request processing
-                is disabled TEMPORARILY for any reason
-        NRn     File requests not accepted by caller
-                for address number n in AKA list
-
-     Note that NFE,NPX,NRQ != NPU
-
-    Hold:
-
-        HNM     Hold all traffic EXCEPT Mail (ARCmail and Packets)
-        HNn     Hold all traffic EXCEPT Mail (ARCmail and Packets)
-                for address number n in AKA list
-
-        HXT     Hold compressed mail traffic.
-        HXn     Hold compressed mail traffic.
-                for address number n in AKA list
-
-        HFE     Hold tic's and associated files
-                and file attaches other than mail 
-        HFn     Hold tic's and associated files
-                and file attaches other than mail 
-                for address number n in AKA list
-
-        HRQ     Hold file requests (not processed at this time)
-                This  flag is presented if file request processing
-                is disabled TEMPORARILY for any reason
-        HRn     Hold file requests (not processed at this time)
-                for address number n in AKA list
-
-     Note that HXT,HRQ,HFE == HAT
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0091.html b/html/ftsc/fsc-0091.html deleted file mode 100755 index daedbf11..00000000 --- a/html/ftsc/fsc-0091.html +++ /dev/null @@ -1,61 +0,0 @@ - - - -ISDN nodelist flags (rev.002). - - - - -
- | Document: fsc-0091
- | Version:  001
- | Date:     01 Jun 1996
- | Arjen Lentz, 2:283/512
-
-ISDN nodelist flags (rev.002)                   Arjen Lentz (agl@bitbike.com)
-addendum to FTS-0005                                        FidoNet 2:283/512
-superceding FSC-0075                                       October 30th, 1995
-
-Input from Michael Buenter, Jan Ceuleers, Chris Lueders, and others. Thanks!
-
-The proposed new information text in nodelist trailer is as follows:
-
-   Nodelist  Specification of minimal support required for this flag;
-   flag      any additional support to be arranged via agreement between users
-   ========  =================================================================
-   V110L     ITU-T V.110 19k2 async ('low').
-   V110H     ITU-T V.110 38k4 async ('high').
-   V120L     ITU-T V.120 56k async, layer 2 framesize 259, window 7, modulo 8.
-   V120H     ITU-T V.120 64k async, layer 2 framesize 259, window 7, modulo 8.
-   X75       ITU-T X.75 SLP (single link procedure) with 64kbit/s B channel;
-               layer 2 max.framesize 2048, window 2, non-ext.mode (modulo 8);
-               layer 3 transparent (no packet layer).
-   ISDN      Other configurations. Use *only* if none of the above fits.
-   ===========================================================================
-   NOTE: No flag implies another. Each capability MUST be specifically listed.
-   If no modem connects are support, the nodelist speed field should be 300.
-
-   Conversion from old to new ISDN capability flags:
-   - Nodes in the USA currently use the 'ISDN' flag.
-     Most will be able to change to V120H (64k lines).
-     Also many to V120L,V120H (64k lines) with autodetecting equipment.
-     Some to only V120L (still with 56k lines).
-   - Nodes in Europe currently use the ISDNA, ISDNB and ISDNC flags.
-     A simple translation will do the trick here.
-     ISDNA -> V110L
-     ISDNB -> V110H
-     ISDNC -> X75
-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsc-0093.html b/html/ftsc/fsc-0093.html deleted file mode 100755 index c9694bc0..00000000 --- a/html/ftsc/fsc-0093.html +++ /dev/null @@ -1,157 +0,0 @@ - - - -Reduced seen-by lines. - - - - -
- | Document: FSC-0093
- | Version:  001
- | Date:     13 September, 1996
- | Title:    Reduced seen-by lines
- | Author:   Frank Ellermann, 2:240/5815.1
-
-
-  Reduced seen-by lines
-  Frank Ellermann, 2:240/5815.1
-
-
-  Abstract
-  --------
-  A way to save great amounts (estimated 10 %) of echo mail traffic by
-  reducing "seen by" informations, compatible with existing echo mail
-  tossers conforming to FTS-0004.
-
-
-  Definitions
-  -----------
-  A thorough understanding of FTS-0004 is required, the reader should
-  be familiar with PATH and SEEN-BY lines in echo mail, illegal and
-  legal echo mail distribution topologies, i.e. dup-rings, as well
-  as with some pre-requisite knowledge of zones, 4D and 2D addresses,
-  and the "sticky" 2D notation in PATH and SEEN-BY lines.
-
-  PATH: path lines as specified in FTS-0004
-  FSB:  full seen-by informations as specified in FTS-0004
-  TSB:  tiny seen-by informations as mentioned in FTS-0004, see below
-  RSB:  reduced seen-by informations specified below
-  dupe: multiple arrival of the same echo mail (e.g. different paths)
-
-
-  Examples of echo mail distribution topologies
-  ---------------------------------------------
-  In all examples a) to d) echo mail entered at system 1 is sent to
-  systems 2 and 3 with FSB 1 2 3. Therefore system 2 (3) knows, that
-  system 3 (2) already got this mail, topology a) is perfectly legal.
-
-  a) 1 - 3  b) 1 - 3  c) 1 - 3  d) 1 - 2
-     | /       |   |     | / |     | X |
-     2         2 - 4     2 - 4     2 - 4
-
-  In the exanmples b) and c) both systems 2 and 3 forward all mails
-  from system 1 to system 4, these topologies contain a dup-ring and
-  are therefore illegal following FTS-0004.
-
-  The examples a) and d) show fully connected polygons with three or
-  four nodes. In example d) a mail entered at system 1 is sent to
-  systems 2, 3, and 4 with FSB 1 2 3 4. The topologies a) and d) are
-  perfectly legal, there are no dupes caused by distribution.
-
-  In example b) each mail entered at system 1 reaching system 4 via
-  system 2 carries FSB 1 2 3 4, therefore system 4 will not forward
-  such mails to 3. Using TSB at system 2 the same mails would carry
-  TSB 2 4, therefore system 4 would forward them to 3 as dupes.
-
-  Note that illegal topologies as in example b) and c) cause dupes
-  with either FSB or TSB. The real problem with TSB is example b),
-  as it allows for loop mails on the dup-ring 1 - 2 - 3 - 4 - ...
-  and vice versa, if no additional checks for dupes are employed.
-
-  With RSB (specified below) systems contained in the PATH are not
-  stripped from the seen-by informations, therefore RSB avoid loop
-  mail much like FSB.
-
-
-  FSB algorithm
-  -------------
-  1) add own system to the PATH.
-  2) all area links not contained in the FSB qualify as recipients.
-  3) add own address(es) to the FSB set if not already contained.
-  4) add recipients to FSB, sort FSB, forward mail to recipients.
-
-
-  TSB algorithm
-  -------------
-  1) add own system to the PATH.
-  2) all area links not contained in the TSB qualify as recipients.
-  3) strip old TSB and start new TSB with own address(es).
-  4) add recipients to TSB, sort TSB and forward mail to recipients.
-
-
-  RSB algorithm
-  -------------
-  1) add own system to the PATH.
-  2) all area links not contained in the RSB qualify as recipients.
-  3) strip RSB addresses not matching an address in the PATH, then
-     add own address(es) to the RSB set if not already contained.
-  4) add recipients to RSB, sort RSB and forward mail to recipients.
-
-
-  PATH considerations
-  -------------------
-  There are 2 problems with the PATH kludge as specified in FTS-0004:
-
-  First like in the FSB the addresses in the PATH are 2D, and having
-  the same 2D address in different zones is possible. Therefore zone
-  gates are required to use the TSB algorithm. Unfortunately the PATH
-  is forwarded without regarding zone gating, therefore detection of
-  loop mail based solely on the PATH could be erroneous.
-
-  Further FTS-0004 (written 1989) expects future echo mail tossers to
-  implement PATH support, but doesn't require this support from old
-  implementations. Strictly spoken the PATH is still only an option.
-
-  In some areas of FidoNet (e.g. in zone 2) at least all non-terminal
-  nodes are required to fully support the PATH line, therefore this
-  problem will probably not show up in praxis. Of course any tosser
-  implementing the RSB feature is required to fully support the PATH.
-
-
-  Summary
-  -------
-  To show the benfits of RSB compared with FSB assume the following:
-
-  An echo mail travels from node to echo hub, host, major star, echo
-  host, hub, and finally arrives at a recipient. Each routing system
-  has 10 links, i.e. FSB at the recipient contain 51 addresses, about
-  400 characters, but RSB only 15 addresses in about 150 characters.
-
-  Therefore in an echo mail with 2500 characters about 10 % of its
-  size can be reduced using RSB in favour of FSB. If this estimation
-  is applicable on world wide FidoNet echo mail traffic, RSB can save
-  us an immense amount of costs.
-
-  This document can be adopted by the FTSC as FTS, in this case it
-  has to be regarded as an addition to FTS-0004 with the extension,
-  that all non-terminal nodes are required to support PATH lines as
-  specified in FTS-0004.
-
-  For additional informations (e.g. aspects of zone gating) feel free
-  to send mails to Frank Ellermann 2:240/5815 or leo@bfispc.hanse.de
-
-- eof -
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsp-1002.html b/html/ftsc/fsp-1002.html deleted file mode 100755 index 1d5e3507..00000000 --- a/html/ftsc/fsp-1002.html +++ /dev/null @@ -1,141 +0,0 @@ - - - -Numeric reply indication in FTN subject lines. - - - - -
-**********************************************************************
-FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication:    FSP-1002
-Revision:       2
-Title:          Numeric reply indication in FTN subject lines
-Author:         Odinn Sorensen, 2:236/77
-Revision Date:  19 October 1997
-Expiry Date:    11 October 1999
-----------------------------------------------------------------------
-Contents:
-                1. Scope
-                2. Format
-                3. Reply procedure
-----------------------------------------------------------------------
-
-
-Status of this document
------------------------
-
-  This document is a Fidonet Standards Proposal (FSP).
-
-  This document specifies an optional Fidonet standard protocol for
-  the Fidonet community, and requests discussion and suggestions for
-  improvements.
-
-  This document is released to the public domain, and may be used,
-  copied or modified for any purpose whatever.
-
-
-Abstract
---------
-
-  When making a reply to a message, there are currently three common
-  ways to handle the subject line:
-
-  1. Don't change it.
-  2. Insert the string "Re: " in front of it.
-  3. Insert the string "Re^n: " in front of it, where 'n' is increased
-     by one if the original subject was already a reply.
-
-  This document concerns itself with specifying the third variant.
-
-
-1. Scope
---------
-
-  This standard is specified for all FTN messages. Implementations
-  will typically be message editors and other software that creates
-  replies to messages.
-
-
-2. Format
----------
-
-  The format is "Re^n: ", where n is an unsigned integer number with
-  one or more digits. The range of the number must be at least 0 to
-  255. Negative numbers are not allowed. Note that there must be a
-  space after the colon. The letters are not case sensitive, but
-  uppercase 'R' and lowercase 'e' is recommended.
-
-
-3. Reply procedure
-------------------
-
-  When making a reply that conforms to this specification, this
-  procedure, or a functionally identical one, must be followed:
-
-  1. If the original subject does not have a leading "Re: " or
-     "Re^n: ", put the string "Re: " in front of it. Don't use a
-     number here.
-
-     Example:   "Hello world"  ->  "Re: Hello world"
-
-  2. If the original subject has a leading "Re: ", put the string
-     "Re^2: " in front of the subject.
-
-     Example:   "Re: Hello world"  ->  "Re^2: Hello world"
-
-  3. If the original subject has a leading "Re^n: ", increase the
-     number 'n' by one and modify the subject accordingly.
-
-     Example:   "Re^4: Hello world"  ->  "Re^5: Hello world"
-
-  Notes:
-
-  * The numbers 0 and 1 should not occur in the "Re^n: " string under
-    normal circumstances, but a robust implementation should just
-    increase the number in any case.
-
-  * The number should not be increased beyond the range of the number
-    type used in the implementation, or in other words, it should not
-    roll around to zero. If it can't be increased, leave it alone.
-
-  * When inserting the "Re: " or "Re^n: " string in front of the
-    subject, information from the end might be lost, because the
-    message storage or packet formats use fixed length subject fields.
-    Intelligent subject-based reply linking software should be aware
-    of this and try to link correctly anyway.
-
-
-A. Author contact data
-----------------------
-
-  Odinn Sorensen
-  Fidonet: 2:236/77
-  E-mail:  odinn@goldware.dk
-  WWW:     http://www.goldware.dk
-
-
-B. History
-----------
-
-  Rev.1, 971011: First release.
-  Rev.2, 971019: Added note that "Re" is not case sensitive.
-
-
-**********************************************************************
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsp-1011.html b/html/ftsc/fsp-1011.html deleted file mode 100755 index aa32f008..00000000 --- a/html/ftsc/fsp-1011.html +++ /dev/null @@ -1,1757 +0,0 @@ - - - -FTSC Document FSP-1011, Revision 003 - - -
-**********************************************************************
-FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication:    FSP-1011
-Revision:       3
-Title:          Binkp - a protocol for transferring FidoNet mail over
-                reliable connections
-Authors:        Dima Maloff
-                Nick Soveiko
-                Maxim Masiutin
-Revision Date:  31 July 2000
-Expiry Date:    31 July 2002
-
-----------------------------------------------------------------------
-
-Abstract
---------
-
-   This specification defines binkp - a protocol to handle a session
-   between two Fidonet Technology systems over a reliable connection.
-   Assumption that the connection is reliable makes possible to
-   eliminate error-checking and unnecessary synchronization steps,
-   achieving both ease of implementation and major performance
-   improvement over connections with large unpredictable delays (e.g.
-   Internet).
-
-Status of this document
------------------------
-
-   This document is a Fidonet Standards Proposal (FSP).
-
-   This document specifies an optional Fidonet standard protocol for
-   the Fidonet community, and requests discussion and suggestions for
-   improvements.
-
-   This document is released to the public domain, and may be used,
-   copied or modified for any purpose whatever.
-
-Available formats
------------------
-
-   Binkp Specification is also available in HTML format at
-   http://www.ritlabs.com/binkp/
-
-Table of contents
------------------
-
-    1. Background
-         1. Objectives
-         2. Motivation for a New Protocol
-    2. Definitions
-    3. Protocol Overview
-    4. Frame Format
-         1. Notation
-         2. Examples
-    5. Protocol Commands and Their Arguments
-         1. Classification
-         2. File Name Issues
-         3. Non-ASCII Characters in Command Argument symbol string
-         4. Binkp Commands
-         5. Example of Frame Exchange in a Simple binkp Session
-    6. Protocol States
-         1. Session Setup Stage
-              1. Originating Side
-              2. Answering Side
-         2. File Transfer Stage
-         3. Session Termination
-    7. Recommended Protocol Extensions
-         1. Non-Reliable Mode
-         2. Multiple Batch Mode
-         3. Multiple Passwords Mode
-         4. Keyed Hashing Challenge-Response Authentication Mechanism
-              1. Overview
-              2. Sequence of Steps
-              3. Generating and Transmitting Challenge Data
-              4. Producing and Transmitting a Digest
-              5. Indicating CRAM Capabilities
-              6. Example of Frame Exchange During CRAM Authentication
-              7. Notes on Hash Function Algorithms
-    8. License
-    9. Glossary
-   10. References
-   11. Acknowledgements
-    A. Author Contact Data
-    B. History
-
-     ---------------------------------------------------------------
-
-1. Background
--------------
-
-  1.1 Objectives
-  --------------
-
-   It's been a long time since a new Fidonet protocol has been
-   developed, [EMSI] definitions being published last time in 1991,
-   not speaking about basic standards, [FTS-0001] and [FTS-0006].
-   Fidonet is evolving everyday and new transport layers are being
-   introduced into practice. This led to a situation when in certain
-   Fidonet Regions a visible portion of traffic, especially long
-   distance traffic generating high toll, is being carried by means of
-   protocols that formally are not Fidonet standards. This creates an
-   ambiguity for such systems in indicating their additional
-   capabilities in Fidonet nodelist and in some instances, from being
-   listed in the nodelist at all.
-
-   This document attempts to document the current practice for
-   communication between two Fidonet systems via a reliable channel,
-   provide technical reference for Fidonet software developers and
-   eventually improve Fidonet connectivity.
-
-  1.2 Motivation for a new protocol
-  ---------------------------------
-
-   Existing Fidonet Technical Standards and Fidonet Reference Library
-   documents [FTS-0001], [FTS-0006], [EMSI] specify both session
-   handshake procedures and transmission capabilities that imply:
-     * non-reliable communication channel between mailers
-     * low round-trip times in the communication channel between
-       mailers.
-
-   This was commonplace a few years ago, when Fidonet systems were not
-   using transport other than direct dial-up on a visible basis.
-   Things have changed today, when other communication media becomes
-   widely available on a day-to-day basis. This communication media
-   typically provides implementation of Physical, Data Link, Network
-   and Transport layers of the ISO/OSI Reference Model and facilitates
-   relieving Session layer of inappropriate functions, such as error
-   control, flow control, call management and data transparency
-   [Halsall95]. Examples of such communication media are TCP/IP socket
-   connection and HDLC family protocol connection.
-
-   New communication media can be generally characterized by the
-   reliable transmission service offered by it to the Session layer
-   protocol. Reliable transmission implies that:
-     * Data link and/or Transport layer protocols are responsible for
-       error control and delivery of frames in correct sequence
-     * Session layer and higher layer protocols are operating on top
-       of connection-oriented mode
-     * Quality of Service provisions (if any) result in unspecified
-       delays between transmitter and receiver
-     * connections are rarely aborted.
-
-   Combination of these factors imposed the following requirements for
-   the new Fidonet protocol:
-     * error control can be eliminated throughout the session layer
-       protocol for both handshake and default file transfer method
-     * session setup procedure should minimize number of
-       synchronization points for fast handshake
-     * protocol should be insensitive to delays and robust with
-       respect to timeouts
-     * application flow control should be moved to file level;
-       individual data frames do not need to be error checked nor
-       acknowledged
-     * protocol should be independent from both higher and lower layer
-       protocols
-     * protocol should be reasonably easy to implement and allow
-       future extensions.
-
-2. Definitions
---------------
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
-   in this document are to be interpreted as specified in [FTA-0006].
-   However, for readability, these words may sometimes not appear in
-   all uppercase letters in this specification. Although it should not
-   impact minimal realization of binkp protocol, it must be noted that
-   Protocol Extensions may override, update or obsolete requirement
-   levels indicated by the above keywords in chapters from 3 to 6
-   inclusive.
-
-   Calling party in this document is referred to as the Originating
-   side and called party is referred to as the Answering side.
-   Originating side here is the party that initiates the connection
-   between two systems.
-
-   Mailer in this document is a software that implements the protocol.
-
-   Words "frame", "packet", and "block" when used in this document
-   refer to binkp's Frames, unless explicitly stated otherwise.
-
-   Other definitions that are not local to this document can be found
-   in the Glossary.
-
-   This document is organized as following:
-
-   Frames section defines binkp's frames. Binkp/1.0 commands and their
-   arguments section provides detailed description of all defined
-   protocol commands together with recommendations for their usage.
-   Actual binkp implementation may match it's own diagrams provided
-   that such implementation remains fully compatible with current
-   specification. Protocol states section gives rigorous state
-   diagrams for the minimum realization of binkp. All mailers MUST
-   support this minimum realization. Recommended Protocol Extensions
-   section documents most important extensions to the basic protocol
-   that are in use as of the time of this writing. The License,
-   Glossary and References sections can be found at the end of this
-   document.
-
-3. Protocol Overview
---------------------
-
-   Binkp is a Fidonet session layer protocol intended for use over
-   data transparent bi-directional channels with reliable
-   transmission. There are no other requirements for the service
-   provided by the underlying protocol suite. Presentation and
-   application layer protocols are not discussed here. Whenever TCP/IP
-   socket is used, IANA registered port number for binkp 24554 SHOULD
-   be used (as registered with the Internet Assigned Numbers
-   Authority).
-
-   Functionality of the minimum protocol realization makes provision
-   for:
-     * password protected sessions
-     * 4D/5D addressing for Fidonet and technology compatible networks
-     * exchange of Type 2 [FTS-0001], Type 2.2 [FSC-0045], Type 2+
-       [FSC-0039] and [FSC-0048], Type 3 [FSC-0081] packets and
-       [FTS-0006] arcmail in both directions, including poll and mail
-       pickup, as well as transfer of any binary or ASCII files
-     * handling WaZOO [FTS-0006] file requests
-     * ensuring integrity of transmitted mail and files
-     * simultaneous bi-directional transmission
-     * maximizing performance over packet switched data networks
-
-   Binkp uses only one synchronization point during session startup,
-   that is password exchange. This feature facilitates fast session
-   startup for high latency links. Sliding window flow control is
-   incorporated on the file level. This ensures that a batch of small
-   files is transmitted with the same efficiency as a one large file.
-
-4. Frame Format
----------------
-
-   Binkp is defined in terms of sending and receiving specifically
-   formatted data blocks. We call them frames.
-
-   Command frames carry protocol commands and may change protocol
-   state. Data frames are usually appended to files being received by
-   mailers or may be discarded, depending on the protocol state.
-
-   The particular way of mapping an octet stream or a datagram stream
-   of the transport layer into binkp frames may depend on the
-   underlying protocol suite. At this time, we define such mapping for
-   TCP/IP socket connection which can also be used for similar
-   transports as well.
-
-   The socket stream is being split into binkp frames in the following
-   manner:
-
-     7 6543210 76543210
-    +-+-------+--------+--- ................ ---+
-    |T|      SIZE      |          DATA          |
-    +-+-------+--------+--- ................ ---+
-    |<-   2 octets   ->|<- up to 32767 octets ->|
-       (frame header)          (frame data)
-
-   If T bit is 0, this is a data frame.
-
-   If T bit is 1, this is a command frame.
-
-   15 bits marked SIZE carry the size of the DATA part of the frame in
-   octets (with the bit marked 0 being the least significant). That
-   is, the actual length of a binkp frame is SIZE+2.
-
-   The size of the DATA part may vary between 1 and 32767 octets. A
-   correct realization should never set SIZE to 0. Upon receiving of a
-   packet header with the SIZE field set to 0, the total length of the
-   incoming packet must be treated as 2, this packet must be dropped,
-   and the event should be logged.
-
-   The first octet of a command frame data is the command ID. The ID
-   must be between 0 and 127 inclusive.
-
-   Other octets carry command arguments. Command arguments are an
-   arbitrary symbol string that may be null-terminated. Treating of a
-   null character in the middle of a command depends on realization
-   (with the options being "treat as whitespace" or "treat as
-   end-of-line"). The terminating null character (if any) is either
-   stripped or used by mailers internally as an end-of-line marker.
-
-  4.1 Notation
-  ------------
-
-   As stated before, command ID is a small number between 0 and 127.
-   Every binkp command defined in this document has a symbolic name in
-   the form M_XXX. Symbolic names are defined in binkp commands
-   section. We will use symbolic names and not numeric command IDs to
-   refer to commands everywhere in this document.
-
-   The following notation is used to describe binkp's command frames:
-
-         M_XXX "Data string"
-
-   The actual numeric command ID for the command with the symbolic
-   name of M_XXX should be written into the first octet of the DATA
-   area of a binkp frame. "Data string" is a string to be copied into
-   DATA area starting at second octet. SIZE should be set to the total
-   length of "Data string" plus one for the octet to store the command
-   number. T bit should be set to 1.
-
-  4.2 Examples
-  ------------
-
-   M_OK "":
-
-     7 6543210 76543210 76543210
-    +-+-------+--------+--------+
-    |1|      0        1|       4|
-    +-+-------+--------+--------+
-     |                |        +----- command ID (no arguments)
-     |                +-------- frame length
-     +- command frame flag
-
-   M_NUL "TEST":
-
-    +-+-------+--------+--------+-------+--------+--------+--------+
-    |1|      0        5|       0|   T        E        S       T    |
-    +-+-------+--------+--------+-------+--------+--------+--------+
-
-5. Protocol Commands and Their Arguments
-----------------------------------------
-
-  5.1 Classification
-  ------------------
-
-   Protocol commands may be classified the following way:
-
-     * By argument type:
-                    M_SKIP. Mailer MUST parse these commands and it is not
-            recommended to log arguments of these commands as they
-            are. Mailer-parseable commands can be further subdivided
-            by containment of a file name in the argument.
-                              commands contain a file name in their arguments.
-                                 MAY ignore and/or log arguments of these commands.
-     * By protocol stage:
-                    M_PWD (must not be sent by the Answering side), M_OK (must
-            not be sent by the Originating side). These commands MUST
-            never be sent during the file transfer stage.
-                    These commands MUST NOT be sent session setup stage.
-                    any time during the session.
-
-  5.2 File Name Issues
-  --------------------
-
-   In Mailer-parseable commands that contain a file name, the file
-   name MUST NOT include a whitespace (ASCII value 20 hex). The file
-   name SHOULD NOT include symbols other than alphanumeric
-   (A-Z,a-z,0-9) and safe characters as defined below in BNF. All
-   other symbols are to be considered unsafe and SHOULD be escaped in
-   the form of two hexadecimal digits preceded by a backslash (e.g. a
-   whitespace must be transmitted as "\20").
-
-   filename        = *pchar
-   pchar           = unreserved | escape
-   unreserved      = ALPHA | DIGIT | safe
-   safe            = "@" | "&" | "=" | "+" | "%" | "$" | "-" | "_" |
-                     "." | "!" | "(" | ")" | "#" | "|"
-   escape          = "\" HEX HEX
-
-   National characters should not be escaped, but rather transmitted
-   using [UTF8] encoding (see section discussing non-ASCII characters
-   below).
-
-   The best current practice is that Mailer does not alter a file name
-   without sysop's intention. If the mailer does provide such a
-   mechanism, it MUST BE optional and it SHOULD BE off by default.
-
-   The protocol does not impose limitations on the file name length
-   other than those arising from the finite length of the binkp frame
-   itself.
-
-  5.3 Non-ASCII Characters in Command Argument Symbol String
-  ----------------------------------------------------------
-
-   Generally, mailer SHOULD use only characters from the ASCII range
-   [32...126] in the symbol strings for command arguments. In case
-   when there is a necessity to use non-ASCII characters, mailer
-   SHOULD use the [UTF8] format of the multioctet Universal Character
-   Set [ISO10646]. Mailer SHOULD use non-ASCII characters only if the
-   other side have indicated it's support by transmitting M_NUL "OPT
-   UTF8" frame during the session setup stage. Otherwise, mailer
-   SHOULD assume that the remote does not support non-ASCII characters
-   and SHOULD NOT use them in command arguments.
-
-  5.4 Binkp Commands
-  ------------------
-
-   Format: symbolic_command_name command_ID
-
-   M_NUL 0
-
-           Command arguments contain human-readable information, such
-           as nodelist info, sysop name, etc. This frame can also be
-           used by some Mailers to exchange protocol options. Mailer
-           MAY ignore and/or log arguments of M_NUL.
-
-           e.g. "ZYZ Dima Maloff"
-
-           The following format of M_NUL argument is recommended for
-           compatibility purposes:
-
-              * M_NUL "SYS system_name"
-              * M_NUL "ZYZ sysop's_name"
-              * M_NUL "LOC system_location"
-              * M_NUL "NDL system_capabilities"
-              * M_NUL "TIME remote_date_time"
-                remote_date_time format is described in [RFC822].
-                Example of valid remote_date_time is
-                Sun, 06 Nov 1994 08:49:37 GMT
-              * M_NUL "VER mailer_version protocol_version"
-                note: binkp/1.0 mailers should send "binkp/1.0" string
-                for protocol_version.
-              * M_NUL "TRF netmail_bytes arcmail_bytes"
-                traffic prognosis (in bytes) for the netmail
-                (netmail_bytes) and arcmail and files (arcmail_bytes),
-                both are decimal ASCII strings
-              * M_NUL "OPT protocol options"
-                here protocol options is a space separated list of
-                binkp options and extensions supported by the mailer.
-              * M_NUL "PHN string"
-                phone number, ip address or other network layer
-                addressing ID
-              * M_NUL "OPM string"
-                string is a message for the system operator that may
-                require manual attention
-
-   M_ADR 1
-
-           List of 4D/5D addresses (space separated).
-
-           e.g. "2:5047/13@fidonet 2:5047/0@fidonet"
-
-   M_PWD 2
-
-           Session password, case sensitive. After successful password
-           authentication of the remote, originating side proceeds to
-           the file transfer stage. This command MUST never be sent by
-           the Answering side.
-
-           e.g. "pAsSwOrD"
-
-   M_OK 4
-
-           Acknowledgement for a correct password. Upon receiving of
-           this command, originating side goes to file transfer stage.
-           This command MUST never be sent by the Originating side.
-           Arguments may be ignored.
-
-           e.g. ""
-
-   M_FILE 3
-
-           Space separated list of parameters for the next file to be
-           transmitted: filename; size in bytes; unixtime; file
-           transmission offset.
-
-           In protocol extensions, negative values for the offset may
-           have special meaning (see non-reliable mode for an example
-           of such usage), basic implementation may treat negative
-           values as an error.
-
-           Size, time and offset parameters are decimal. Until the
-           next M_FILE command is received, all data frames must carry
-           data from this file in consecutive manner. There is no end
-           of file identifier as the file size is known beforehand. If
-           there are "extra" data frames, Mailer may append this data
-           to the file. By default, transmission of each file should
-           be started from offset 0. M_GET command sent by the remote
-           MUST force the mailer to start transmission from the
-           specified offset.
-
-           e.g. "config.sys 125 2476327846 0"
-
-           or, answering to M_GET with offset 100:
-
-           "config.sys 125 2476327846 100"
-
-   M_EOB 5
-
-           End-of-Batch. M_EOB command must be transmitted after all
-           the files have been sent.
-
-           Arguments of the command may be ignored.
-
-           e.g. ""
-
-   M_GOT 6
-
-           File acknowledgement, that must be transmitted upon
-           receiving of the last data frame for current file.
-           Arguments for this command shall be the same as for the
-           M_FILE sent by remote, excluding the last argument, file
-           offset, which is not transmitted back to the system which
-           have sent M_FILE. M_GOT can also be transmitted while
-           receiving a file, in which case transmitting party may
-           interpret it as a destructive skip.
-
-           e.g. "config.sys 125 2476327846"
-
-   M_ERR 7
-
-           This command indicates a fatal error. A party sending M_ERR
-           should abort the session. Argument should contain an error
-           explanation and may be logged. Mailer sends M_ERR in
-           response for an incorrect password. Mailer NUST NOT abort a
-           session without sending a M_ERR or a M_BSY frame (though
-           state machine tables, for simplicity, may not include
-           "transmit M_ERR" instructions).
-
-           e.g. "Incorrect password"
-
-   M_BSY 8
-
-           M_BSY command is transmitted when the system encounters a
-           non-fatal error typically due to temporary lack of
-           resources to proceed with the session. The argument should
-           contain an explanation of the situation and may be logged
-           by remote. M_BSY may be sent at any time during the session
-           (including session setup stage), not only the stages
-           explicitly indicated in the finite state machine. The side,
-           which have sent M_BSY, is in legal position to abort the
-           session. Mailer MUST be able to accept M_BSY at any time.
-           Though state machine tables, for simplicity, may not
-           include handling of M_BSY command, Mailer MUST NOT be
-           confused by reception of M_BSY command.
-
-           e.g. "Too many servers are running already"
-
-           If a mailer wishes to suggest the remote a time interval
-           before the next session attempt, it may choose to transmit
-           it in the following format:
-
-           M_BSY "RETRY NNNN: explanation"
-
-           where NNNN is interval in seconds (decimal string) and
-           explanation is an arbitrary string containing explanation
-           of the matter (optional).
-
-   M_GET 9
-
-           M_GET command is a request to (re)send files. Arguments of
-           the command are the same as for the M_FILE command and
-           refer to a file which we'd like to receive from the remote.
-
-           Mailer may send M_GET when it doesn't like transmission
-           file offset (e.g. file was partially received during one of
-           the previous sessions).
-
-           e.g. "config.sys 125 2476327846 100"
-
-           Mailer reacts to this command as follows: according to the
-           first three arguments (filename/size/unixtime), it
-           determines whether the M_GET argument is the current file
-           being transmitted to the remote (or a file that have been
-           transmitted, but we are still waiting an M_GOT ack for it).
-           If this is the case, it should
-
-              * discard transmission in progress as soon as possible
-              * perform seek() to the specified offset
-              * proceed with transmission of the file requested
-                starting with an appropriate M_FILE.
-
-           For the example above, corresponding M_FILE will have the
-           following arguments: "config.sys 125 2476327846 100"
-
-           When the mailer is finished with transmitting data of the
-           requested file it may proceed with transmission of other
-           files it has for the remote.
-
-   M_SKIP 10
-
-           Non destructive skip. Parameter is a space separated list
-           of filename, size and unixtime. This command indicates that
-           the remote should postpone sending the file until next
-           session.
-
-           e.g. "config.sys 125 2476327846"
-
-  5.5 Example of Frame Exchange in a Simple Binkp Session
-  -------------------------------------------------------
-
-   +-----------------------------------------------------------------+
-   | Originating side                | Answering side                |
-   |---------------------------------+-------------------------------|
-   | M_NUL "SYS ..."                 | M_NUL "SYS ..."               |
-   | M_NUL "ZYZ ..."                 | M_NUL "ZYZ ..."               |
-   | M_NUL "LOC ..."                 | M_NUL "LOC ..."               |
-   | M_NUL "VER ..."                 | M_NUL "VER ..."               |
-   | M_ADR "2:2/2.2@fidonet"         | M_ADR "3:3/3.3@fidonet"       |
-   | M_PWD "password"                | (waiting for a password from  |
-   |                                 | remote)                       |
-   |---------------------------------+-------------------------------|
-   | (waiting for password           | M_OK "" (or M_ERR "Bad        |
-   | acknowledgement)                | password")                    |
-   |---------------------------------+-------------------------------|
-   | (got M_OK)                      | M_FILE "file2 200 42342434 0" |
-   |---------------------------------+-------------------------------|
-   | M_FILE "file1 100 423424244 0"  | data                          |
-   |---------------------------------+-------------------------------|
-   | data                            | data                          |
-   |---------------------------------+-------------------------------|
-   | data                            | data                          |
-   |---------------------------------+-------------------------------|
-   | M_EOB                           | (got file1, acknowledging it) |
-   |---------------------------------+-------------------------------|
-   | (got file2, acknowledging it)   | M_GOT "file1 100 423424244"   |
-   |---------------------------------+-------------------------------|
-   | M_GOT "file2 200 42342434"      | data                          |
-   |---------------------------------+-------------------------------|
-   |                                 | M_EOB                         |
-   +-----------------------------------------------------------------+
-
-6. Protocol States
-------------------
-
-   The protocol has two major stages: session setup (different for
-   originating side and answering side) and file transfer (where state
-   machined for both sides are the same). Methods for initiating
-   connection as well as numerical values for particular timeouts are
-   dependent on the underlying layer's protocol suite and are not
-   considered here. Mailer MAY allow configuration of timeouts in
-   reasonably wide range to cover all supported transport protocols.
-
-   The Finite State Machine notation is used throughout this section
-   as defined by [FTS-0001].
-
-  6.1 Session Setup Stage
-  -----------------------
-
-   Originating side should initiate a binkp session according to Table
-   1. Answering side should be able to act according to Table 2. Any
-   optional extensions of the handshake procedure MUST NOT confuse the
-   other side, which may choose at it's discretion to follow this
-   minimal implementation. Upon successful handshake, both sides
-   follow Table 3 (file transfer stage). That's why terms Answering
-   side and Originating side were chosen for this specification
-   instead of Client and Server - both sides play the same roles, and
-   their state machines differ in session setup stage only.
-
-   Session setup stage has the following roles
-
-     * Authentication (REQUIRED). Answering side, upon reception of a
-       password (common secret word) from Originating side, decides
-       whether the password really matches the list of presented
-       addresses, and either acknowledges it by sending M_OK frame or
-       rejects by sending M_ERR frame. This mechanism is called Basic
-       Authentication Scheme and MUST be supported by all Mailers.
-       Basic Authentication Scheme has the following limitations:
-          * If Originating side presented multiple addresses, the
-            password for all of the addresses must be the same (may be
-            solved by Multiple passwords extension).
-          * Cleartext reusable passwords are passed over a network
-            (may be solved by CRAM extension).
-          * Verification is made on Answering side only, thus
-            Originating side has no way to verify Answering side (may
-            be solved by dual CRAM or public-key cryptography, not
-            discussed in this document).
-     * Indicating protocol options (OPTIONAL). Sides may exchange
-       specially formatted M_NUL messages to indicate supported
-       extensions. Sides MAY use another technique to indicate
-       extensions.
-
-    6.1.1 Originating Side
-    ----------------------
-
-   Originating side sends M_ADR and M_PWD frames, waits for successful
-   authentication acknowledgement from the Answering side (M_OK frame)
-   and goes to file transfer stage. Originating side MUST NOT wait
-   before sending M_ADR frame, i.e. this frame should be send just
-   after setting up a connection on underlying layer. Originating side
-   MUST NOT wait before sending M_PWD except after reception of M_ADR
-   frame. The term wait in this paragraph means do not send anything
-   while expecting data from remote.
-
-                Table 1: Session setup, originating side
-   +-----------------------------------------------------------------+
-   | #  | Name       | Predicate(s)     | Action(s)           | Next |
-   |----+------------+------------------+---------------------+------|
-   | S0 | ConnInit   |                  | Attempt to          | S1   |
-   |    |            |                  | establish           |      |
-   |    |            |                  | connection          |      |
-   |----+------------+------------------+---------------------+------|
-   | S1 | WaitConn   | Connection       | Send M_NUL frames   | S2   |
-   |    |            | established      | with system info    |      |
-   |    |            |                  | (at least one M_NUL |      |
-   |    |            |                  | "SYS ..." frame     |      |
-   |    |            |                  | should be sent      |      |
-   |    |            |                  | before M_ADR)       |      |
-   |    |            |                  | Send M_ADR frame    |      |
-   |    |            |                  | with system         |      |
-   |    |            |                  | addresses           |      |
-   |    |            |                  | Set Timer           |      |
-   |    |            |                  | See if we have      |      |
-   |    |            |                  | password for the    |      |
-   |    |            |                  | remote              |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | Connection       | Report no           | exit |
-   |    |            | refused          | connection          |      |
-   |----+------------+------------------+---------------------+------|
-   | S2 | SendPasswd | Yes, we have a   | Send M_PWD          | S3   |
-   |    |            | password         | "password" frame    |      |
-   |    |            |                  | Reset Timer         |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | No, there's no   | Send M_PWD "-"      | S3   |
-   |    |            | password         | frame               |      |
-   |----+------------+------------------+---------------------+------|
-   | S3 | WaitAddr   | M_ADR frame      | See if answering    | S4   |
-   |    |            | received         | side presented the  |      |
-   |    |            |                  | address we've       |      |
-   |    |            |                  | called              |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | M_BSY frame      | Report remote is    | exit |
-   |    |            | received         | busy                |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | M_ERR frame      | Report error        | exit |
-   |    |            | received         |                     |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | M_NUL frame      | Ignore (optionally, | S3   |
-   |    |            | received         | log frame argument) |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | Other known      | Report unexpected   | exit |
-   |    |            | frame received   | frame               |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | Unknown frame    | Ignore              | S3   |
-   |    |            | received         |                     |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | Nothing happens  | Wait                | S3   |
-   |    |            |------------------+---------------------+------|
-   |    |            | Timer Expired    | Report timeout      | exit |
-   |----+------------+------------------+---------------------+------|
-   | S4 | AuthRemote | Yes, the address | See if we've sent a | S5   |
-   |    |            | was presented    | password for this   |      |
-   |    |            |                  | address             |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | No, the address  | Report we called    | exit |
-   |    |            | was not          | the wrong system    |      |
-   |    |            | presented        |                     |      |
-   |----+------------+------------------+---------------------+------|
-   | S5 | IfSecure   | Yes, we've sent  | Wait for M_OK frame | S6   |
-   |    |            | a password       |                     |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | No, there was no | Report non-secure   | T0   |
-   |    |            | password         | session             |      |
-   |----+------------+------------------+---------------------+------|
-   | S6 | WaitOk     | M_OK frame       | report secure       | T0   |
-   |    |            | received         | session             |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | M_BSY frame      | Report remote is    | exit |
-   |    |            | received         | busy (Answering     |      |
-   |    |            |                  | size MAY report     |      |
-   |    |            |                  | busy after          |      |
-   |    |            |                  | reception of        |      |
-   |    |            |                  | caller's address)   |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | M_ERR frame      | Report error        | exit |
-   |    |            | received         |                     |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | M_NUL frame      | Ignore (optionally, | S6   |
-   |    |            | received         | log arguments)      |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | Other known      | Report unexpected   | exit |
-   |    |            | frame received   | frame               |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | Unknown frame    | Ignore              | S6   |
-   |    |            | received         |                     |      |
-   |    |            |------------------+---------------------+------|
-   |    |            | Nothing happens  | Wait                | S6   |
-   |    |            |------------------+---------------------+------|
-   |    |            | Timer Expired    | Report timeout      | exit |
-   +-----------------------------------------------------------------+
-
-    6.1.2 Answering Side
-    --------------------
-
-   Originating side sends M_ADR and waits for M_ADR and M_PWD frames
-   from remote. Upon receptions of these frames, it decides whether
-   the password really matches the list of presented addresses, and
-   either acknowledges it by sending M_OK frame (and goes to file
-   transfer stage) or rejects by sending M_ERR frame (and
-   disconnects). The term wait in this paragraph means do not send
-   anything while expecting data from remote.
-
-                 Table 2: Session setup, answering side
-   +-----------------------------------------------------------------+
-   | #  | Name     | Predicate(s)        | Action(s)          | Next |
-   |----+----------+---------------------+--------------------+------|
-   | R0 | WaitConn | Incoming connection | Send M_NUL frames  | R1   |
-   |    |          | established         | with system info   |      |
-   |    |          |                     | (at least one      |      |
-   |    |          |                     | M_NUL "SYS ..."    |      |
-   |    |          |                     | frame should be    |      |
-   |    |          |                     | sent before M_ADR) |      |
-   |    |          |                     | Send M_ADR frame   |      |
-   |    |          |                     | with system        |      |
-   |    |          |                     | addresses          |      |
-   |    |          |                     | Set Timer          |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Nothing happens     | Wait               | R0   |
-   |----+----------+---------------------+--------------------+------|
-   | R1 | WaitAddr | M_ADR frame         | See if we have a   | R2   |
-   |    |          | received            | password for any   |      |
-   |    |          |                     | of the remote      |      |
-   |    |          |                     | addresses          |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | M_ERR frame         | Report error       | exit |
-   |    |          | received            |                    |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | M_NUL frame         | Log                | R1   |
-   |    |          | received            |                    |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Other known frame   | Report unexpected  | exit |
-   |    |          | received            | frame              |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Unknown frame       | Ignore             | R1   |
-   |    |          | received            |                    |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Nothing happens     | Wait               | R1   |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Timer expired       | Report timeout     | exit |
-   |----+----------+---------------------+--------------------+------|
-   | R2 | IsPasswd | Yes, we have a      | Set Timer          | R3   |
-   |    |          | password            |                    |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Yes, but we have    | Send M_ERR frame   | exit |
-   |    |          | several different   | Report             |      |
-   |    |          | passwords for       | inconsistent       |      |
-   |    |          | different addresses | password settings  |      |
-   |    |          | of the remote       |                    |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | No, there's no      | Report non-secure  | T0   |
-   |    |          | password            | session            |      |
-   |----+----------+---------------------+--------------------+------|
-   | R3 | WaitPwd  | M_PWD frame         | See if the         | R4   |
-   |    |          | received            | password matches   |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | M_ERR frame         | Report error       | exit |
-   |    |          | received            |                    |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | M_NUL frame         | Log                | R4   |
-   |    |          | received            |                    |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Other known frame   | Report unexpected  | exit |
-   |    |          | received            | frame              |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Unknown frame       | Ignore             | R4   |
-   |    |          | received            |                    |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Nothing happens     | Wait               | R3   |
-   |    |          |---------------------+--------------------+------|
-   |    |          | Timer Expired       | Report timeout     | exit |
-   |----+----------+---------------------+--------------------+------|
-   | R4 | PwdAck   | Yes, the password   | Send M_OK frame    | T0   |
-   |    |          | matches             | Report secure      |      |
-   |    |          |                     | session            |      |
-   |    |          |---------------------+--------------------+------|
-   |    |          | No, password does   | Report password    | exit |
-   |    |          | not match           | error              |      |
-   +-----------------------------------------------------------------+
-
-  6.2 File Transfer Stage
-  -----------------------
-
-   File transfer stage is based on two major routines. We call them
-   Receive Routine and Transmit Routine. These routines perform some
-   actions depending on their state variables. State variables are
-   RxState for Receive Routine and TxState for Transmit Routine.
-
-   RxState := { RxWaitF | RxAccF | RxReceD | RxWriteD | RxEOB | RxDone
-   }
-
-   TxState := { TxGNF | TxTryR | TxReadS | TxWLA | TxDone }
-
-                         Table 3: File Transfer
-   +-----------------------------------------------------------------+
-   | #  | Name         | Predicate(s)        | Action(s)      | Next |
-   |----+--------------+---------------------+----------------+------|
-   | T0 | InitTransfer | none                | Set Timer      | T1   |
-   |    |              |                     | Set RxState to |      |
-   |    |              |                     | RxWaitF        |      |
-   |    |              |                     | Set TxState to |      |
-   |    |              |                     | TxGNF          |      |
-   |----+--------------+---------------------+----------------+------|
-   | T1 | Switch       | RxState is RxDone   | Report session | exit |
-   |    |              | and TxState is      | complete       |      |
-   |    |              | TxDone              |                |      |
-   |    |              |---------------------+----------------+------|
-   |    |              | Data Available in   | call Receive   | T2   |
-   |    |              | Input Buffer        | routine        |      |
-   |    |              |---------------------+----------------+------|
-   |    |              | Free space exists   | call Transmit  | T3   |
-   |    |              | in output buffer    | routine        |      |
-   |    |              |---------------------+----------------+------|
-   |    |              | Nothing happens     | Wait           | T1   |
-   |    |              |---------------------+----------------+------|
-   |    |              | Timer Expired       | Report Timeout | exit |
-   |----+--------------+---------------------+----------------+------|
-   | T2 | Receive      | Receive routine     | Set Timer      | T1   |
-   |    |              | returned OK         |                |      |
-   |    |              |---------------------+----------------+------|
-   |    |              | Receive routine     | Close all      | exit |
-   |    |              | returned Failure    | opened files   |      |
-   |    |              |---------------------+----------------+------|
-   |    |              | Receive routine     | Call Receive   | T2   |
-   |    |              | returned Continue   | routine again  |      |
-   |----+--------------+---------------------+----------------+------|
-   | T3 | Transmit     | Transmit routine    | Set Timer      | T1   |
-   |    |              | returned OK         |                |      |
-   |    |              |---------------------+----------------+------|
-   |    |              | Transmit routine    | Close all      | exit |
-   |    |              | returned Failure    | opened files   |      |
-   |    |              |---------------------+----------------+------|
-   |    |              | Transmit routine    | Call Transmit  | T3   |
-   |    |              | returned Continue   | routine again  |      |
-   +-----------------------------------------------------------------+
-
-   Tables 4-6 are not actually state machines, but routines called
-   during file transfer stage
-
-   We define here a FIFO queue called "TheQueue", which is used to
-   pass incoming M_GET / M_GOT / M_SKIP frames from Receive Routine to
-   Transmit Routine. Receive routine itself does not react to these
-   frames.
-
-                        Table 4: Receive Routine
-   +-----------------------------------------------------------------+
-   |RxState |Predicate(s) |Condition(s) |Actions(s)|Next    |Return  |
-   |--------+-------------+-------------+----------+--------+--------|
-   |RxWaitF |Get a frame  |Haven't got a|none      |RxWaitF |OK      |
-   |        |from Input   |complete     |          |        |        |
-   |        |Buffer       |frame yet    |          |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got Data     |ignore    |RxWaitF |OK      |
-   |        |             |frame        |          |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_ERR    |Report    |RxDone  |Failure |
-   |        |             |             |Error     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_GET /  |Add frame |RxWaitF |OK      |
-   |        |             |M_GOT /      |to The    |        |        |
-   |        |             |M_SKIP       |Queue     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_NUL    |Log       |RxWaitF |OK      |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_EOB    |Report End|RxEOB   |OK      |
-   |        |             |             |of Batch  |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_FILE   |none      |RxAccF  |continue|
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got other    |Report    |RxDone  |Failure |
-   |        |             |known frame  |unexpected|        |        |
-   |        |             |             |frame     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got unknown  |ignore    |RxWaitF |OK      |
-   |        |             |frame        |          |        |        |
-   |--------+-------------+-------------+----------+--------+--------|
-   |RxAccF  |Decide how to|Accept from  |Report    |RxReceD |OK      |
-   |        |accept       |beginning    |receiving |        |        |
-   |        |Incoming File|             |file      |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Accept from  |Send M_GET|RxReceD |OK      |
-   |        |             |offset (we do|Report    |        |        |
-   |        |             |already have |receiving |        |        |
-   |        |             |a part of    |file,     |        |        |
-   |        |             |file)        |requested |        |        |
-   |        |             |             |offest    |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Accept later |Send      |RxWaitF |OK      |
-   |        |             |(or failed to|M_SKIP    |        |        |
-   |        |             |create file) |Report we |        |        |
-   |        |             |             |will      |        |        |
-   |        |             |             |accept    |        |        |
-   |        |             |             |file      |        |        |
-   |        |             |             |later, not|        |        |
-   |        |             |             |in current|        |        |
-   |        |             |             |session   |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Refuse       |Send M_GOT|RxWaitF |OK      |
-   |        |             |(delete on   |Report we |        |        |
-   |        |             |remote)      |do not    |        |        |
-   |        |             |             |accept    |        |        |
-   |        |             |             |file      |        |        |
-   |--------+-------------+-------------+----------+--------+--------|
-   |RxReceD |Get a frame  |Didn't got a |none      |RxReceD |OK      |
-   |        |from Input   |complete     |          |        |        |
-   |        |Buffer       |frame yet    |          |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got Data     |none      |RxWriteD|continue|
-   |        |             |frame        |          |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_ERR    |Report    |RxDone  |Failure |
-   |        |             |             |Error     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_GET /  |Add frame |RxReceD |OK      |
-   |        |             |M_GOT /      |to The    |        |        |
-   |        |             |M_SKIP       |Queue     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_NUL    |Log       |RxReceD |OK      |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_FILE   |Report    |RxAccF  |Continue|
-   |        |             |             |partially |        |        |
-   |        |             |             |received  |        |        |
-   |        |             |             |file      |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got other    |Report    |RxDone  |Failure |
-   |        |             |known frame  |unexpected|        |        |
-   |        |             |             |frame     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got unknown  |ignore    |RxReceD |OK      |
-   |        |             |frame        |          |        |        |
-   |--------+-------------+-------------+----------+--------+--------|
-   |RxWriteD|Write data to|Write Failed |Report    |RxDone  |Failure |
-   |        |file         |             |error     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |File Pos >   |Report    |RxDone  |Failure |
-   |        |             |Reported     |write     |        |        |
-   |        |             |             |beyond EOF|        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |File Pos =   |Close File|RxWaitF |OK      |
-   |        |             |Reported     |Send M_GOT|        |        |
-   |        |             |             |Report    |        |        |
-   |        |             |             |File      |        |        |
-   |        |             |             |Received  |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |File Pos <   |none      |RxReceD |OK      |
-   |        |             |Reported     |          |        |        |
-   |--------+-------------+-------------+----------+--------+--------|
-   |RxEOB   |Get a frame  |Didn't get a |none      |RxEOB   |OK      |
-   |        |from Input   |complete     |          |        |        |
-   |        |Buffer       |frame yet or |          |        |        |
-   |        |             |TxState is   |          |        |        |
-   |        |             |not TxDone   |          |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_ERR    |Report    |RxDone  |Failure |
-   |        |             |             |Error     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_GET /  |Add frame |RxEOB   |OK      |
-   |        |             |M_GOT /      |to The    |        |        |
-   |        |             |M_SKIP       |Queue     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got M_NUL    |Log       |RxEOB   |OK      |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got other    |Report    |RxDone  |Failure |
-   |        |             |known frame  |unexpected|        |        |
-   |        |             |or data frame|frame     |        |        |
-   |        |             |-------------+----------+--------+--------|
-   |        |             |Got unknown  |ignore    |RxEOB   |OK      |
-   |        |             |frame        |          |        |        |
-   |--------+-------------+-------------+----------+--------+--------|
-   |RxDone  |none         |none         |none      |RxDone  |OK      |
-   +-----------------------------------------------------------------+
-
-   We define the list called "PendingFiles". After we put the last
-   byte of file into output buffer, we cannot yet consider the file as
-   being successfully transmitted, thus we have to add the file to
-   this list and then look for corresponding incoming M_GET / M_GOT /
-   M_SKIP frames to remove the file from the list and decide whether
-   the file was indeed received by remote or remote will accept this
-   file later, or something else. After we have sent M_EOB frame, we
-   must wait until PendingFiles list gets empty before disconnecting.
-
-   If the connection accidentally breaks, all the files left in
-   PendingFiles are considered unsent and will be re-transmitted in
-   the next session. If the connection breaks when the remote did
-   actually receive the file (but the corresponded confirmation frame
-   (M_GOT) didn't came back to us) and we are resending this file
-   again in the next session, remote may get two copies of the same
-   file (file dupe). Binkp allows to reduce or totally suppress such
-   dupes (at a cost of performance, of course), see Non-Reliable mode
-   and "No Dupes" protocol extension (to be found in a separate
-   document at a later date).
-
-                        Table 5: Transmit Routine
-   +-----------------------------------------------------------------+
-   |TxState|Predicate(s)|Condition(s)  |Actions(s)  |Next   |Return  |
-   |-------+------------+--------------+------------+-------+--------|
-   |TxGNF  |Open next   |File opened OK|Send M_FILE |TxTryR |continue|
-   |       |file from   |              |Report      |       |        |
-   |       |outgoing    |              |sending file|       |        |
-   |       |queue       |--------------+------------+-------+--------|
-   |       |            |Failed to open|Report      |TxDone |Failure |
-   |       |            |file          |failure     |       |        |
-   |       |            |--------------+------------+-------+--------|
-   |       |            |No more files |Send M_EOB  |TxWLA  |continue|
-   |       |            |              |Report end  |       |        |
-   |       |            |              |of batch    |       |        |
-   |-------+------------+--------------+------------+-------+--------|
-   |TxTryR |Check       |TheQueue is   |none        |TxReadS|continue|
-   |       |TheQueue    |empty         |            |       |        |
-   |       |            |--------------+--------------------+--------|
-   |       |            |TheQueue is   |call ProcessTheQueue|continue|
-   |       |            |not empty     |                    |        |
-   |-------+------------+--------------+--------------------+--------|
-   |TxReadS|Read data   |Read failed   |Report Error|TxDone |Failure |
-   |       |block from  |--------------+------------+-------+--------|
-   |       |file        |Read OK,      |Send data   |TxGNF  |OK      |
-   |       |            |Reached EOF   |block frame |       |        |
-   |       |            |              |Close       |       |        |
-   |       |            |              |current file|       |        |
-   |       |            |              |Add current |       |        |
-   |       |            |              |file to     |       |        |
-   |       |            |              |PendingFiles|       |        |
-   |       |            |--------------+------------+-------+--------|
-   |       |            |Read OK, not  |Send data   |TxTryR |OK      |
-   |       |            |reached EOF   |block frame |       |        |
-   |-------+------------+--------------+------------+-------+--------|
-   |TxWLA  |Check       |TheQueue is   |none        |TxDone |OK      |
-   |       |TheQueue    |empty and     |            |       |        |
-   |       |            |RxState >=    |            |       |        |
-   |       |            |RxEOB         |            |       |        |
-   |       |            |--------------+------------+-------+--------|
-   |       |            |TheQueue is   |none        |TxWLA  |OK      |
-   |       |            |empty and     |            |       |        |
-   |       |            |RxState <     |            |       |        |
-   |       |            |RxEOB         |            |       |        |
-   |       |            |--------------+--------------------+--------|
-   |       |            |TheQueue is   |call ProcessTheQueue|continue|
-   |       |            |not empty     |                    |        |
-   |-------+------------+--------------+--------------------+--------|
-   |TxDone |none        |none          |none        |TxDone |OK      |
-   +-----------------------------------------------------------------+
-
-   We define a list called KnownFiles. This list contains files that
-   can be requested by the remote using M_GET command. This list shall
-   at least contain all the files that are part of the PendingFiles
-   list.
-
-                    Table 6: ProcessTheQueue routine
-   +-----------------------------------------------------------------+
-   | Predicate(s)       | Condition(s)       | Actions(s)            |
-   |--------------------+--------------------+-----------------------|
-   | M_GET received     | requested file is  | Report unknown file   |
-   |                    | not in the         |                       |
-   |                    | KnownFiles list    |                       |
-   |--------------------+--------------------+-----------------------|
-   | M_GET received for | Requested pos is   | Close and finalize    |
-   | a known file       | FileSize           | file.                 |
-   |                    |                    | Report that remote    |
-   |                    |                    | refused file being    |
-   |                    |                    | transmitted.          |
-   |                    |                    | Set TxState to        |
-   |                    |                    | TxGetNextFile.        |
-   |                    |--------------------+-----------------------|
-   |                    | Requested pos is   | Set file pointer to   |
-   |                    | less than FileSize | requested pos.        |
-   |                    |                    | Report that remote    |
-   |                    |                    | requested offset.     |
-   |                    |                    | Set TxState to        |
-   |                    |                    | TxReadSend.           |
-   |                    |--------------------+-----------------------|
-   |                    | Requested pos is   | Ignore frame          |
-   |                    | greater than       |                       |
-   |                    | FileSize           |                       |
-   |--------------------+--------------------+-----------------------|
-   | M_GOT file that is | none               | Close and finalize    |
-   | currently          |                    | file                  |
-   | transmitting       |                    | Report Remote refused |
-   |                    |                    | file being            |
-   |                    |                    | transmitted           |
-   |                    |                    | Set TxState to TxGNF  |
-   |--------------------+--------------------+-----------------------|
-   | M_GOT file that is | File is in         | Finalize file         |
-   | not currently      | PendingFiles list  | Report file has been  |
-   | transmitting       |                    | sent                  |
-   |                    |                    | Remove file from the  |
-   |                    |                    | PendingFiles list     |
-   |                    |--------------------+-----------------------|
-   |                    | File is not in     | Ignore frame          |
-   |                    | PendingFiles       |                       |
-   |--------------------+--------------------+-----------------------|
-   | M_SKIP file that   | none               | Close file (do not    |
-   | is currently       |                    | finalize, we will     |
-   | transmitting       |                    | send it later, not in |
-   |                    |                    | current session)      |
-   |                    |                    | Report remote will    |
-   |                    |                    | accept this file      |
-   |                    |                    | later                 |
-   |                    |                    | Set TxState to TxGNF  |
-   |--------------------+--------------------+-----------------------|
-   | M_SKIP file that   | none               | Report remote will    |
-   | is not currently   |                    | accept this file      |
-   | transmitting       |                    | later                 |
-   |                    |                    | Remove file from      |
-   |                    |                    | PendingPiles, if      |
-   |                    |                    | exists there          |
-   +-----------------------------------------------------------------+
-
-  6.3 Session Termination
-  -----------------------
-
-   A session may be terminated in any of the following cases:
-
-          should be deemed aborted due to a fatal error.
-          should be deemed aborted due to non-fatal error typically
-       because of temporary lack of resources to proceed with the
-       session.
-             * all the files have been sent
-          * we have received M_EOB from the remote side (there are no
-            more files for us),
-          * we have received acknowledgements for all the files sent,
-          * we have received all the files re-requested by M_GET,
-       In this case, the session should be deemed successfully
-       completed.
-
-   A session termination itself is not a protocol stage. Mailer may
-   terminate a session at any time simply by issuing disconnect
-   (shutdown) command to the underlying transport layer, provided any
-   of the three conditions above are met. Mailer MUST take all proper
-   steps to provide a graceful shutdown of the transport layer, as it
-   is the transport layer that is responsible for all the data
-   transmitted by one side to be received by another before
-   disconnection, provided that shutdown of the transport layer
-   protocol was successful.
-
-7. Recommended Protocol Extensions
-----------------------------------
-
-   This section documents already implemented and proposed extensions
-   for the binkp/1.0. These extensions are purely optional and are
-   included here for the sake of compatibility with future
-   implementations.
-
-   Sides indicate supported protocol extensions by sending M_NUL
-   frame(s) with "OPT list_of_extensions" string, where
-   list_of_extensions is a space separated list of supported protocol
-   extensions. Whenever multiple M_NUL "OPT ..." frames are received
-   during the session, they SHOULD augment the current list of
-   extensions rather than replace it, unless specifically stated
-   otherwise for a particular option.
-
-   Mailer SHOULD NOT use any extension unless exactly sure that this
-   extension is supported by the remote. Mailer SHOULD use M_NUL "OPT
-   ..." to indicate supported options. Other methods for indicating
-   supported extensions are allowed as long as the provide full
-   backwards compatibility.
-
-  7.1 Non-reliable Mode
-  ---------------------
-
-   Non-reliable mode solves the problem with frequently aborted
-   connections when the sides can not successfully complete file
-   transfer before connection is broken. In this case, if the
-   transmitting side starts retransmission from offset 0, performance
-   degrades as by the time it receives M_GET from the remote, network
-   buffers are already full and by the time they are freed for
-   retransmission from requested offset, the connection might go down
-   again.
-
-   In order to circumvent this problem, a mailer can request the
-   remote to enter non-reliable mode by sending a M_NUL "OPT NR" frame
-   at any time during the session. After the remote acknowledges it by
-   sending an M_NUL "OPT NR" frame indicating that the option is
-   supported, both sides can assume that they are in non-reliable
-   mode.
-
-   When session is in non-reliable mode, the transmitting side may
-   send -1 for the offset value in M_FILE command. If it does so, it
-   should wait for the M_GET frame from the receiving side that
-   explicitly specifies file offset and start transmitting file data
-   from this offset. If the receiving side has indicated that it
-   supports non-reliable mode by sending M_NUL "OPT NR" frame, it must
-   recognize -1 as the file offset in M_FILE command as an explicit
-   request for the file offset and transmit an appropriate M_GET frame
-   as soon as possible.
-
-   It should be understood that this option degrades performance over
-   regular quality connections and it should be used only if
-   absolutely necessary.
-
-  7.2 Multiple Batch Mode
-  -----------------------
-
-   The session is in MB mode if both sides set "MB" flag in any of
-   M_NUL "OPT" packets exchanged before sending of M_OK/M_PWD packets.
-
-   In MB mode both sides restart session from RxDone into InitTransfer
-   state if there were any command packets sent or received by any
-   side between starting at InitTransfer and exchanging of M_EOB by
-   the sides (RxDone state). Otherwise, the session terminates as
-   usual.
-
-   Multiple batches mode is intended to handle WaZOO [FTS-0006] file
-   requests. If there were any WaZOO request files transferred in a
-   batch, sides MAY process them and send resulting files in the next
-   batch. Mailers MAY also generate list of files to send in
-   additional batches by other techniques -- including rescanning of
-   their spools or processing of other magic files transferred before
-   in the same session.
-
-  7.3 Multiple Passwords Mode
-  ---------------------------
-
-   Multiple password mode allows to specify different passwords for
-   the different addresses of the remote.
-
-   Originating side identifies it's multipassword capabilities by
-   sending M_NUL "OPT MPWD" during session setup stage before sending
-   any M_ADR commands and waits for response from the answering side.
-
-   If answering side responds with the M_NUL "OPT MPWD", then it
-   supports multiply passwords too. Answering side also always
-   responds with it's own address list: M_ADR "adr1 adr2 adr3 ...". If
-   M_NUL "OPT MPWD" was not received prior to the first M_ADR command,
-   originating side should assume that the remote does not support
-   multiple password mode and send a single password (if any) for one
-   of the addresses of the remote.
-
-   If the MPWD option was indicated by the answering side, originating
-   side now may send M_PWD "pwd1 pwd2 pwd3 ..." with the number of
-   entries in space separated password list equivalent to the number
-   of addresses presented by the answering side. If there is no
-   password for a particular address, it must send '-' character as a
-   placeholder.
-
-   If the passwords presented are consistent, answering side must
-   acknowledge successful authentication by sending M_OK command.
-
-  7.4 Keyed Hashing Challenge-Response Authentication Mechanism
-  -------------------------------------------------------------
-
-    7.4.1 Overview
-    --------------
-
-   Challenge-Response Authentication Mechanism (CRAM) allows to avoid
-   passing cleartext, reusable passwords across the network. Since it
-   utilizes Keyed-Hashing digests [Keyed], it does not require
-   password to be stored in the clear on the Mailer's media, allowing
-   storage of the intermediate results which are known as "contexts".
-
-   Providing binkp-mailer is capable of [Keyed] digest calculation and
-   conversion of a byte array to a hexadecimal string and back,
-   implementation of CRAM is easily achieved by slightly modifying the
-   state machine.
-
-    7.4.2 Sequence of Steps
-    -----------------------
-
-   CRAM adds an additional synchronization step to binkp protocol. The
-   description of this step follows:
-
-          the Originating side, encoded to a hexadecimal string.
-          hexadecimal string, and a password to produce a digest by
-       applying the keyed Hashing algorithm from [Keyed] where the key
-       is the password and the digested text is the challenge data.
-          digest provided. If the digest is correct, the answering side
-       should consider the Originating side authenticated and responds
-       appropriately.
-
-   Similar technique is used in [IMAP-AUTH].
-
-    7.4.3 Generating and Transmitting Challenge Data
-    ------------------------------------------------
-
-   Size and contents of challenge data are implementation-dependent,
-   but it SHOULD be no smaller than 8 bytes and no bigger than 64
-   bytes. Answering side SHOULD never generate the same challenge
-   data.
-
-   Instead of generating a long challenge data, answering side MAY use
-   a hash function to shorten it. In calculation of a challenge data
-   answering side MAY also use connection/line number, caller's IP
-   address, current time, etc.
-
-   Answering side transmits challenge data in the very first M_NUL
-   message, in the following way:
-
-   M_NUL "OPT [othropt] CRAM-lsthf-cde [othropt]"
-
-   lsthf is a list of aliases of supported hash functions, delimited
-   by slash characters. The list begins with alias of the most
-   preferred and ends with alias of the least preferred hash function.
-
-   Currently defined aliases are: MD5 for [MD5] and SHA1 for [SHA-1].
-
-   cde is the challenge data encoded to hexadecimal string, Lower-case
-   ASCII characters MUST be used for encoding, but Mailer SHOULD also
-   accept upper-case characters. The length of the string MUST be
-   even, and the leading zeros MUST NOT be trimmed.
-
-    7.4.4 Producing and Transmitting a Digest
-    -----------------------------------------
-
-   Originating side responds with:
-
-   M_PWD "CRAM-chosenhf-khde [othropt]"
-
-   where chosenhf is the alias of the chosen hash function and khde is
-   the keyed hashed digest, encoded to a hexadecimal string.
-
-   According to [IMAP-AUTH], keyed hashed digest is produced by
-   calculating
-
-   HASH((secret XOR opad), HASH((secret XOR ipad), challengedata))
-
-   where HASH is chosen hash function, ipad and opad are 36 hex and 5C
-   hex (as defined in [Keyed]) and secret is a password null-padded to
-   a length of 64 bytes. If the password is longer than 64 bytes, the
-   hash-function digest of the password is used as an input (16-byte
-   for [MD5] and 20-byte for [SHA-1]) to the keyed hashed calculation.
-
-    7.4.6 Indicating CRAM Capabilities
-    ----------------------------------
-
-   Answering side MUST send
-
-   M_NUL "OPT [othropt] CRAM-lsthf-cde [othropt]"
-
-   as a very first M_NUL message if it supports CRAM.
-
-   It MAY send other non-M_NUL messages before though. Current
-   specification doesn't define any such non-M_NUL message, they are
-   reserved for protocol extension.
-
-   Originating side MUST be ready to receive non-M_NUL before M_NUL in
-   a CRAM session. Binkp state machine MUST ignore any received
-   message of unknown type in order to be compatible with future
-   extensions.
-
-   If an originating side receives a first message that is a M_ADR or
-   a M_NUL message that is not
-
-   M_NUL "OPT [othropt] CRAM-lsthf-cde [othropt]"
-
-   it MUST decide that the answering side doesn't support CRAM and MAY
-   either disconnect or use old password exchange. If the sides have
-   no any compatible hash function, originator may also either
-   disconnect or use old password exchange. If an originating side
-   decides to disconnect, it SHOULD send M_ERR frame with a proper
-   explanation before disconnecting.
-
-   When parsing M_NUL "OPT ..." string (coming from the answering
-   side), originating side first splits it by using space delimiter to
-   get a list of options, and then if an option begins with
-   "CRAM-lsthf-", takes the remaining substring as a
-   hexadecimal-encoded challenge data.
-
-    7.4.7 Example of Frame Exchange During CRAM Authentication
-    ----------------------------------------------------------
-
-   (Password here is tanstaaftanstaaf)
-
-   Originating :
-     send M_NUL messages
-     and M_ADR
-     wait for first M_NUL message
-
-   Answering   :
-     send M_NUL "OPT ND CRAM-SHA1/MD5-f0315b074d728d483d6887d0182fc328"
-     and other messages
-     wait for M_PWD
-
-   Originating :
-     M_PWD "CRAM-MD5-56be002162a4a15ba7a9064f0c93fd00"
-
-   Answering   :
-     M_OK and continue session
-
-    7.4.8 Notes on Hash Function Algorithms
-    ---------------------------------------
-
-   [MD5] and [SHA-1] are the most widely used cryptographic hash
-   functions. [MD5] has been shown to be vulnerable to collision
-   search attacks [Dobb]. This attack and other currently known
-   weaknesses of [MD5] do not compromise the use of [MD5] within CRAM
-   as specified in this document (see [Dobb]); however, [SHA-1]
-   appears to be a cryptographically stronger function. To this date,
-   [MD5] can be considered for use in CRAM for applications where the
-   superior performance of [MD5] is critical. In any case,
-   implementors and users need to be aware of possible cryptanalytic
-   developments regarding any of these cryptographic hash functions,
-   and the eventual need to replace the underlying hash function.
-
-8. License
-----------
-
-   You can implement binkp protocol in your software as long as you
-   agree to the following conditions:
-
-          other way. You shall include the author(s) of the protocol in
-       your copyright statement for the software.
-          versions. Binkp allows development of the new capabilities
-       without compromising interoperability with previous versions.
-       Therefore, it is important that future developments of the
-       protocol are not pursued in different directions by different
-       people. If you have any suggestions regarding future
-       developments of the protocol, make a reasonable effort to
-       contact the author(s), so that the development efforts can
-       coordinated in a way advantageous for everybody.
-          future binkp specifications, you shall reference to it as a
-       "binkp variation" or "binkp derived".
-
-   Remember that you may use, implement or utilize binkp, it's
-   description or any other associated texts or documentations at your
-   own risk, without any warranty, without even the implied warranty
-   of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
-
-   Binkp author: Dima Maloff.
-
-9. Glossary
------------
-
-   Many entries in this glossary are provided courtesy of Butterfly
-   Glossary of Internet and Data Communication terms and RFC-1983.
-
-   connection-oriented
-           Data communication method in which communication proceeds
-           through three well-defined phases: connection
-           establishment, data transfer, connection release. TCP is a
-           connection-oriented protocol.
-
-   data link layer
-           The OSI layer that is responsible for data transfer across
-           a single physical connection, or series of bridged
-           connections, between two Network entities.
-
-   flow control
-           A technique for ensuring that a transmitting entity does
-           not overwhelm a receiving entity.
-
-   HDLC
-           (High level Data Link Control). Popular ISO standard
-           bit-oriented, data link layer protocol derived from SDLC.
-           HDLC specifies an encapsulated method of data on
-           synchronous serial data links.
-
-   IP
-           (Internet Protocol). The Internet Protocol, defined in STD
-           5, RFC 791, is the network layer for the TCP/IP Protocol
-           Suite. It is a connectionless, best-effort packet switching
-           protocol.
-
-   network layer
-           Layer 3 of the OSI reference model. Layer 3 is the layer at
-           which routing, addressing and connection management take
-           place.
-
-   OSI (Open Systems Interconnection) Reference Model
-           A seven-layer structure designed to describe computer
-           network architectures and the way that data passes through
-           them. This model was developed by the ISO (International
-           Organization for Standardization) in 1978 to clearly define
-           the interfaces in multivendor networks, and to provide
-           users of those networks with conceptual guidelines in the
-           construction of such networks.
-
-   port
-           A port is a transport layer demultiplexing value. Each
-           application has a unique port identifier associated with
-           it.
-
-   physical layer
-           The OSI layer that provides the means to activate and use
-           physical connections for bit transmission. In plain terms,
-           the Physical Layer provides the procedures for transferring
-           a single bit across a Physical Media.
-
-   Quality of Service
-           (Also QoS). A measure of performance for a transmission
-           system that reflects its transmission quality and
-           availability of service.
-
-   reliable transmission
-           a type of transport service that:
-              * recovers from errors by retransmitting errored frames
-              * delivers frames in correct sequence (also known as
-                stream-oriented)
-              * usually is used in connection-oriented mode
-
-   session layer
-           Layer 5 of the OSI reference model. Coordinates session
-           activity between applications, including application-layer
-           error control, dialog control, and remote procedure calls.
-
-   sliding window flow control
-           Method of flow control in which a receiver gives
-           transmitter permission to transmit data until a window is
-           full. When the window is full, the transmitter must stop
-           transmitting until the receiver advertises a larger window.
-
-   socket
-           Software structure operating as a communications and point
-           within a network device.
-
-   TCP
-           Transmission Control Protocol. An Internet Standard
-           transport layer reliable protocol defined in STD 7, RFC
-           793. It is connection-oriented and stream-oriented.
-
-   TCP/IP protocol suite
-           Transmission Control Protocol over Internet Protocol. This
-           is a common shorthand which refers to the suite of
-           transport and application protocols which runs over IP.
-
-   transport layer
-           Layer 4 of the OSI reference model. The transport layer is
-           responsible for reliable network communication between end
-           nodes. It implements flow and error control and often uses
-           virtual circuits to ensure reliable data delivery.
-
-   unixtime
-           number of seconds elapsed since 00:00:00 UTC, Jan. 1, 1970.
-
-10. References
---------------
-
-   [FTS-0001]
-           A Basic FidoNet(r) Technical Standard, Revision 16. Randy
-           Bush, Pacific Systems Group, September 30, 1995. FTS-0001.
-
-   [FTS-0006]
-           YOOHOO and YOOHOO/2U2. The netmail handshake used by
-           Opus-CBCS and other intelligent Fidonet mail handling
-           packages. Version 002, Vince Perriello. 30-Nov-1991.
-           FTS-0006.
-
-   [FSC-0039]
-           M.Howard, A type-2 packet extension proposal, FSC-0039
-           Version 4, 29-Sep-1990. FSC-0039.
-
-   [FSC-0045]
-           T.Henderson, Proposed new packet header, Version 1,
-           17-Apr-1990. FSC-0045.
-
-   [FSC-0048]
-           J.Vroonhof, Proposed type-2 packet extension, Version 2,
-           21-Oct-1990. FSC-0048.
-
-   [FSC-0081]
-           M.Staldal, A type-3 packet proposal, Version 1,
-           01-Mar-1995. FSC-0081.
-
-   [EMSI]
-           Joaquim H. Homrighausen, EMSI/IEMSI protocol definition.
-           May 3, 1991. FSC-0056.
-
-   [FTA-1006]
-           Key words to indicate requirement levels, Fidonet Technical
-           Standards Committee administrative. FTA-1006.
-
-   [Halsall95]
-           Data Communications, Computer Networks and Open Systems, F.
-           Halsall, 4th ed., Addison-Wesley, 1995, ISBN 0-201-42293-X.
-
-   [Dobb]
-           H. Dobbertin, "The Status of MD5 After a Recent Attack",
-           RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
-
-   [MD5]
-           Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-           April 1992.
-
-   [SHA-1]
-           NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
-
-   [Keyed]
-           Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
-           Message Authentication", RFC 2104, February 1997.
-
-   [IMAP-AUTH]
-           Klensin, "IMAP/POP AUTHorize Extension for Simple
-           Challenge/Response", RFC 2195, September, 1997
-
-   [RFC822]
-           Standard for the format of ARPA Internet text messages. D.
-           Crocker. Aug-13-1982. RFC 822, STD0011.
-
-   [UTF8]
-           UTF-8, a transformation format of ISO 10646. F. Yergeau.
-           January 1998, RFC 2279.
-
-   [ISO10646]
-           ISO/IEC 10646-1:1993. International Standard -- Information
-           technology -- Universal Multiple-Octet Coded Character Set
-           (UCS) -- Part 1: Architecture and Basic Multilingual Plane.
-           Five amendments and a technical corrigendum have been
-           published up to now. UTF-8 is described in Annex R,
-           published as Amendment 2.
-
-11. Acknowledgements
---------------------
-
-   This document is partially based on extracts from RFCs and FTSC
-   publications too numerous to be acknowledged individually.
-
-   The authors would like to thank Joaquim Homrighausen, Kim 'B'
-   Heino, Rune Johansen and many others for fruitful discussions and
-   suggestions regarding protocol design and specifications.
-
-A. Author Contact Data
------------------------
-
-   Dima Maloff
-   Fidonet: 2:5020/128
-   E-mail: maloff@corbina.net
-   WWW: http://www.corbina.net/~maloff/
-
-   Maxim Masiutin
-   Fidonet: 2:469/84
-   E-mail: max@ritlabs.com
-   WWW: http://www.ritlabs.com/
-
-   Nick Soveiko
-   Fidonet: 2:5030/23.101
-   E-mail: nsoveiko@doe.carleton.ca
-   WWW: http://www.doe.carleton.ca/~nsoveiko/
-
-B. History
-----------
-
-   Rev.1, 19990611:
-           First release
-
-   Rev.2, 19991008:
-              * Added new topic: "Definitions";
-              * clarified the following topics: "Frame Format",
-                "Protocol Commands and Their Arguments", "Keyed
-                Hashing Challenge-Response Authentication Mechanism";
-              * added "unixtime" item to Glossary topic;
-              * corrected links in References topic.
-
-   Rev.3, 20000731:
-              * Table 6 in section 6.2, File transfer stage has been
-                rewritten: TheListOfSendFiles replaced by PendingFiles
-                which was defined earlier. introduced definition of
-                KnownFiles list. new ProcessTheQueue routine w/respect
-                to handling M_GET command
-              * Section 5.2, File Name Issues was rewritten to clearly
-                define safe and unsafe characters in filenames.
-              * Section 5.3, Non-ASCII Characters was rewritten to
-                clarify Unicode usage.
-              * Expanded descriptions for M_NUL "TIME ...", M_NUL "TRF
-                ...", added description of M_NUL "PHN ..." and M_NUL
-                "OPM ..." frames in section 5.4 Binkp Commands.
-              * IANA port number added to section 3, Protocol
-                Overview.
-              * M_GET description in section 5.4, Binkp Commands was
-                rewritten for clarity.
-              * M_BSY "RETRY ..." option documented.
-              * Minor edits throughout the document to improve
-                readability.
-
-BackGo Back - - diff --git a/html/ftsc/fta-1005.html b/html/ftsc/fta-1005.html deleted file mode 100755 index 7d192b09..00000000 --- a/html/ftsc/fta-1005.html +++ /dev/null @@ -1,269 +0,0 @@ - - - -FTSC Product ID List. - - - - -
-**********************************************************************
-FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication:    FTA-1005
-Revision:       3
-Title:          FTSC Product Codes
-Author:         Administrator
-Revision Date:  22 March 1998
-Expiry Date:    22 March 1998
-----------------------------------------------------------------------
-Contents:
-                1. Format of product code list
-                2. Application for a product code
-----------------------------------------------------------------------
-
-
-1. Format of product code list
-------------------------------
-
-  The FTSC publishes a list of all product codes issued. The filename
-  is FTSCPROD.nnn, where nnn is a number which increases with each
-  revision.
-
-  The list is an ASCII text file with one line per product. Each line
-  contains a number of fields, delimited by commas. Some fields may
-  contain more than one value. In this case, the different values are
-  delimited with a forward slash ('/'). Spaces in fields are replaced
-  with underscores ('_'). Fields are not case-sensitive.
-
-  These are the fields which are currently defined:
-
-    code,name,platform,type,contact,netaddr[,assigned[,updated]]
-
-  code      The product code. 4 digits hexadecimal.
-  name      Product name.
-  platform  Platforms(s) supported.
-  type      Type(s) of product.
-  contact   Name of contact person.
-  netaddr   FidoNet address of contact person.
-  assigned  Date the product code was originally assigned.
-  updated   Date of last update of the product code data.
-
-  Platforms
-  ---------
-  See the list for examples. (Will be specified more firmly later).
-
-  Product types
-  -------------
-  Mailer    A mailer is a product that exchanges mail with FTS-0001,
-            FTS-0006, EMSI or other protocols that include a product
-            code field.
-  Packer    A packer is a product that creates .PKT files.
-
-  Dates
-  -----
-  The format is YYYYMMDD. A date field may also be blank.
-
-  If you write software which is dependant on this format, please make
-  it tolerant of additional fields after these for upwards
-  compatibility.
-
-
-2. Application for a product code
----------------------------------
-
-  FidoNet products without an allocated product code which either
-  create Type-2 packets, or negotiate FTS-0001 sessions must use a
-  product code FEh (254d) in Type-2 compatible packet headers. This
-  code as been reserved for that purpose (use by product without a
-  product code). The product code FFh (255d) has been reserved to
-  indicate that the product code is stored elsewhere in the packet
-  header at an as yet unallocated offset.
-
-  The FTSC is currently working on an update to the Type-2 packet
-  specification, to allow 16-bit codes while keeping full backward
-  compatibility with 8-bit codes (something which the current Type-2
-  proposals in the FSC's are not). Until the specification is ready,
-  16-bit codes are issued with the low byte set to FFh (255d).
-
-  Below is an application form for an FTSC product code, which is used
-  to identify your product when used in FidoNet, and providing a means
-  by which you can be contacted should your product be found
-  responsible for problems encountered during its use. The issuance of
-  this product code in no way implies authorisation or approval of
-  your product for use on the network, only provides a means of ready
-  identification.
-
-  This application should be completed and submitted for only `real'
-  and completed products which will be used by FidoNet systems. If you
-  are currently developing a product which is not yet ready for use on
-  the network out of experimental stage, use product code 0 (zero)
-  which is, by convention, reserved for this purpose.
-
-  Please answer the questions as accurately and completely as
-  possible. We need to know what will actually be used on the net, so
-  describe only the current product, and leave future features and
-  plans for the comments section.
-
-  Send the completed form to the administrator of the FidoNet
-  Technical Standards Committee. Please see FTA-1003 for addresses.
-
-  We hope that you will take the time to revise your answers by
-  submitting updates as your product changes. A summary of the
-  information you provide is compiled into a list of all product codes
-  published and updated periodically by the FTSC called
-  "FTSCPROD.nnn".
-
-
-A. Application Form
--------------------
-
---- Cut along here ---------------------------------------------------
-
-FTSC Product Code Application
-=============================
-
-Type of application
--------------------
-
-1.  Mark whichever is appropriate:
-
-    ____  New product application
-    ____  Update existing product       for existing product code ____
-
-
-2.  If this is an update, please briefly state the nature of the
-    update (change author's node number, change of product name, etc.)
-
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-
-
-Product information
--------------------
-
-3.  What is the name of the product and the current version name or
-    number?
-
-    __________________________________________________________________
-
-
-4.  What is the name, FidoNet node, and postal address, and voice
-    number of the person(s) or organization responsible for the
-    product?  Where should inquiries be directed and who should be
-    contacted if the product is thought to cause errors on the
-    network?
-
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-
-
-5.  What operating systems does it currently run on?
-
-    __________________________________________________________________
-
-
-6.  Does the product contain a 'mailer'?  E.g. the package transmits
-    mail to other FidoNet systems and can fall back to FTS-0001,
-    though it may handle other protocols.
-
-    __________________________________________________________________
-
-
-7.  If the answer to question (6) is yes, what additional protocols
-    other than FTS-0001 does the product support? Refer to the
-    specific FTSC document which details this protocol, if any.
-
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-
-
-    With what additions or restrictions?
-
-    __________________________________________________________________
-
-
-8.  Is the package capable of servicing file requests, and if so,
-    'Bark' style (FTS-0008) and/or WaZOO .REQ (FTS-0006) or both?
-
-    __________________________________________________________________
-
-
-    With what additions or restrictions?
-
-    __________________________________________________________________
-
-
-9.  Is your software capable of functioning as a Continuous Mail
-    system? i.e. nodes running it might be marked as such in the
-    FidoNet nodelist?
-
-    __________________________________________________________________
-
-
-10. How is the product distributed?
-
-    Public Domain  ____________          Shareware      ______________
-    Commercial     ____________          Other          ______________
-    Object code    ____________          Source code    ______________
-
-    Comments: ________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-
-
-11. Please give additional comments to describe your product.
-
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-    __________________________________________________________________
-
---- Cut along here ---------------------------------------------------
-
-
-B. Acknowledgements
--------------------
-
-  The application form was inspired by one originally published in
-  FSC-0022 and later FSC-0090, originally by Bob Hartman, Jim Long,
-  and Randy Bush and modified by Rick Moore and David Nugent.
-
-
-C. History
-----------
-
-  Rev.1, 19970407: First non-draft release. Author Adrian Walker.
-  Rev.2, 19971229: Author changed to Administrator. Reformatted
-                   document slightly. Changed all dates in the lists
-                   to 4 digit centuries. Added information about
-                   status of 16-bit product codes.
-  Rev.3, 19980322: Moved the product code list out of the document and
-                   into a separate list, FTSCPROD.nnn. Added an
-                   application form. Revised text about 16 bit codes.
-
-
-**********************************************************************
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-0001.html b/html/ftsc/fts-0001.html deleted file mode 100755 index 90177d76..00000000 --- a/html/ftsc/fts-0001.html +++ /dev/null @@ -1,1261 +0,0 @@ - - - -A Basic FidoNet(r) Technical Standard. - - - - -
-Document: FTS-0001
-Version:  016
-Date:     30-Sep-95
-
-
-
-
-                     A Basic FidoNet(r) Technical Standard
-|                                Revision 16
-                      Formerly known as FSC001,  FSC-0001
-|                      Randy Bush, Pacific Systems Group
-|                             September 30, 1995
-
-
-
-
-Status of this document:
-
-    This FTS  (FidoNet(r)  Technical  Standard)  specifies  a  standard  for
-    the FidoNet community. FidoNet nodes are expected to adopt and implement
-    this standard. Distribution is subject to the restrictions stated in the
-    copyright paragraph below.
-
-    Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
-
-    Copyright  1986-95,  Randy  Bush.  All  rights  reserved.   A  right  to
-    distribute only  without modification  and only at no charge is granted.
-    Under no  circumstances is this document to be reproduced or distributed
-    as  part of  or packaged with any product or other sales transaction for
-    which any fee is charged.  Any and all other reproduction  or excerpting
-    requires the explicit written consent of the author.
-
-
- A. Introduction
-
-    FidoNet  has  grown  beyond  most  peoples' fantasies, and  new  FidoNet
-    implementations  are appearing regularly.  Unfortunately, the  scattered
-    nature of the documentation and absence of clear testing procedures have
-    made  implementation  difficult.   FidoNet, in its desire to promote and
-    encourage  FidoNet  implementations,  suggested  a  project  to create a
-    technical  standard for  FidoNet.  The author did not  design or specify
-    the data formats or protocols, only attempted to document them.
-
-    This  document defines the  data structures and communication  protocols
-    which a FidoNet implementation must provide.  The implementor of FidoNet
-    compatible systems is the intended audience of this document.
-
-    The  layered metaphor of the ISO Open Systems Interface reference  model
-    has been used to view FidoNet from a standard perspective.  As with most
-    prospective  ISO/OSI  descriptions, FidoNet  does not always  make  this
-    easy.
-
-    The  content of this document  was gleaned from the references given  at
-    the  end.
-
-    Please direct technical comments and errata to
-|     Randy Bush                       randy@psg.com
-|     Pacific Systems Group
-      9501 S.W. Westhaven Drive
-      Portland, Oregon  US-97225
-|
-
-   1. Basic Requirements for a FidoNet Implementation
-
-      Compatibility is a set of abilities which, when taken as a whole, make
-      it safe to list a net or node in the FidoNet nodelist. In other words,
-      if  another  node should attempt  contact, does it have  a  reasonable
-      chance  of successful communication?  This is a social obligation,  as
-      the  calling  system  pays  money  for the  attempt.   Conversely,  an
-      implementation  should be able to successfully contact other  systems,
-      as life is not a one-way street.
-
-      A FidoNet implementation must be able to call other nodes and transfer
-      messages and files in both directions.  This includes pickup and poll.
-      A FidoNet implementation must be able to accept calls from other nodes
-      and  transfer  messages and  files in both directions.  This  includes
-      pickup.
-
-      FidoNet implementations must be able to receive and process the FidoNet
-      format  nodelist, and transfer nodelists to other nodes.  A  companion
-      document,  FTS-0005, defines the FidoNet format nodelist  and  how  to
-      interpret and process it.
-
-      A  FidoNet implementation must route messages which do not have  files
-      attached through net hosts as shown in a FidoNet format nodelist.
-
-
-   2. Levels of Compliance
-
-      This  documents represents the  most basic FidoNet implementation.   A
-      future  document will define well tested extensions which are optional
-      but  provide sufficient  additional function that implementors  should
-      seriously   consider   them.   SEAdog(tm),  from  System   Enhancement
-      Associates,  is  an  excellent  example  of such an  extended  FidoNet
-      implementation.
-
-
-   3. The ISO/OSI Reference Model (cribbed from "Protocol Verification via
-      Executable Logic Specifications", D. P. Sidhu, in Rudin & West)
-
-      In  the ISO/OSI model, a distributed system consists of entities  that
-      communicate  with  each other  according  to a set of rules  called  a
-      protocol.   The  model is  layered, and there are entities  associated
-      with  each layer of the model which provide services to higher  layers
-      by  exchanging information with their peer entities using the services
-      of  lower layers.  The only actual physical communication between  two
-      systems is at the lowest level.
-
-      Several  techniques  have  been  used  in the  specification  of  such
-      protocols.  A common ingredient in all techniques is the notion of the
-      extended  finite  state automata  or machine.  Extensions include  the
-      addition of state variables for the storing of state information about
-      the  protocol.  The state of an  automation can change as a result  of
-      one of the following events:
-
-      o Request from an upper network layer for service
-
-      o Response to the upper layer
-
-      o Request to the lower network layer to perform a service
-
-      o Response from the lower layer
-
-      o Interaction with the system and environment in which the protocol is
-        implemented (e.g. timeouts, host operating system aborts, ...)
-
-      A  protocol  specification, in  a large part, consists  of  specifying
-      state  changes  in  automata  which  model protocol  entities  and  in
-      describing the data which they exchange.
-
-      For  historical  reasons,  the  term  packet  is used  in  FidoNet  to
-      represent a bundle of messages, as opposed to the more common use as a
-      unit of communication, which is known as a block in FidoNet.
-
-
-   4. Data Description
-
-      A  language  specific  notation  was avoided.  Please help  stamp  out
-      environmental  dependencies.   Only  you  can  prevent  PClone  market
-      dominance.  Don't panic, there are rectangular record layouts too.
-
-      (* non-terminals *)
-      UpperCaseName - to be defined further on
-
-      (* literals *)
-      "ABC"         - ASCII character string, no termination implied
-      nnH           - byte in hexadecimal
-
-      (* terminals *)
-      someName      - 16-bit integer, low order byte first (8080 style)
-      someName[n]   - field of n bytes
-      someName[.n]  - field of n bits
-      someName(n)   - Null terminated string allocated n chars (incl Null)
-      someName{max} - Null terminated string of up to max chars (incl Null)
-
-      (* punctuation *)
-      a b           - one 'a' followed by one 'b'
-      ( a | b )     - either 'a' or 'b', but not both
-      { a }         - zero or more 'a's
-      [ b ]         - zero or one 'b'
-      (* comment *) - ignored
-
-      (* predeclared constant *)
-      Null          = 00H
-
-
-
- 5. Finite State Machine Notation
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         |  St |
-    |-----+----------+-------------------------+-------------------------+-----|
-    | fnn*|          |                         |                         |     |
-    `-----+----------+-------------------------+-------------------------+-----'
-
-    State #      - Number of this state (e.g. R13).
-                   f  - FSM initial (Window, Sender, Receiver, ...)
-                   nn - state number
-                   *  - state which represents a lower level protocol  which
-                        is represented by yet another automation.
-
-    State Name   - Descriptive name of this state.
-
-    Predicate(s) - Conditions which terminate the state.  If predicates are
-                   non-exclusive, consider them ordered.
-
-    Action(s)    - Action(s) corresponding to predicate(s)
-
-    Next State   - Subsequent state corresponding to predicate(s)
-
-    Ideally,  there  should be  a  supporting section for each  state  which
-    should  give a prose description of the state, its predicates,  actions,
-    etc.  So much for ideals.
-
-
- B. Application Layer : the System from the User's View
-
-    The application layer is outside the domain of a FidoNet standard, as it
-    is the layer that the user's application sees as opposed to what FidoNet
-    sees.   In  recent  months,  there  has been  sufficient  confusion  and
-    discussion  about  the  format  of  data at this level  to  warrant  the
-    description  of the data structure, the message as it is stored by Fido,
-    SEAdog, and Rover.
-
-    Perfectly valid FidoNet systems may be implemented whose stored messages
-    differ greatly from this format.
-
-
-   1. Application Layer Data Definition : a Stored Message
-
-                               Stored Message
-
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |                                               |
-              ~                 fromUserName                  ~
-              |                   36 bytes                    |
-              +-----------------------+-----------------------+
-       36  24 |                                               |
-              ~                  toUserName                   ~
-              |                   36 bytes                    |
-              +-----------------------+-----------------------+
-       72  48 |                                               |
-              ~                    subject                    ~
-              |                   72  bytes                   |
-              +-----------------------+-----------------------+
-      144  90 |                                               |
-              ~                    DateTime                   ~
-              |                    20 bytes                   |
-              +-----------------------+-----------------------+
-      164  A4 | timesRead (low order) | timesRead (high order)|
-              +-----------------------+-----------------------+
-      166  A6 | destNode (low order)  | destNode (high order) |
-              +-----------------------+-----------------------+
-      168  A8 | origNode (low order)  | origNode (high order) |
-              +-----------------------+-----------------------+
-      170  AA |   cost (low order)    |   cost (high order)   |
-              +-----------------------+-----------------------+
-      172  AC | origNet (low order)   | origNet (high order)  |
-              +-----------------------+-----------------------+
-      174  AE | destNet (low order)   | destNet (high order)  |
-              +-----------------------+-----------------------+
-      176  B0 | destZone (optional)   | destZone (optional)   |
-              +-----------------------+-----------------------+
-      178  B2 | origZone (optional)   | origZone (optional)   |
-              +-----------------------+-----------------------+
-      180  B4 | destPoint(optional)   | destPoint(optional)   |
-              +-----------------------+-----------------------+
-      182  B6 | origPoint(optional)   | origPoint(optional)   |
-              +-----------------------+-----------------------+
-      184  B8 |  replyTo (low order)  |  replyTo (high order) |
-              +-----------------------+-----------------------+
-      186  BA | Attribute (low order) | Attribute (high order)|
-              +-----------------------+-----------------------+
-      188  BC | nextReply (low order) | nextReply (high order)|
-              +-----------------------+-----------------------+
-      190  BE |                      text                     |
-              ~                    unbounded                  ~
-              |                 null terminated               |
-              `-----------------------------------------------'
-
-      Message    = fromUserName(36)  (* Null terminated *)
-                   toUserName(36)    (* Null terminated *)
-                   subject(72)       (* see FileList below *)
-                   DateTime          (* message body was last edited *)
-                   timesRead         (* number of times msg has been read *)
-                   destNode          (* of message *)
-                   origNode          (* of message *)
-                   cost              (* in lowest unit of originator's
-                                        currency *)
-                   origNet           (* of message *)
-                   destNet           (* of message *)
-                   destZone          (* of message *)
-                   origZone          (* of message *)
-                   destPoint         (* of message *)
-                   origPoint         (* of message *)
-                   replyTo           (* msg to which this replies *)
-                   AttributeWord
-                   nextReply         (* msg which replies to this *)
-                   text(unbounded)   (* Null terminated *)
-
-      DateTime   = (* a character string 20 characters long *)
-                                     (* 01 Jan 86  02:34:56 *)
-                   DayOfMonth " " Month " " Year " "
-                   " " HH ":" MM ":" SS
-                   Null
-
-      DayOfMonth = "01" | "02" | "03" | ... | "31"   (* Fido 0 fills *)
-      Month      = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
-                   "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
-      Year       = "01" | "02" | .. | "85" | "86" | ... | "99" | "00"
-      HH         = "00" | .. | "23"
-      MM         = "00" | .. | "59"
-      SS         = "00" | .. | "59"
-
-      AttributeWord   bit       meaning
-                      ---       --------------------
-                        0  +    Private
-                        1  + s  Crash
-                        2       Recd
-                        3       Sent
-                        4  +    FileAttached
-                        5       InTransit
-                        6       Orphan
-                        7       KillSent
-                        8       Local
-                        9    s  HoldForPickup
-                       10  +    unused
-                       11    s  FileRequest
-                       12  + s  ReturnReceiptRequest
-                       13  + s  IsReturnReceipt
-                       14  + s  AuditRequest
-                       15    s  FileUpdateReq
-
-                             s - need not be recognized, but it's ok
-                             + - not zeroed before packeting
-
-      Bits numbers ascend with arithmetic significance of bit position.
-
-
-      Message Text
-
-      Message text is unbounded and null terminated (note exception below).
-
-      A 'hard' carriage return, 0DH,  marks the end of a paragraph, and must
-      be preserved.
-
-      So   called  'soft'  carriage  returns,  8DH,  may  mark  a   previous
-      processor's  automatic line wrap, and should be ignored.  Beware  that
-      they may be followed by linefeeds, or may not.
-
-      All  linefeeds, 0AH, should be ignored.  Systems which display message
-      text should wrap long lines to suit their application.
-
-      If the first character of a physical line (e.g. the first character of
-      the  message text, or the character immediately after a hard  carriage
-      return (ignoring any linefeeds)) is a ^A (<control-A>, 01H), then that
-      line  is  not  displayed  as  it  contains  control  information.  The
-      convention for such control lines is:
-        o They begin with ^A
-        o They end at the end of the physical line (i.e. ignore soft <cr>s).
-        o They begin with a keyword followed by a colon.
-        o The keywords are uniquely assigned to applications.
-        o They keyword/colon pair is followed by application specific data.
-
-      Current ^A keyword assignments are:
-|     o TOPT <pt no> - destination point address
-      o FMPT <pt no> - origin point address
-      o INTL <dest z:n/n> <orig z:n/n> - used for inter-zone address
-
-
-      File Specifications
-
-      If  one  or more  of FileAttached, FileRequest, or  FileUpdateReq  are
-      asserted  in an AttributeWord, the subject{72} field is interpreted as
-      a  list of file specifications  which may include wildcards and  other
-      system-dependent data.  This list is of the form
-
-      FileList = [ FileSpec { Sep FileSpec } ] Null
-
-      FileSpec = (* implementation dependent file specification.  may
-                    not contain Null or any of the characters in Sep. *)
-
-      Sep      = ( " " | "," )  { " " }
-
-
-      There are deviations from and additions to these specifications
-
-      1  - Fido does not necessarily terminate the message text with a Null,
-           but  uses  an empty line (0DH 0AH 0DH 0AH).  Some  Fido utilities
-           use an EOF (1AH).
-
-      2 - SEAdog zeros the message cost field when building a message.
-
-      4 - SEAdog uses a different format for dates, e.g.
-
-      DateTime   = (* a character string 20 characters long *)
-                   (* SEAdog format Mon  1 Jan 86 02:34 *)
-                   DayOfWk " " DayOfMo " " Month " " Year " " HH ":" MM Null
-
-      DayOfWk    = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"
-      DayOfMo    = " 1" | " 2" | " 3" | ... | "31"  (* blank fill *)
-
-
-
-   2. Application Layer Protocol : Schedules and Events
-
-      At  the application level, FidoNet imposes few protocol  requirements.
-      An   implementation   must   automatically   originate   and   receive
-      node-to-node  FidoNet  connections.   Some implementations do this  in
-      'windows'  or  time  slots.   Routing  of  messages  will  usually  be
-      different and customizable for each scheduled window.
-
-      The ability to send to and receive from any FidoNet listed node during
-      the Zone Mail Hour (eg. 9:00-10:00 UCT in Z1) is considered mandatory.
-
-      Current  implementations assemble all data for outbound connections at
-      the  start of a window, and  disassemble inbound data at the end of  a
-      window.   Due to performance considerations on small machines, this is
-      considered  a valid optimization.   Observe that it somewhat  inhibits
-      dynamic routing.
-
-
- C. Presentation Layer : the User from the System's View
-
-   1. Presentation Layer Data Definition : the Packed Message
-
-      To  conserve space and eliminate fields which would be meaningless  if
-      sent  (e.g. timesRead), messages are packed for transmission.  As this
-      is  a data structure which is actually transferred, its definition  is
-      critical  to FidoNet.  A packed  message has a number of fixed  length
-      fields followed by four null terminated strings.
-
-      While  most of the string fields in a stored message are fixed length,
-      to  conserve space strings are variable length when in a packet.   All
-      variable  length strings are all Null terminated, including especially
-      the message text.
-
-
-                                Packed Message
-
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |    0     |     2      |    0      |    0      |
-              +-----------------------+-----------------------+
-        2   2 | origNode (low order)  | origNode (high order) |
-              +-----------------------+-----------------------+
-        4   4 | destNode (low order)  | destNode (high order) |
-              +-----------------------+-----------------------+
-        6   6 | origNet (low order)   | origNet (high order)  |
-              +-----------------------+-----------------------+
-        8   8 | destNet (low order)   | destNet (high order)  |
-              +-----------------------+-----------------------+
-       10   A | Attribute (low order) | Attribute (high order)|
-              +-----------------------+-----------------------+
-       12   C |   cost (low order)    |   cost (high order)   |
-              +-----------------------+-----------------------+
-       14   E |                                               |
-              ~                    DateTime                   ~
-              |                    20 bytes                   |
-              +-----------------------+-----------------------+
-       34  22 |                  toUserName                   |
-              ~                  max 36 bytes                 ~
-              |                null terminated                |
-              +-----------------------+-----------------------+
-              |                 fromUserName                  |
-              ~                  max 36 bytes                 ~
-              |                null terminated                |
-              +-----------------------+-----------------------+
-              |                    subject                    |
-              ~                  max 72 bytes                 ~
-              |                null terminated                |
-              +-----------------------+-----------------------+
-              |                      text                     |
-              ~                    unbounded                  ~
-              |                 null terminated               |
-              `-----------------------------------------------'
-
-      Due  to routing, the origin and  destination net and node of a  packet
-      are  often quite different from  those of the messages within it,  nor
-      need  the origin and destination nets and nodes of the messages within
-      a packet be homogenous.
-
-      PakdMessage  = 02H 00H           (* message type, old type-1 obsolete *)
-                     origNode          (* of message *)
-                     destNode          (* of message *)
-                     origNet           (* of message *)
-                     destNet           (* of message *)
-                     AttributeWord
-                     cost              (* in lowest unit of originator's
-                                          currency *)
-                     DateTime          (* message body was last edited *)
-                     toUserName{36}    (* Null terminated *)
-                     fromUserName{36}  (* Null terminated *)
-                     subject{72}       (* Null terminated *)
-                     text{unbounded}   (* Null terminated *)
-
-
-
-
-
-
-
- 2. Presentation Layer Protocol : a Mail Window
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         | St  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | W0  | WindTop  | 1 end of window reached | reset modem to not answr| exit|
-   |     |          | 2 time remains in window| ensure modem can answer | W1  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | W1  | WindIdle | 1 incoming call         |                         | W2  |
-   |     |          | 2 receive-only mode     |                         | W0  |
-   |     |          | 3 send-only mode        |                         | W3  |
-   |     |          | 4 60-180 secs & no call |                         | W3  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | W2* | WindRecv |                         | (receive call R0)       | W3  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | W3  | WindCall | 1 select outgoing call  | increment try count     | W4  |
-   |     |          | 2 no outgoing calls     |                         | W0  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | W4* | WindSend |                         | (make call S0)          | W5  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | W5  | WindMark | 1 call successful       | remove node fr call list| W0  |
-   |     |          | 2 no connect            | remove if try cnt > lim | W0  |
-   |     |          | 3 call failed           | incr conn cnt, remove   | W0  |
-   |     |          |                         |   if con cnt > lim      |     |
-   `-----+----------+-------------------------+-------------------------+-----'
-
-
-    The  length of the inter-call delay time at W1.4 is not critical.  It is
-    important that this not be a constant, so two systems calling each other
-    do  not incur infinite busy signals.  Sophisticated implementations  may
-    vary  the  inter-call delay  depending  on number of calls to  be  made,
-    window width, user specification, etc.
-
-
- D. Session Layer Protocol : Connecting to Another FidoNet Machine
-
-    A session is a connection between two FidoNet machines.  It is currently
-    assumed  to be over the  DDD telephone network via modems.  The  calling
-    machine starts out as the sender and the called machine as the receiver.
-    The  pickup  feature is described  by the sender and  receiver  changing
-    roles  midway through the session, after the sender has transferred  the
-    message  packet and any attached files.  Due to the lack of security  in
-    the  pickup protocol (danger of pickup by a fake node), a change in  the
-    protocol may be expected in the near future.
-
-    Once  a connection has been established, each system should ensure  that
-    the  physical connection remains  throughout the session.  For  physical
-    layers  implemented  through modems,  this means monitoring the  carrier
-    detect signal, and terminating the session if it is lost.
-
-    Error  detection at the physical layer should be monitored for both sent
-    and  received  characters.  Parity,  framing, and other physical  errors
-    should be detected.
-
-    Sender
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         | St  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S0  | SendInit |                         | dial modem              | S1  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S1  | WaitCxD  | 1 carrier detected      | delay 1-5 seconds       | S2  |
-   |     |          | 2 busy, etc.            | report no connection    | exit|
-   |     |          | 3 voice                 | report no carrier       | exit|
-   |     |          | 4 carrier not detected  | report no connection    | exit|
-   |     |          |   within 60 seconds     |                         |     |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S2  | WhackCRs | 1 over 30 seconds       | report no response  | exit|
-   |     |          | 2 ?? s received     | delay 1 sec             | S3  |
-   |     |          | 3 s not received    | send    | S2  |
-   |     |          |                         |   delay ??? secs        |     |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S3  | WaitClear| 1 no input for 0.5 secs | send TSYNCH = AEH       | S4  |
-   |     |          | 2 over 60 seconds       | hang up, report garbage | exit|
-   |     |          |   and line not clear    |                         |     |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S4* | TSyncChk | 1 'C' or NAK (peeked at)| (XMODEM send packet XS1)| S5  |
-   |     |          | 2 over 2 seconds        | eat noise, resend TSYNCH| S4  |
-   |     |          | 3 over 30 seconds       | hang up report not Fido | exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S5  | CheckMail| 1 XMODEM successful     | (Fido registers success)| S6  |
-   |     |          | 2 XMODEM fail or timeout| hang up, report mail bad| exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S6* | SendFiles|                         | (BATCH send files BS0)  | S7  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S7  | CheckFile| 1 BATCH send successful |                         | S8  |
-   |     |          | 2 BATCH send failed     | hang up, rept files fail| exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | S8  | TryPickup| 1 wish to pickup        | note send ok            | R2* |
-   |     |          | 2 no desire to pickup   | delay 5 secs            | exit|
-   |     |          |                         |   hang up, rept send ok |     |
-   `-----+----------+-------------------------+-------------------------+-----'
-
-    Although  the  above  shows  the  sender  emitting only one  TSYNCH,  it is
-    recommended  that a timeout of 5-20 seconds should initiate another TSYNCH.
-    The receiver should tolerate multiple TSYNCHs.
-
-    In state S4, the phrase "peeked at" means that the character is not removed
-    from the buffer.  Therefore when XS1 is started the proper character for
-    beginning the Xmodem transfer will be detected.
-
-   Receiver
-
-    The  receiving FSM is given  an external timer, the expiration of  which
-    will cause termination with a result of 'no calls' (R0.2).
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         | St  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | R0  | WaitCxD  | 1 carrier detected      |                         | R1  |
-   |     |          | 2 external timer expires| report no calls         | exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | R1  | WaitBaud | 1 baud rate detected    | send signon with s  | R2  |
-   |     |          | 2 no detect in ?? secs  | hang up, report no baud | exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | R2  | WaitTsync| 1 TSYNCH received       | ignore input not TSYNCH | R3  |
-   |     |          | 2 60 seconds timeout    | hang up, report not Fido| exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | R3* | RecMail  |                         | (XMODEM rec packet XR0) | R4  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | R4  | XRecEnd  | 1 XMODEM successful     | delay 1 second          | R5  |
-   |     |          |                         |   flush input           |     |
-   |     |          | 2 XMODEM failed         | hang up, rept mail fail | exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | R5* | RecFiles |                         | (BATCH rec files BR0)   | R6  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | R6  | ChkFiles | 1 BATCH recv successful | delay 2 secs            | R7  |
-   |     |          | 2 BATCH recv failed     | hang up, report bad file| exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | R7  | AllowPkup| 1 have pickup for sender| receiver becomes sender | S3* |
-   |     |          | 2 nothing to pickup     | hang up, rept recv ok   | exit|
-   `-----+----------+-------------------------+-------------------------+-----'
-
-
- E. Transport Layer : ?????
-
-   1. Data Definitions
-
-   2. Transport Layer Protocol : Routing
-
-      FidoNet   does  not  necessarily  send  a  message  directly  to   its
-      destination.   To reduce the number of network connections, mail to  a
-      subset  of  the  nodelist  may  be  routed  to one  node  for  further
-      distribution  within  that  subset.   In addition, custom  routing  is
-      possible.  Routing of a message is determined in one of three ways.
-
-      o If there are files attached, then a message must be sent directly to
-        its destination.
-
-      o Messages without attached files should be routed through the inbound
-        host  of the destination  node's  subnet  as specified  by a FidoNet
-        format nodelist.
-
-      o To prevent overloading of inbound hosts, a system should provide for
-        host routing to be disabled for a target node, or nodes.
-
-
- F. Network Layer : the Network's View of the System, Routing and Packets
-
-
-   1. Network Layer Data Definition : the Packet Header
-
-      The  packet contains messages in packed format to be transferred  over
-      the  net during a connection.  As this data structure is  transferred,
-      its definition is critical to FidoNet.
-
-      A  packet may contain zero or more packed messages.  A packet  without
-      messages is often generated as a poll packet.
-
-      Every  packet begins with a  packet header.  The fields of the  packet
-      header are of fixed length.
-
-
-                                Packet Header
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 | origNode (low order)  | origNode (high order) |
-              +-----------------------+-----------------------+
-        2   2 | destNode (low order)  | destNode (high order) |
-              +-----------------------+-----------------------+
-        4   4 |   year (low order)    |   year (high order)   |
-              +-----------------------+-----------------------+
-        6   6 |  month (low order)    |  month (high order)   |
-              +-----------------------+-----------------------+
-        8   8 |   day (low order)     |   day (high order)    |
-              +-----------------------+-----------------------+
-       10   A |   hour (low order)    |   hour (high order)   |
-              +-----------------------+-----------------------+
-       12   C |  minute (low order)   |  minute (high order)  |
-              +-----------------------+-----------------------+
-       14   E |  second (low order)   |  second (high order)  |
-              +-----------------------+-----------------------+
-       16  10 |   baud (low order)    |   baud (high order)   |
-              +-----------------------+-----------------------+
-       18  12 |    0     |     2      |    0      |    0      |
-              +-----------------------+-----------------------+
-       20  14 | origNet (low order)   | origNet (high order)  |
-              +-----------------------+-----------------------+
-       22  16 | destNet (low order)   | destNet (high order)  |
-              +-----------------------+-----------------------+
-       24  18 |       prodCode        |       serialNo        |
-              +-----------------------+-----------------------+
-       26  1A |                                               |
-              |             password   (some impls)           |
-              |                  eight bytes                  |
-              |                  null padded                  |
-              |                                               |
-              +-----------------------+-----------------------+
-       34  22 | origZone (low) (opt)  | origZone (high) (opt) |
-              +-----------------------+-----------------------+
-       36  24 | destZone (low) (opt)  | destZone (high) (opt) |
-              +-----------------------+-----------------------+
-       38  26 |                     fill                      |
-              ~                   20 bytes                    ~
-              |                                               |
-              +-----------------------+-----------------------+
-       58  3A |                 zero or more                  |
-              ~                    packed                     ~
-              |                   messages                    |
-              +-----------------------+-----------------------+
-              |    0     |     0      |    0     |     0      |
-              `-----------------------+-----------------------'
-
-
-      Packet       = PacketHeader  { PakdMessage }  00H 00H
-
-      PacketHeader = origNode   (* of packet, not of messages in packet *)
-                     destNode   (* of packet, not of messages in packet *)
-                     year       (* of packet creation, e.g. 1986 *)
-                     month      (* of packet creation, 0-11 for Jan-Dec *)
-                     day        (* of packet creation, 1-31 *)
-                     hour       (* of packet creation, 0-23 *)
-                     minute     (* of packet creation, 0-59 *)
-                     second     (* of packet creation, 0-59 *)
-                     baud       (* max baud rate of orig and dest, 0=SEA *)
-                     PacketType (* old type-1 packets now obsolete *)
-                     origNet    (* of packet, not of messages in packet *)
-                     destNet    (* of packet, not of messages in packet *)
-                     prodCode   (* 0 for Fido, write to FTSC for others *)
-                     serialNo   (* binary serial number (otherwise null)*)
-                     password   (* session password  (otherwise null)   *)
-                     origZone   (* zone of pkt sender (otherwise null)  *)
-                     destZone   (* zone of pkt receiver (otherwise null)*)
-                     fill[20]
-
-      PacketType   = 02H 00H  (* 01H 00H was used by Fido versions before 10
-                                 which did not support local nets.  The packed
-                                 message header was also different for those
-                                 versions *)
-
-      prodCode     = (  00H      (* Fido *)
-                     |  ...
-                     |  ??H      (* Please apply for new codes *)
-                     )
-
-
-      The  remainder of the packet consists of packed messages.  Each packed
-      message  begins  with  a  message type word 0200H.   A  pseudo-message
-      beginning with the word 0000H signifies the end of the packet.
-
-
-   2. Network Layer Data Description : a File with Attributes
-
-      The  BATCH  protocol uses  the MODEM7 filename and TeLink/XMODEM  file
-      transfer protocols to transfer the file with attributes.
-
-      When  a  file is transferred via  FidoNet, an attempt is made to  also
-      pass  the operating system's attributes  for the file such as  length,
-      modification  date, etc.  FidoNet does this via a special prefix block
-      to  the XMODEM file transfer using a protocol known as TeLink.  As the
-      TeLink  protocol relies on a modification to the XMODEM file  transfer
-      protocol, it is documented at the data link layer level.
-
-      The  MODEM7 file name is redundant if there is also a TeLink block, in
-      which case the name may be taken from either or both.
-
-                              FileName as Sent
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |                   fileName                    |
-              ~                   8  bytes                    ~
-              |           left adjusted blank filled          |
-              +-----------------------+-----------------------+
-        8   8 |                    fileExt                    |
-              ~                    3  bytes                   ~
-              |           left adjusted blank filled          |
-              `-----------------------------------------------'
-
-
- 3. Network Layer Protocol : BATCH File Finite State Machines
-
-
-    BATCH File Sender
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         | St  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | BS0*| MoreFiles| 1 more files to send    | (MODEM7 FName send MS0) | BS1 |
-   |     |          | 2 no more files to send |                         | BS3 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | BS1 | CheckFNm | 1 MODEM7 Filename ok    | (TeLink send file XS0)  | BS2 |
-   |     |          | 2 MODEM7 Filename bad   | report name send bad    | exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | BS2 | CheckFile| 1 TeLink send ok        |                         | BS0 |
-   |     |          | 2 TeLink send bad       | report file send bad    | exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | BS3 | EndSend  | 1 rec NAK for next file | send EOT, report send ok| exit|
-   |     |          | 2 10 seconds no NAK     | send EOT, report no NAK | exit|
-   `-----+----------+-------------------------+-------------------------+-----'
-
-    When  no files remain, the sender responds to the receiver's NAK with an
-    EOT.  The EOT is not ACK/NAKed by the receiver.
-
-    Filenames  must be upper case ASCII.  The data link layer uses "u" as  a
-    control character.
-
-
-    BATCH File Receiver
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         | St  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | BR0*| RecvName |                         | (MODEM7 FName recv MR0) | BR1 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | BR1 | CheckFNm | 1 MODEM7 no more files  | report files recd ok    | exit|
-   |     |          | 2 MODEM7 Filename ok    | (TeLink recv file XR0)  | BR2 |
-   |     |          | 2 MODEM7 Filename bad   | report name recv bad    | exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | BR2 | CheckFile| 1 TeLink recv ok        |                         | BR0 |
-   |     |          | 2 TeLink recv bad       | report file recv bad    | exit|
-   `-----+----------+-------------------------+-------------------------+-----'
-
-
- G. Data Link Layer : Error-Free Data Transfer
-
-   1. Data Link Layer Data Definition : XMODEM/TeLink Blocks
-
-      XMODEM  transfers  are  in  blocks  of 128  uninterpreted  data  bytes
-      preceded  by  a three  byte header  and followed by either a one  byte
-      checksum  or a two byte crc remainder.  XMODEM makes no provision  for
-      data  streams  which  are  not  an  integral number  of  blocks  long.
-      Therefore,  the sender pads streams whose length is not a multiple  of
-      128 bytes with the end-of-file character (^Z for MS-DOS), and use some
-      other  means  to convey  the  true data length to the  receiver  (e.g.
-      TeLink file info block).
-
-      Data blocks contain sequence numbers so the receiver can ensure it has
-      the  correct block.  Block  numbers are sequential unsigned eight  bit
-      integers  beginning with 01H and wrapping to 00H, except that a TeLink
-      block is given sequence number 00H.
-
-      For  files which are attached to the mail packet, not the mail  packet
-      itself,  if the sending system is aware of the file attributes as they
-      are  known to the operating system, then the first block of the XMODEM
-      transfer  may be a special TeLink block to transfer that  information.
-      This  block  differs  in that  the  first byte is a SYN  character  as
-      opposed  to an SOH, and it is always sent checksum as opposed to CRC.
-      Should the receiver be unwilling to handle such information, after two
-      NAKs (or "C"s), the sender skips this special block and goes on to the
-      data itself.
-
-
-
-                        XMODEM Data Block (CRC mode)
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |        SOH  -  Start Of Header -  01H         |
-              +-----------------------------------------------+
-        1   1 |                 BlockNumber                   |
-              +-----------------------------------------------+
-        2   2 |               BlockComplement                 |
-              +-----------------------------------------------+
-        3   3 |                128 bytes  of                  |
-              ~                uninterpreted                  ~
-              |                    data                       |
-              +-----------------------------------------------+
-      131  83 |             CRC high order byte               |
-              +-----------------------------------------------+
-      132  84 |             CRC  low order byte               |
-              `-----------------------------------------------'
-
-
-
-                      XMODEM Data Block (Checksum mode)
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |        SOH  -  Start Of Header -  01H         |
-              +-----------------------------------------------+
-        1   1 |                 BlockNumber                   |
-              +-----------------------------------------------+
-        2   2 |               BlockComplement                 |
-              +-----------------------------------------------+
-        3   3 |                128 bytes  of                  |
-              ~                uninterpreted                  ~
-              |                    data                       |
-              +-----------------------------------------------+
-      131  83 |                Checksum byte                  |
-              `-----------------------------------------------'
-
-
-                       TeLink File Descriptor Block
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |       SYN  -  File Info Header -  16H         |
-              +-----------------------------------------------+
-        1   1 |                     00H                       |
-              +-----------------------------------------------+ data offset
-        2   2 |                     FFH                       |  dec  hex
-              +-----------------------------------------------+
-        3   3 |     File Length, least significant byte       |  0    0
-              +-----------------------------------------------+
-        4   4 | File Length, second to least significant byte |  1    1
-              +-----------------------------------------------+
-        5   5 |  File Length, second to most significant byte |  2    2
-              +-----------------------------------------------+
-        6   6 |      File Length, most significant byte       |  3    3
-              +-----------------------------------------------+
-        7   7 |            Creation Time of File              |  4    4
-              |                "DOS Format"                   |
-              +-----------------------------------------------+
-        9   9 |            Creation Date of File              |  6    6
-              |                "DOS Format"                   |
-              +-----------------------------------------------+
-       11   B |                 File  Name                    |  8    8
-              ~                  16 chars                     ~
-              |        left justified  blank filled           |
-              +-----------------------------------------------+
-       27  1B |                    00H                        | 24   18
-              +-----------------------------------------------+
-       28  1C |            Sending Program Name               | 25   19
-              ~                  16 chars                     ~
-              |         left justified  Null filled           |
-              +-----------------------------------------------+
-       44  2C |            01H (for CRC) or 00H               | 41   29
-              +-----------------------------------------------+
-       45  2D |                    fill                       | 42   2A
-              ~                  86 bytes                     ~
-              |                  all zero                     |
-              +-----------------------------------------------+
-      132  84 |                Checksum byte                  |
-              `-----------------------------------------------'
-
-
-
-      XMODEMData   = XMODEMBlock      (* block of data with header and
-                                         trailer *)
-                     | TeLinkBlock    (* TeLink File Descriptor Block *)
-                     | ACK            (* acknowledge data received ok *)
-                     | NAK            (* negative ACK & poll 1st block *)
-                     | EOT            (* end of xfer, after last block *)
-                     | "C"            (* 43H *)
-
-      XMODEMBlock  = SOH              (* Start of Header, XMODEM Block *)
-                     blockNumber[1]   (* sequence, i'=mod( i+1, 256 ) *)
-                     blockCompl[1]    (* one's compl of BlockNumber *)
-                     data[128]        (* uninterpreted user data block *)
-                     (CRC | Checksum) (* error detect/correction code *)
-
-      TeLinkBlock  = SYN              (* File Info Header *)
-                     00H              (* block no, must be first block *)
-                     FFH              (* one's complement of block no *)
-                     fileLength[4]    (* length of data in bytes *)
-                     CreationTime[2]  (* time file last modified or zero *)
-                     CreationDate[2]  (* date file last modified or zero *)
-                     fileName(16)     (* name of file, not vol or dir *)
-                     00H              (* header version number *)
-                     sendingProg(16)  (* name of program on send side *)
-                     crcMode[1]       (* 01H for CRC 00H for Checksum *)
-                     fill[87]         (* zeroed *)
-                     Checksum         (* error detect/correction code *)
-
-      ACK          = 06H              (* acknowledge data received ok *)
-      NAK          = 15H              (* negative ACK & poll 1st block *)
-      SOH          = 01H              (* start of header, begins block *)
-      SYN          = 16H              (* start of TeLink file info blk *)
-      EOT          = 04H              (* end of xfer, after last block *)
-
-      CRC          = crc[2]           (* CCITT Cyclic Redundancy Check *)
-
-      Checksum     = checksum[1]      (* low 8 bits of sum of data bytes
-                                         using unsigned 8 bit arithmetic *)
-
-      CreationDate = year[.7]         (* 7 bits, years since 1980, 0-127  *)
-                     month[.4]        (* 4 bits, month of year, 1-12 *)
-                     day[.5]          (* 5 bits, day of month, 1-31 *)
-
-      CreationTime = hour[.5]         (* 5 bits, hour of day, 0-23 *)
-                     minute[.6]       (* 6 bits, minute of hour, 0-60 *)
-                     biSeconds[.2]    (* 6 bits, seconds/2, 0-29 *)
-
-
-      Note  that the crcMode is always set to 01H in current implementations
-      as  all TeLink/XMODEM implementations use the CRC method.   Therefore,
-      it is always set to 01H by the sender, and is ignored by the receiver.
-
-
- 2. Data Link Layer Protocol : XMODEM/TeLink Finite State Machines
-
-    The  protocol is receiver driven, the receiver polling the sender  for
-    each  block.   If the receiver polls  for the first block using a  "C"
-    (43H)  as  the poll character,  it would prefer to have the  CRC-CCITT
-    polynomial  remainder error detection code at the end of each block as
-    opposed  to a one byte unsigned checksum.  The sender will respond  to
-    the  "C"  poll iff it can  comply.  If the sender chooses checksum  as
-    opposed  to  CRC, it waits for  the receiver to poll with  NAK  (15H).
-    Should  the  checksum method be  preferable to the receiver, it  polls
-    with NAK rather than "C".
-
-    The sender returns an EOT instead of a data block when no data remain.
-
-    Neither  the  sender nor the  receiver should send the block or  ACK/NAK
-    response  while there is data being received.  They should wait for  the
-    line to settle, and possibly time out.
-
-    It  is  suggested that one's  input buffer be cleared immediately  after
-    sending  block or ACK/NAK response, before waiting for the response from
-    the  other  end.  This  clears  any line garbage which  occurred  during
-    transmit.
-
-
-    XMODEM/TeLink Sender
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         | St  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | XS0 | WaitTeLnk| 1 over 40-60 seconds    | report sender timeout   | exit|
-   |     |          | 2 over 2 tries          | note TeLink block failed| XS1 |
-   |     |          | 3 NAK or "C" received   | send TeLink, incr tries | XS0 |
-   |     |          | 4 ACK received          | TeLink ok, set crc/cksm | XS2 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | XS1 | WaitStart| 1 over 40-60 seconds    | report sender timeout   | exit|
-   |     |          | 2 over 20 tries         | report send failed      | exit|
-   |     |          | 3 NAK received          | set checksum mode       | XS2 |
-   |     |          | 4 "C" recd, I can crc   | set crc mode            | XS2 |
-   |     |          | 5 "C" recd, I can't crc |                         | XS1 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | XS2 | SendBlock| 1 more data available   | send next data block    | XS3 |
-   |     |          |                         |   as checksum or crc    |     |
-   |     |          | 2 last block has gone   | send EOT                | XS4 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | XS3 | WaitACK  | 1 10 retries or 1 minute| report send failed      | exit|
-   |     |          | 2 ACK received          |                         | XS2 |
-   |     |          | 3 NAK (or C if 1st blk) | resend last block       | XS3 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | XS4 | WaitEnd  | 1 10 retries or 1 minute| report send failed      | exit|
-   |     |          | 2 ACK received          | report send successful  | exit|
-   |     |          | 3 NAK received          | resend EOT              | XS4 |
-   `-----+----------+-------------------------+-------------------------+-----'
-
-
-    XMODEM/TeLink Receiver
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         | St  |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | XR0 | RecStart | 1 prefer crc mode       | Send "C"                | XR1 |
-   |     |          | 2 want checksum mode    | send NAK                | XR1 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | XR1 | WaitFirst| 1 10 retries or 1 minute| report receive failure  | exit|
-   |     |          | 2 > 3 retries or 30 secs| set want checksum mode  | XR0 |
-   |     |          | 3 EOT received          | delay < sec, purge input| exit|
-   |     |          |                         | send ACK, report no file|     |
-   |     |          | 4 TeLink block recd     | send ACK, set crc/cksm  | XR2 |
-   |     |          | 5 data block recd       | send ACK, set crc/cksm  | XR2 |
-   |     |          | 6 bad block or 2-10 secs| incr retry count        | XR0 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | XR2 | WaitBlock| 1 10 retries or 1 minute| report receive failure  | exit|
-   |     |          | 2 EOT received          | send ACK, report recd ok| exit|
-   |     |          |                         | send ACK, report recd ok|     |
-   |     |          | 3 data block received   | send ACK                | XR2 |
-   |     |          | 4 bad block or 2-10 secs| send NAK, incr retry cnt| XR2 |
-   `-----+----------+-------------------------+-------------------------+-----'
-
-
-    A  number of checks should be made to ensure a valid data block has been
-    received.
-
-    o  The  physical  layer  should  have encountered no errors,  e.g.  parity,
-       framing, etc.
-
-    o  The length of the block should not be less than expected.
-
-    o  If  the blocks sequence  number does not match the  complement,  then
-       respond with a NAK and attempt to read the block again.
-
-    o  If the block's sequence number is one previous (remember wrap around)
-       to that of the expected block, respond with an ACK and read again.
-
-    o  If the sequence number fits neither of the above criteria, and is yet
-       not the expected sequence number, abort the receive.
-
-    o  The checksum or CRC should be correct.
-
-
-
- 3. Data Link Layer Protocol : MODEM7 Filename Finite State Machines
-
-
-    MODEM7 Filename Sender
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         |  St |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | MS0 | WaitNak  | 1 20 retries or 1 minute| filename send failed    | exit|
-   |     |          | 2 NAK received          | send ACK & 1st ch of fn | MS1 |
-   |     | (note 1) | 3 C received            | return fn skipped       | exit|
-   |-----+----------+-------------------------+-------------------------+-----|
-   | MS1 | WaitChAck| 1 ACK rcd, fname done   | send SUB = 1AH          | MS2 |
-   |     |          | 2 ACK rcd, fname ~done  | send next ch of fname   | MS1 |
-   |     |          | 3 other char or 1 sec   | send "u", incr retry cnt| MS0 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | MS2 | WaitCksm | 1 cksum recd and ok     | send ACK, report fn ok  | exit|
-   |     |          | 2 cksum recd but bad    | send "u", incr retry cnt| MS0 |
-   |     |          | 3 no cksum in 1 sec     | send "u", incr retry cnt| MS0 |
-   `-----+----------+-------------------------+-------------------------+-----'
-
-
-    MODEM7 Filename Receiver
-
-   .-----+----------+-------------------------+-------------------------+-----.
-   |State| State    | Predicate(s)            | Action(s)               | Next|
-   |  #  | Name     |                         |                         |  St |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | MR0 | SendNak  | 1 20 tries or 1 minute  | report filename failure | exit|
-   |     |          | 2                       | send NAK, incr try cnt  | MR1 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | MR1 | WaitAck  | 1 rcd ACK               |                         | MR2 |
-   |     |          | 2 rcd EOT               | report no files remain  | exit|
-   |     |          | 3 5 secs & no ACK/EOT   |                         | MR0 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | MR2 | WaitChar | 1 recd EOT (can happen?)| report no files remain  | exit|
-   |     |          | 2 recd SUB              | send checksum byte      | MR3 |
-   |     |          | 3 recd "u"              |                         | MR0 |
-   |     |          | 4 recd char of name     | send ACK                | MR2 |
-   |     |          | 5 no char in 1 second   |                         | MR0 |
-   |-----+----------+-------------------------+-------------------------+-----|
-   | MR3 | WaitOkCk | 1 recd ACK within 1 sec | report recd filename ok | exit|
-   |     |          | 2 recd "u" or other char|                         | MR0 |
-   `-----+----------+-------------------------+-------------------------+-----'
-
-    SUB  is the ASCII character ^Z or 1AH.  The checksum is the unsigned low
-    order eight bits of the sum of the characters in the transferred filename
-    including the SUB.
-
-    Although  one second timeouts are used successfully by Fido and  SEAdog,
-    some fear that this is too small a timeout for some satellite and packet
-    network links.
-
-    Note 1 - MS0.3 is a common addition to accommodate a common noncompliance.
-             Support of MS0.3 is optional for a compliant mailer.  This hack
-             also requires modification of a number of state tables, see
-             FSC-0011.
-
-
- H. Physical Layer : the Actual Connection of Two FidoNet Systems
-
-    Will  one of the more hardware-oriented comm types give me some idea  of
-    what's needed here?  Can we leave it open enough to allow implementation
-    over a non-dial net?  Thanks.
-
-
- I. Revisions since FTS-0001
-
-    89 Oct 25 (rev 13)
-      o packet header: optional serialNo, password, and orig/dest zone
-      o stored message to/from zone/point info added as option per
-        Fido-12 and Dutchie
-      o XR1 and XR2 changes per FSC-0011
-      o reference to FSC-0011 for the MODEM7-avoidance hack, MS0.3
-      o dropped enumeration of product codes
-      o S4 modification from FSC-0011
-      o Nodelist and EID reference appropriate documents
-      o various cosmetics
-    90 July 1-5 (rev 14)
-      o spelling errors caught by Ray Gardner
-      o references to the now dead IFNA elided
-      o offset at end of Packed Message was 10 as opposed to 20 bytes
-      o Packed Message and Packet Header corrections by Roland Gautschi
-      o Offsets in TeLink header caught by Rick Moore
-    90 August 30 (rev 15)
-      o corrected offsets in packet header
-    95 September 30 (rev 16)
-      o TOPT corrected
-      o contact info changed
-
-
- J. Acknowledgements
-
-    Ben  Baker,  Thom  Henderson,  Tom  Jennings,  Ken Kaplan, and  Gee Wong
-    suggested, informed,  reviewed, and  encouraged.   Tom  and Thom gave me
-    all the basics, and even allowed me to look at actual code.  Bob Hartman 
-    was  foolish  enough  to implement  the  specification, and was generous
-    with useful feedback.  Ray  Gardner caught  my  spelling errors ,
-    and Roland Gautschi and Rick Moore found offset and length errors.
-
-    My employer, Pacific Systems Group was kind enough to donate my time to
-    research and to write this document.
-
-    Fido and FidoNet are registered trademarks of Tom Jennings.
-
-    SEAdog is a trademark of System Enhancement Associates.
-
-
- K. Bibliography
-
-    Documentation  for the protocols  and data formats are scattered.   Some
-    are  unattributed, some even untitled.
-
-    Anonymous, changes to MODEM to implement CRC option  XMDM-CRC.TXT
-
-    Baker, Ken and Moore, Rick, Nodelist Definition, currently FTS-0005
-
-    Christensen, Ward, "MODEM Protocol Overview" of 1 January 82  XMODEM.TXT
-
-    Hartman, Bob, "Some thoughts that I had on FSC001", FSC-0011
-
-    Henderson, Thom, "SEAdog Electronic Mail System Version 3" of April 86
-
-    International  Standards Organization,  "Data Processing - Open  Systems
-    Interconnection - Basic Reference Model"  ISO/DIS 7498  April 82
-
-    Jennings,   Tom,  "FidoNet  Electronic  Mail  Protocol"  8  February  85
-    FIDOMAIL.DOC
-
-    Jennings,   Tom,  "Fido's  Internal  Structures"  of  13  September  85
-    STRUCT.TXT aka STRUCT.APX
-
-    Jennings, Tom, "Extending XMODEM/MODEM File Transfer Protocol to support
-    DOS" 20 September 83   FILEXFER.DOC
-
-    Jordan, Larry, "XMODEM File Transfer Protocol"  XMDM-LJ.TXT
-
-    Rudin,   H   and   West,  C,  "Protocol  Specification,   Testing,   and
-    Verification,  III" Proceedings of  the IFIP WG 6.1 Third  International
-    Workshop   on   Protocol  Specification,  Testing,   and   Verification,
-    Rueschlikon Switzerland 31 May - 2 June 1983.
-
-    Tanenbaum, Andrew, "Computer Networks" Prentice Hall 1981
-
-    Messages generated by Fido 11w, SEAdog 3.8, and QMail 1.01
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-0004.html b/html/ftsc/fts-0004.html deleted file mode 100755 index 5a79fd8e..00000000 --- a/html/ftsc/fts-0004.html +++ /dev/null @@ -1,415 +0,0 @@ - - - -Echomail Specification. - - - - -
-FTS-0004        EchoMail Specification
-
-This document is directly derived from the documentation of
-
--------------------------------------------------------------------------------
-
-                           The Conference Mail System
-                                        
-                                       By
-                                  Bob Hartman
-                       Sysop of FidoNet(tm) node 132/101
-                                        
-                  (C) Copyright 1986,87, Spark Software, Inc.
-                                        
-                              427-3 Amherst Street
-                              CS  2032, Suite  232
-                              Nashua,  N.H.  03061
-                                        
-                              ALL RIGHTS RESERVED.
-
--------------------------------------------------------------------------------
-
-version 3.31 of 12 December, 1987.
-
-With Bob Hartman's kind consent, copying for the purpose of technological
-research and advancement is allowed.
-
-                                        
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-                                        
-
-     WHAT IS THE CONFERENCE MAIL SYSTEM?
-
-          Conference Mail  is a  technique to  permit several  nodes  on  a
-          network to  share a  message base,  similar  in  concept  to  the
-          conferences available on many of the computer services, but it is
-          most closely related to the Usenet system consisting of more than
-          8,000 systems  world wide. All systems sharing a given conference
-          see any  messages entered  into the  conference  by  any  of  the
-          participating systems.  This can  be implemented in such a way as
-          to be  totally transparent  to the users of a particular node. In
-          fact, they  may not  even be  aware of  the network being used to
-          move their  messages about from node to node! Unfortunately, this
-          has its  disadvantages also  - most  users who  are not  educated
-          about Conference  Mail do  not realize  the messages  transmitted
-          cost MANY  sysops (system  operators) money,  not just  the local
-          sysop. This  is an important consideration in Conference Mail and
-          should not be taken lightly.  In a conference with 100 systems as
-          participants the cost per message can get quite high.
-
-          The Conference  Mail System is designed to operate in conjunction
-          with a  FidoNet compatible  mail server.  The currently supported
-          mail servers  are Fido(tm),  SEAdog(tm), Opus, and Dutchie. Since
-          the mail  server is  a prerequisite  to using the Conference Mail
-          System, it  will be  assumed you  already have  your mail  server
-          operating correctly  on your   system, and you are connected into
-          FidoNet or a compatible network.
-
-
-     HISTORY OF THE CONFERENCE MAIL SYSTEM
-
-          In late  1985, Jeff  Rush, a  Fido  sysop  in  Dallas,  wanted  a
-          convenient means  of sharing  ideas with the other Dallas sysops.
-          He created  a system  of programs  he called  Echomail,  and  the
-          Dallas sysops' Conference was born.
-
-          Within a  short time  sysops in other areas began hearing of this
-          marvelous new  gadget and  Echomail took  on a  life of  its own.
-          Today, a  scant year and a half later, the FidoNet public network
-          boasts a myriad of conferences varying in size from the dozen-or-
-          so participants  in the  FidoNet  Technical  Standards  Committee
-          Conference  to   the  Sysops'  Conference  with  several  hundred
-          participants. It  is not  uncommon for a node to carry 30 or more
-          conferences and share those conferences with 10 or more nodes.
-
-
-     HOW IT WORKS
-
-          The Conference  Mail System  is functionally  compatible with the
-          original Echomail utilities.  In general, the process is:
-
-          1. A  message is  entered into  a designated  area on  a  FidoNet
-          compatible system.
-
-          2. This message is "Exported" along with some control information
-          to each system "linked" to the conference through the originating
-          system.
-
-          3. Each  of the  receiving systems  "Import" the message into the
-          proper Conference Mail area.
-
-          4. The receiving systems then "Export" these messages, along with
-          additional control  information,  to  each  of  their  conference
-          links.
-
-          5. Return to step 3.
-
-          As you  can see,  the method  is quite  simple -  in general.  Of
-          course, following  the steps  literally would mean messages would
-          never stop being Exported and transmitted to other systems.  This
-          obviously would  not be  desired or  the  network  would  quickly
-          become overburdened.  The information  contained in  the 'control
-          information' section  is used  to prevent  transmitting the  same
-          message more than once to a single system.
-
-
-     CONFERENCE MAIL MESSAGE CONTROL INFORMATION
-
-          There are  five pieces  of control  information associated with a
-          Conference  Mail  message.  Some  are  optional,  some  are  not.
-          Normally this information is never entered by the person creating
-          the  message.   The  following   control  fields   determine  how
-          Conference Mail is handled:
-
-          1. Area line
-
-               This is  the first  line of  a conference  mail message. Its
-               actual appearance is:
-
-                                     AREA:CONFERENCE
-
-               Where CONFERENCE is the name of the conference. This line is
-               added when  a conference  is  being  "Exported"  to  another
-               system. It  is based upon information found in the AREAS.BBS
-               (configuration) File  for the  designated message area. This
-               field is  REQUIRED by  the receiving  system to  "Import"  a
-               message into the correct Conference Mail area.
-
-          2. Tear Line
-
-               This line is near the end of a message and consists of three
-               dashes (---)  followed by  an  optional  program  specifier.
-               This is  used to show the first program used to add Echomail
-               compatible control information to the message. The tear line
-               generated by Conference Mail looks like:
-
-                                    --- <a small product-specific banner>
-
-               This  field   is  optional   for  most  Echomail  compatible
-               processors, and  is added  by the  Conference Mail System to
-               ensure complete  compatibility. Some systems will place this
-               line in  the message  when it  is first  created, but  it is
-               normally added when the message is first "exported."
-
-          3. Origin line
-
-               This line  appears near  the bottom of a message and gives a
-               small amount  of  information  about  the  system  where  it
-               originated. It looks like:
-
-                      * Origin: The Conference Mail BBS (1:132/101)
-
-               The "  * Origin:  " part  of the  line is  a constant field.
-               This is followed by the name of the system as taken from the
-               AREAS.BBS file  or a  file named  ORIGIN located  in the DOS
-               directory of  the  designated  message  area.  The  complete
-               network address  (1:132/101 in  this case)  is added  by the
-               program inserting  the line.  This field is generated at the
-               same time  as the  tear line,  and therefore  may either  be
-               generated at  the time  of  creation  or  during  the  first
-               "export"  processing.   Although  the  Origin  line  is  not
-               required by  all Echomail  processors, it  is added  by  the
-               Conference Mail System to ensure complete compatibility.
-
-
-          4. Seen-by Lines
-
-               There can  be many  seen-by lines  at the  end of Conference
-               Mail messages,  and they  are the real "meat" of the control
-               information. They  are used  to  determine  the  systems  to
-               receive the exported messages. The format of the line is:
-
-                           SEEN-BY: 132/101 113 136/601 1014/1
-
-               The net/node  numbers correspond  to the net/node numbers of
-               the systems having already received the message. In this way
-               a message  is never  sent to a system twice. In a conference
-               with many  participants the  number of  seen-by lines can be
-               very large.   This line is added if it is not already a part
-               of the  message, or added to if it already exists, each time
-               a message  is exported  to other systems. This is a REQUIRED
-               field, and  Conference Mail  will not  function correctly if
-               this field  is not put in place by other Echomail compatible
-               programs.
-
-          5. PATH Lines
-
-               These are  the last  lines in  a Conference Mail message and
-               are a  new addition,  and therefore  is not supported by all
-               Echomail processors. It appears as follows:
-
-                                  ^aPATH: 132/101 1014/1
-
-               Where the  ^a stands  for Control-A  (ASCII character 1) and
-               the net/nodes  listed correspond  to  those  systems  having
-               processed the  message before it reached the current system.
-               This is  not the  same as  the seen-by  lines, because those
-               lines list  all systems  the message has been sent to, while
-               the path line contains all systems having actually processed
-               the message.  This is not a required field, and few echomail
-               processors currently  support it,  however it  can  be  used
-               safely with  any other  system, since  the line(s)  will  be
-               ignored. For  a discussion  on how  the  path  line  can  be
-               helpful, see the "Advanced Features" section of this manual.
-
-
-     METHODS OF SENDING CONFERENCE MAIL
-
-          To this  point the  issue of how Conference Mail is actually sent
-          has been glossed over entirely. The phrase has been, "the message
-          is exported  to another  system."   What exactly  does this mean?
-          Well, for starters lets show what is called the "basic" setup:
-
-          In this setup exported mail is placed into the FidoNet mail area.
-          Each message   exported  from a  Conference  Mail  area  has  one
-          message generated  for each  receiving system.  This mail is then
-          sent the  same as any other network mail. When Echomail was first
-          created this was the only way mail could be sent.
-
-          The "basic"  method has some disadvantages. First, since Echomail
-          has grown so large it is not uncommon to get 200 new messages per
-          day imported  into various message bases. It is also not uncommon
-          for a  system to  be exporting  messages to 4 or 5 other systems.
-          Simple arithmetic  shows 800-1000  messages per day would be sent
-          in normal  netmail! This  puts a tremendous strain on any netmail
-          system, not  to mention transmission time and the resultant phone
-          charges. When this limitation of Echomail was first noticed a lot
-          of people started scratching their heads wondering what to do. If
-          a  solution  could  not  be  found  it  appeared  Echomail  would
-          certainly overrun the capabilities of FidoNet.
-
-          Thom Henderson  (from System Enhancement Associates) came up with
-          the original  ARCmail program.  Having previously written the ARC
-          file archiving  and compression  program,  he  knew  the  savings
-          achievable by  having all  of the netmail messages placed in .ARC
-          format for  transmission. As  a byproduct, the messages no longer
-          appeared in  the netmail  area,  but  were  included  in  a  file
-          attached to  a message  (see your  FidoNet mailer manual for file
-          attaches).  In   this  way  the  tremendous  number  of  messages
-          generated, and the phone bill problems were both solved.
-
-          Unfortunately, ARCmail  required the  messages to first be placed
-          into the  netmail area  before it  could be  run. In  effect,  it
-          caused the  messages to  be scanned once when they were exported,
-          once during  the ARCmail  phase, once when ARCmail was run at the
-          other end  to get  the messages out of .ARC format, and once when
-          those messages  were later  imported into  a message  base on the
-          receiving system.  The Conference Mail System solves this problem
-          by eliminating  the ARCmail  program. Conference  Mail builds the
-          ARCmail files during Export, and unpacks them during Import. This
-          way  messages   are  exported  directly  to  ARCmail  style  file
-          attaches, and imported directly from ARCmail style file attaches.
-          The scanning  phases between importing and exporting messages are
-          totally removed and processing time is proportionally reduced.
-
-          This is  now the  most common  method for sending Conference Mail
-          between systems.  The overhead  involved in  doing it  during the
-          importing and exporting phases is much less than what is involved
-          if ARCmailing  is not  utilized. This was a primary consideration
-          in the  design and  implementation of the Conference Mail System,
-          and as  a result  the entire system is optimized for this type of
-          use.  Please  refer  to  the  Import  and  Export  functions  for
-          specifics on how to use the ARCmailing feature.
-
-
-     CONFERENCE TOPOLOGY
-
-          The  way   in  which  systems  link  together  for  a  particular
-          conference is  called the "conference topology."  It is important
-          to know  this structure  for two  reasons: 1)  It is important to
-          have a  topology which  is  efficient  in  the  transfer  of  the
-          Conference Mail  messages, and  2) It  is  important  to  have  a
-          topology which  will not  cause systems  to see the same messages
-          more than once.
-
-          Efficiency can  be measured  in a  number  of  ways;  least  time
-          involved for all systems to receive a message, least cost for all
-          systems to receive a message, and fewest phone calls required for
-          all systems  to receive  a message  are all  valid indicators  of
-          efficiency. Users  of Echomail compatible systems have determined
-          (through trial  and error)  the best  measure of  efficiency is a
-          combination  of  all  three  of  the  measurements  given  above.
-          Balancing the equation is not trivial, but some guidelines can be
-          given:
-
-               1. Never have two systems attempting to send Conference mail
-               to each other at the same time. This results in "collisions"
-               that will  cause both  systems to  fail. To  avoid this, one
-               system should  be responsible  for polling  while the  other
-               system is holding mail. This arrangement can alternate based
-               upon various  criteria, but  both systems  should  never  be
-               attempting to call each other at the same time.
-
-               2. Have  nodes form  "stars" for  distribution of Conference
-               Mail. This arrangement has several nodes all receiving their
-               Conference Mail from the same system. In general the systems
-               on the  "outside"  of  the  star  poll  the  system  on  the
-               "inside". The  system on  the "inside"  in turn  polls other
-               systems to  receive the Conference Mail that is being passed
-               on to the "outside" systems.
-
-               3. Utilize  fully connected  polygons with  a few  vertices.
-               Nodes can  be connected in a triangle (A sends to B and C, B
-               sends to  A and  C, C sends to A and B) or a fully connected
-               square (all  corners of  the square send to all of the other
-               corners). This  method is useful for getting Conference Mail
-               messages to each node as quickly as possible.
-
-
-          All of  these efficiency  guidelines have to be tempered with the
-          guidelines dealing  with keeping  duplicate messages  from  being
-          exported. Duplicates  will occur  in any  topology that  forms  a
-          closed polygon  that is not fully connected. Take for example the
-          following configuration:
-
-                                      A ----- B
-                                      |       |
-                                      |       |
-                                      C ----- D
-
-          This square  is a  closed polygon that is not fully connected. It
-          is capable of generating duplicates as follows:
-
-               1. A message is entered on node A.
-
-               2. Node  A exports  the message to node B and node C placing
-               the seen-by for A, B, and C in the message as it does so.
-
-               3. Node  B sees that node D is not listed in the seen-by and
-               exports the message to node D.
-
-               4. Node  C sees that node D is not listed in the seen-by and
-               exports the message to node D.
-
-          At this  point node  D has  received the  same message  twice - a
-          duplicate was  generated. Normally  a "dup-ring"  will not  be as
-          simple as  a square.  Generally it  will be caused by a system on
-          one end  of a  long chain  accidentally connecting to a system on
-          the other end of the chain. This causes the two ends of the chain
-          to become connected, forming a polygon.
-
-          In FidoNet  this problem  is reduced somewhat by having "Regional
-          Echomail Coordinators"  (RECS) that try to keep track of Echomail
-          connections within  their regions  of the  world. A  further rule
-          which is  followed is  that only  the RECS  are allowed  to  make
-          inter-regional connections for the larger conferences. In return,
-          the RECS  have established  a very  efficient topology which gets
-          messages from  coast to  coast, and onto over 200 systems in less
-          than 24  hours. If  no one were willing to follow the rules, then
-          this system  would collapse,  but due to the excellent efficiency
-          it has remained intact for over a year.
-
-
-     Why a PATH line?
-
-          As was  previously mentioned,  the PATH  line is a new concept in
-          Echomail. It  stores the  net/node numbers  of each system having
-          actually processed  a message.  This  information  is  useful  in
-          correcting the  biggest problem  encountered by  nodes running an
-          Echomail compatible  system - the problem of finding the cause of
-          duplicate messages.  How does  the  PATH  line  help  solve  this
-          problem? Take the following path line as an example:
-
-               ^aPATH: 107/6 107/312 132/101
-
-          This  shows  the  message  was  processed  by  system  107/6  and
-          transferred to  system 107/312.  It further  shows system 107/312
-          transferred the  message to  132/101, and  132/101  processed  it
-          again. Now take the following path line as the example:
-
-               ^aPATH: 107/6 107/312 107/528 107/312 132/101
-
-          This shows  the message  having been processed by node 107/312 on
-          more than one occasion. Based upon the earlier description of the
-          'information control'  fields in  Echomail messages, this clearly
-          is an  error in  processing (see  the section  entitled  "How  it
-          Works"). This  further shows   node  107/528 as  the  node  which
-          apparently processed  the message  incorrectly. In  this case the
-          path line  can be  used to quickly locate the source of duplicate
-          messages.
-
-          In  a   conference  with  many  participants  it  becomes  almost
-          impossible to  determine the  exact topology used. In these cases
-          the use of the path line can help a coordinator of the conference
-          track any  possible breakdowns in the overall topology, while not
-          substantially increasing  the amount  of information transmitted.
-          Having this  small amount of information added to the end of each
-          message pays  for itself very quickly when it can be used to help
-          detect a  topology  problem  causing  duplicate  messages  to  be
-          transmitted to each system.
-
--30-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-0005.html b/html/ftsc/fts-0005.html deleted file mode 100755 index a4e4b14c..00000000 --- a/html/ftsc/fts-0005.html +++ /dev/null @@ -1,618 +0,0 @@ - - - -The Distribution Nodelist. - - - - -
- | Document: FTS-0005
- | Version:  003
- | Date:     February 7, 1996
- | Maintainer: David Nugent, 3:632/348@fidonet
-
-
-                       The Distribution Nodelist
-
-                        Originally by Ben Baker
-       Amended by Rick Moore, 1:115/333@FidoNet, February 5, 1989
-     Amended by David Nugent, 3:632/348@FidoNet, February 27, 1996
-
-
-|   Copyright 1986-1996 by the FidoNet Technical Standards Committee.
-    All rights reserved. Duplication and/or distribution permitted
-    for non-commercial purposes only.
-
-    This document supersedes and replaces the document known under
-|   the names of FSC002, FSC-0002, and FTS-0002. Significant changes,
-|   which excludes mere formatting changes, to the previous version
-|   of this document have been "redlined" (marked with a vertical
-|   bar in the leftmost column).
-
-    This document defines the format and content of the nodelist for
-    the Public FidoNet Network (PFN) as published on Friday of each
-|   week. This format is historically known as the "St. Louis nodelist
-|   format".
-
-    The PFN is an international network of independently owned
-    electronic mail systems, most with interlocking electronic
-    bulletin board systems. The distribution nodelist, or simply
-    "nodelist", is the glue which holds the network together. It is
-    the PFN's "phone book" and it defines the top-level network
-|   structure and is the means by which FidoNet retains its integrity
-|   as a point-to-point mail network.
-
-
-| THE NODELIST
-
-    The nodelist is published as an ASCII text file named
-    NODELIST.nnn, where nnn is a three digit number representing the
-|   day-of-year of the Friday publication date, with zeros filling
-|   positions to the left if necessary. This file is packed into a
-|   archive file named NODELIST.?nn, where 'nn' are the last two
-|   digits of day-of-year, and the character at the position of the
-|   '?' indicating the type of compression used. Conventions as to
-|   which compression method is used for the distributed nodelist is
-|   a matter of local policy and is usually determined by each zone's
-|   Zone Coordinator.
-
-    As stated above, NODELIST.nnn is an ASCII text file. It contains
-    two kinds of lines; comment lines and data lines. Each line is
-    terminated with an ASCII carriage return and line feed character
-    sequence, and contains no trailing white-space (spaces, tabs,
-|   etc.). The file is terminated with a DOS end-of-file character
-|   (character value 26 decimal, or "control-Z").
-
-    Comment lines contain a semicolon (;) in the first character
-    position followed by zero or more alphabetic characters called
-    "interest flags". A program which processes the nodelist may use
-    comment interest flags to determine the disposition of a comment
-    line. The remainder of a comment line (with one exception,
-|   treated below) is free-form ASCII text. There are five types of
-|   comments flags:
-
-|       ;S This is of particular interest to Sysops
-|       ;U This is of particular interest to BBS users
-|       ;F This should appear in any formatted "Fido List"
-|       ;A This is of general interest (shorthand for ;SUF)
-|       ;E This is an error message inserted by the nodelist generator
-|       ; This comment may be ignored by a nodelist processor
-
-    The first line of a nodelist is a special comment line containing
-    identification data for the particular edition of the nodelist.
-    The following is an example of the first line of a nodelist:
-
-    ;A FidoNet Nodelist for Friday, July 3, 1987 -- Day number 184 : 15943
-
-    This line contains the general interest flag, the day, date, and
-|   three-digit (zero-filled) day-of-year number of publication, and
-    ends with a 5 digit decimal number with leading zeros, if
-    necessary. This number is the decimal representation of a check
-    value derived as follows:
-
-        Beginning with the first character of the second line, a
-        16 bit cyclic redundancy check (CRC) is calculated for the
-        entire file, including carriage return and line feed
-        characters, but not including the terminating EOF
-        character. The check polynomial used is the same one used
-        for many file transfer protocols:
-
-                    2**16 + 2**12 + 2**5 + 2**0
-
-    The CRC may be used to verify that the file has not been edited.
-    The importance of this will become evident in the discussion of
-    NODEDIFF, below. CRC calculation techniques are well documented
-|   in various technical references, and will not be treated further
-    here.
-
-    The content of the remaining comments in the nodelist are
-    intended to be informative. Beyond the use of interest flags for
-    distribution, a processing program need not have any interest in
-    them.
-
-    A nodelist data line contains eight variable length "fields"
-    separated by commas (,). No space characters are allowed in a
-    data line, and underscore characters are used in lieu of spaces.
-    The term "alphanumeric character" is defined as the portion of
-    the ASCII character set from 20 hex through 7E hex, inclusive.
-    The following discussion defines the contents of each field in a
-    data line.
-
-
-  Field 1: Keyword
-
-    The keyword field may be empty, or may contain one of the
-    following:
-
-    Zone
-
-        Begins the definition of a geographic zone and define its
-        coordinator. All the data lines following a line with the
-        "Zone" keyword down to, but not including, the next
-        occurrence of a "Zone" keyword, are regions, networks, and
-|       nodes within the defined zone.  Node entries defined
-|       immediately after the "Zone" keyword and before the next
-|       region or host entry are known as zone adminstrative nodes.
-|       These are allocated by the Zone Coordinator for use by nodes
-|       in the entire zone; for example, mail gateways between
-|       FidoNet zones.
-
-    Region
-
-        Begins the definition of a geographic region and defines
-        its coordinator. All the data lines following a line with
-        the "Region" keyword down to,  but not including,  the
-        next occurrence of a "Zone",  "Region",  or "Host"
-        keyword, are independent nodes within the defined region.
-
-    Host
-
-        Begins the definition of a local network and defines its
-|       network coordinator. All the data lines following a line
-        with the Host keyword down to, but not including, the
-        next occurrence of a "Zone", "Region",  or "Host" keyword,
-        are local nodes, members of the defined local network.
-
-    Hub
-
-        Begins the definition of a routing sub-unit within a
-        multi-level local network. The hub is the routing focal
-        point for nodes listed below it until the next occurrence
-        of a "Zone", "Region", "Host", or "Hub" keyword. The hub
-        entry MUST be a redundant entry, with a unique number, for
-        one of the nodes listed below it, within its hub segment.
-        This is necessary because some nodelist processors
-        eliminate these entries in all but the local network.
-
-    Pvt
-
-        Defines a private node with unlisted number. Private nodes
-        are only allowed as members of local networks.
-
-    Hold
-
-        Defines a node which is temporarily down. Mail may be sent
-        to it and is held by its host or coordinator.
-
-    Down
-
-        Defines a node which is not operational. Mail may NOT be
-        sent to it. This keyword may not be used for longer than
-        two weeks on any single node, at which point the "down"
-        node is to be removed from the nodelist.
-
-    
-
-|       The field contains no text (not the sequence ""),
-|       and defines a normal node entry.
-
-|   Only one of these may be used in any individual data line.
-
-
-  Field 2: Zone/Region/Net/Node number
-
-    This field contains only numeric digits and is a number in the
-    range of 0 to 32767. If the line had the "Zone", "Region", or
-    "Host" keyword, the number is the zone, net, or region number,
-    and the node has an implied node number of 0. Otherwise, the
-    number is the node number. The zone number, region or net number,
-    and the node number, taken together, constitute a node's FidoNet
-    address.
-
-    Zone numbers must be unique. Region or net numbers must be unique
-    within their zone, hub numbers unique be within their net, node
-|   numbers unique within their net (and region, for regional
-|   independent nodes, zone for zone administrative entries). Duplicate
-    node numbers under different hubs within the same net are not
-    allowed.
-
-
-  Field 3: Node name
-
-    This field may contain any alphanumeric characters other than
-    commas and spaces. Underscores are used to represent spaces, and
-    a comma delimits the end of the field. This is the name by which
-    the node is known, usually as determined by the node or the
-    coordinator responsible for compiling the segment.
-
-
-  Field 4: Location
-
-    This field may contain any alphanumeric characters other than
-    commas and spaces. Underscores are used to represent spaces. This
-    field contains the location of the node. It is usually expressed
-    as the primary local location (town, suburb, city, etc.) plus the
-    identifier of the regional geopolitical administrative district
-    (state, province, department, county, etc.). Wherever possible,
-    standard postal abbreviations for the major regional district
-    should be used (IL, BC, NSW, etc.).
-
-
-  Field 5: Sysop name
-
-    This field may contain any alphanumeric characters other than
-    commas and spaces. Underscores are used to represent spaces. This
-    is the name of the system operator.
-
-
-  Field 6: Phone number
-
-    This field contains at least three and usually four numeric
-    sub-fields separated by dashes (-). The fields are country code,
-    city or area code, exchange code, and number. The various parts
-    of the phone number are frequently used to derive cost and
-    routing information, as well as what number is to be dialed. A
-    typical example of the data in a phone number field is
-    1-800-555-1212, corresponding to country 1 (USA), area 800
-    (inbound WATS), exchange 555, and number 1212.
-
-    Alternatively, this field may contain the notation
-    "-Unpublished-" in the case of a private node. In this case, the
-|   keyword "Pvt" must appear at the start of the line.
-
-
-  Field 7: Baud rate
-
-    This field contains one of the values: 300, 1200, 2400, 9600,
-|   19200, or 38400.
-
-|   This baud rate is indicative only of the maximum baud rate that
-|   may be expected when connecting to a node and is generally of use
-|   only where a calling node needs to adjust the baud rate used to
-|   dial to the caller's modem speed in order to achieve a
-|   connection, a requirement that with modem technology available in
-|   1996 is rarely if ever needed. This information is largely
-|   superseded by modem protocol flags (see next section) where any
-|   two nodes using a common protocol may have other expectations
-|   with regards to actual transfer rates. Use of the baud rate field
-|   alone is therefore depreciated.
-
-
-  Field 8 - Flags
-
-    This optional field contains data about the specific operation of
-    the node, such as file requests, modem protocol supported, etc.
-    Any text following the seventh comma on a data line is taken
-    collectively to be the flags field. The required format is zero
-    or more sub-fields, separated by commas. Each sub-field consists
-    of a flag, possibly followed by a value.
-
-    The following flags define special operating conditions:
-
-       Flag    Meaning
-
-       CM      Node accepts mail 24 hours a day
-       MO      Node does not accept human callers
-|      LO      Node accepts calls only from valid listed node
-|              numbers in the current FidoNet nodelist
-
-
-    The following flags define modem protocols supported:
-
-       Flag    Meaning
-
-|      V21     ITU-T V21      300 bps full duplex
-|      V22     ITU-T V22     1200 bps full duplex
-|      V29     ITU-T V29     9600 bps half duplex
-|      V32     ITU-T V32     9600 bps full duplex
-|      V32b    ITU-T V32bis 14400 bps full duplex
-|      V33     ITU-T V33
-|      V34     ITU-T V34    28800 bps full duplex
-
-       H96     Hayes V9600
-       HST     USR Courier HST up to 9600
-|      H14     USR Courier HST up to 14400
-|      H16     USR Courier HST up to 16800
-       MAX     Microcom AX/96xx series
-       PEP     Packet Ensemble Protocol
-|      CSP     Compucom Speedmodem
-|      ZYX     Zyxel series
-|      VFC     V.Fast Class
-|      V32T    V.32 Terbo
-
-       NOTE:   Many V22 modems also support Bell 212A.
-
-    If no modem flag is given, Bell 212A is assumed for 1200 bps
-    systems, ITU-T V22bis is assumed for 2400 bps systems.
-
-
-    The following flags define type of error correction available. A
-    separate error correction flag should not be used when the error
-    correction type can be determined by the modem flag. For
-|   instance, a modem flag of HST implies MNP, V32b implies V32 and
-|   V42b implies V42. Therefore MNP+HST, H14+MNP, H16+MNP, V32+V32b
-|   and V42+V42b flag pairs are redundant and should not be used.
-
-        Flag    Meaning
-
-        MNP     Microcom Networking Protocol error correction
-|       V42     ITU-T LAP-M error correction w/fallback to MNP 1-4
-|       V42b    ITU-T LAP-M error correction w/fallback to MNP 1-5
-
-
-    The following flags define the type(s) of compression of mail
-    packets supported.
-
-        Flag    Meaning
-
-        MN      No compression supported
-
-|       NOTE:   While FidoNet nodes usually exchange mail
-|               using a variety of different file compression
-|               formats negotiated between individual systems, the
-|               presence of this flag indicates the INABILITY TO
-|               RECEIVE MAIL compressed using the SEA ARC version 5
-|               compression format and/or named according to the
-|               ARCmail 0.6 mail bundle naming method. This is, by
-|               convention, the most common mail compression format
-|               in use within FidoNet. The presence of this flag
-|               would normally indicate that all mail should be sent
-|               uncompressed unless there is some overriding
-|               arrangement with the receiving system.
-
-    The following flags indicate the types of file and file update
-    requests supported.
-
-        Flag    Meaning
-
-        XA      Bark and WaZOO file/update requests
-        XB      Bark file/update requests, WaZOO file requests
-|       XC      Bark file requests, WaZOO file file/update
-        XP      Bark file/update requests
-        XR      Bark and WaZOO file requests
-        XW      WaZOO file requests
-|       XX      WaZOO file/update requests
-
-
-    The following flag defines gateways to other domains (mail
-    networks).
-
-        Flag    Meaning
-
-        Gx..x   Gateway to domain 'x..x', where 'x..x` is a string
-                of alphanumeric characters.
-
-        NOTE:   Valid values for 'x..x' are assigned by the FidoNet
-|               International Coordinator or the person appointed as
-|               Internetworking Coordinator by the FidoNet
-|               International Coordinator. Current valid values of
-                'x..x' may usually be found in the notes at the end
-|               of the current FidoNet nodelist. The most common
-|               gateway flag is "GUUCP", to denote a gateway to the
-|               Internet mail system that gates on behalf of the
-|               fidonet.org internet domain.
-
-
-    The following flags define the dedicated mail periods supported.
-    They have the form "#nn" or "!nn" where nn is the UTC hour the mail
-    period begins, '#' indicates Bell 212A compatibility, and '!'
-    indicates incompatibility with Bell 212A.
-
-        Flag    Meaning
-
-|       #01     Zone 5 mail hour (01:00 - 02:00 UTC)
-        #02     Zone 2 mail hour (02:30 - 03:30 UTC)
-|       #03     Zone 4 mail hour (08:00 - 09:00 UTC)
-        #09     Zone 1 mail hour (09:00 - 10:00 UTC)
-        #18     Zone 3 mail hour (18:00 - 19:00 UTC)
-|       #20     Zone 6 mail hour (20:00 - 21:00 UTC)
-
-        NOTE:   When applicable, the mail period flags may be strung
-                together with no intervening commas, e.g.. "#02#09"
-|               or "!02!09". Only mail hours other than that
-                standard within a node's zone should be given. Since
-                observance of mail hour within one's zone is
-                mandatory, it should not be indicated.
-
-
-    The following flag defines user-specific values. If present,
-    this flag MUST be the last flag present in a nodelist entry.
-
-        Flag    Meaning
-
-        Ux..x   A user-specified string, which may contain any
-                alphanumeric character except blanks. This string
-                may contain one to thirty-two characters of
-                information that may be used to add user-defined
-                data to a specific nodelist entry.
-
-|       NOTE:   Ux..x flags are the mechanism by which new flags may
-|               be experimentally introduced into the nodelist for a
-|               trial period to assess their worth. They are
-|               therefore of a temporary nature, and after their
-|               introduction they are eventually either promoted
-|               to a non-U flag or dropped from use altogether.
-
-    The FTSC recognizes that the FidoNet International Coordinator is
-    the ultimate authority over what appears in the FidoNet nodelist.
-    Also, FTSC is by definition a deliberative body, and adding or
-    changing a flag may take a considerable amount of time.
-    Therefore, the FidoNet International Coordinator may temporarily
-    make changes or additions to the flags as defined in this
-    document. The FidoNet International Coordinator will then consult
-    with FTSC over the changes needed to this document to reflect
-    these temporary changes.
-
-
-    The following are examples of nodelist data lines:
-
-    Host,102,SOCALNET,Los_Angeles_CA,Richard_Martz,1-213-874-9484,2400,XP
-    ,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
-
-
-| THE NODEDIFF
-
-|   With more than thirty-five thousand nodes as of this date (1996),
-|   the nodelist, even in archive form, is a document of substantial
-|   size. Since distribution of the nodelist occurs via electronic
-    file transfer, this file is NOT routinely distributed. Instead,
-|   when a new nodelist is prepared weekly, it is compared with the
-    previous week's nodelist, and a file containing only the
-    differences is created and distributed.
-
-|   The distribution difference file, called NODEDIFF.nnn, where nnn
-    is the day-of-year of publication, is actually an editing script
-    which will transform the previous week's nodelist into the
-    current nodelist. A definition of its format follows:
-
-    The first line of NODEDIFF.nnn is an exact copy of the first line
-|   of LAST WEEK'S nodelist (i.e. the first line of the nodelist to
-|   which the current difference file applies). This is used as a
-    first-level confidence check to insure that the correct file is
-    being edited. The second and subsequent lines are editing
-    commands and data.
-
-    There are three editing commands and all have the same format:
-
-  <command><number>
-
-    <command> is a 1 letter command, one of A, C, or D.
-
-    <number> is a decimal number greater than zero, and defines the
-    number of lines to be operated on by the command. Each command
-    appears on a line by itself. The commands have the following
-    meanings:
-
-        Ann     Add the following nn lines to the output file.
-        Cnn     Copy nn unchanged lines from the input to the output
-                file.
-        Dnn     Delete (or skip) nn lines from the input file.
-
-    The following illustrate how the first few lines of a
-|   hypothetical NODEDIFF.213 might look:
-
-        ;A Friday, July 25, 1986 -- Day number 206 : 27712
-        D2
-        A2
-        ;A Friday, August 1, 1986 -- Day number 213 : 05060
-        ;A
-        C5
-
-    This fragment illustrates all three editing commands. The first
-    line is the first line from the previous nodelist, NODELIST.206.
-    The next line says "delete the first two lines" from
-    NODELIST.206. These are the identification line and the line
-    following it. The next command says "add the next two lines" to
-    NODELIST.213 at the "current" location. The two data lines are
-    followed by a command which says "copy five unchanged lines" from
-    NODELIST.206 to NODELIST.213. Notice that the first line added
-|   will ALWAYS contain the new nodelist CRC, so that the software
-|   applying the changes to the old nodelist may check the result of
-|   its editing.
-
-    Since only the differences will be distributed, it is important
-    to insure the accuracy of the newly created nodelist. This is the
-    function of the CRC mentioned above. It is sufficient for a
-    program designed to perform the above edits to pick the CRC value
-    from the first line added to the output file, then compute the
-    CRC of the rest of the output file. If the two CRCs do not agree,
-    one of the input files has been corrupted. If they do agree, the
-    probability is very high (but not 100%) that the output file is
-    accurate.
-
-    For actual distribution, NODEDIFF.nnn is packed into an archive
-|   file named NODEDIFF.?nn, where 'nn' are the last two digits of
-|   day-of-year, and '?' indicates the compression format used.
-
-
-| NODELIST COMPILATION
-
-|   This section is included for tutorial reasons and is not intended
-|   as a definition of any specific method by which FidoNet MUST
-|   compile its weekly nodelist. It merely represents an attempt to
-|   document the method by which it currently does so. It is intended
-|   to be explanatory, and seeks to answer commonly asked questions,
-|   such as how the nodelist is compiled and where the information
-|   comes from, why the nodelists used in different FidoNet zones are
-|   not the same document, and why the difference file generated for
-|   use in one FidoNet zone cannot be applied to the nodelist
-|   generated for use in a different zone, even though the week
-|   numbers match.
-
-|   Nodelists are compiled via a distributed method, which follows
-|   the same structure as the FidoNet coordinator hierarchy. At the
-|   lowest level, network coordinators maintain a list of the nodes
-|   in their network and are responsible for the addition, removal
-|   and correction of individual node's listings in their "segment"
-|   (as portions of the full nodelist are called). In some larger
-|   networks, it is common for this job to be shared with hub
-|   coordinators appointed by the net coordinator, though the
-|   responsibility for those hub segments still remains with the
-|   network coordinator.
-
-|   At a nominated day during the week, before the regional level
-|   segment is submitted to the zone coordinator, individual net
-|   coordinators submit their segments to the regional coordinator
-|   who subsequently compiles these segments and transmits the merged
-|   copy to the zone coordinator. These are combined by the zone
-|   coordinator with the separate segments of other zones and
-|   compiled into that zone's version of the world nodelist. This
-|   world nodelist is then compared with the previous week's version,
-|   a difference file is generated and subsequently distributed
-|   throughout the zone.
-
-|   In some cases, in the interest of saving in transmission times
-|   and therefore costs, the compilation process itself may be better
-|   served by the submission of DIFFERENCE FILES rather than full
-|   net- or region-level segments. Each coordinator therefore retains
-|   a copy of the previously submitted segments and applies
-|   difference files to those to derive the new one. This process is
-|   exactly identical to the NODEDIFF/NODELIST scenario described
-|   earlier in this document, with the same first line and CRC
-|   validation method used to guard the integrity of the nodelist
-|   segments.
-
-|   For a number of reasons, it is important that publication of the
-|   nodelist be as timely as possible. These reasons include: the
-|   nodelist is a definitive list of valid FidoNet addresses that may
-|   receive mail, and must therefore be as correct and up-to-date as
-|   possible to save nodes the unnecessary expense of mail routed to
-|   possibly non-existing addresses; the nodelist contains the list
-|   of telephone numbers that may be called by any user of the
-|   FidoNet nodelist and should therefore be accurate so as not to
-|   unduly annoy owners of those phone numbers should a listed node
-|   go down and an unsuspecting telephone subscriber inherit the same
-|   telephone number.
-
-|   Given this constraint, the expense of international calls and the
-|   fact that FidoNet is a worldwide network that exists in many time
-|   zones, it may be unreasonable to expect the compilation of the
-|   nodelist to be delayed until each zone coordinator can transmit
-|   their most up-to-date zone segment to a central authority for
-|   compilation and subsequent redistribution in any week. For the
-|   sake of expedience, each zone instead maintains its own separate
-|   world nodelist which contains a compilation of the current zone's
-|   latest segments and including the most current copy to hand of
-|   all other FidoNet zone's segments. The zone level nodelist
-|   generated each week by each zone coordinator is then transmitted
-|   to all other zone coordinators for inclusion into their separate
-|   world nodelist as timing permits.
-
-|   In theory, then, the only difference between nodelists
-|   distributed in each zone in any week are accounted for by timing
-|   differences in the exchange of each zone's separate segment. In
-|   practice, other constraints may interfere with timeliness, such
-|   as the difficulty and expense of international telephonic
-|   communications. Also, another point of variance is introduced by
-|   the fact that each zone usually includes its own zone segment
-|   first into its world nodelist to assist - amongst other things -
-|   software that uses the nodelist for index generation. Some
-|   software in common use in FidoNet indexes the nodelist according
-|   to its sequential order (e.g. version 5 and 6 compiled nodelist
-|   formats), and including the current zone first before others will
-|   have a beneficial effect on software performance.
-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-0006.html b/html/ftsc/fts-0006.html deleted file mode 100755 index c0274e5f..00000000 --- a/html/ftsc/fts-0006.html +++ /dev/null @@ -1,871 +0,0 @@ - - - -YOOHOO and YOOHOO/2U2. - - - - -
-Document: FTS-0006
-Version:  002
-Date:     30-Nov-1991
-
-
-
-
-                            YOOHOO and YOOHOO/2U2
-
-                    The netmail handshake used by Opus-CBCS
-             and other intelligent Fidonet mail handling packages
-
-
-                              Vince Perriello
-                             FidoNet 1:2343/491
-
-
-
-
-Status of this document:
-
-     This FTS (FidoNet(r) Technical Standard) specifies an optional
-     standard for the FidoNet community.  Implementation of the
-     protocols defined in this document is not mandatory,  but all
-     implementations of these protocols are expected to adhere to this
-     standard.  Distribution of this document is subject to the 
-     restrictions listed below.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software
-
-
-
-
-LEGAL STUFF
------------
-
-The original  protocol and documentation are by Wynn Wagner III.  Updates
-have  been  made  to  this  document  by  Vince Perriello,  who  also  is
-responsible for most of the sample routine included with this document.
-
-They are  released to the  public for  any use  whatsoever as long as you 
-don't  modify any  transmitted  structure  or try to  make money  hawking
-either the sample code or this document as if you owned them.
-
-If you choose to use the  method  or  the  sample  routines,  you  do  so
-entirely at your own risk.  It  is  possible that the routines will cause
-physical damage to your equipment, an invasion of  fire ants, the plague,
-or an extended visit from in-laws.  If any  of  that  stuff  (or anything
-else) happens, you accept the consequences totally.
-
-
-CREDITS
--------
-
-Fido  and  Fidonet  are  registered  trademarks of Tom Jennings and  Fido
-Software.
-
-ARCmail was originated by System Enhancement Associates.
-
-The ZModem protocol was designed by Chuck Forsberg. The SEAlink / SEAlink
-Overdrive protocols are copyrighted by System Enhancment Associates.  The
-TeLink protocol was designed and first implemented by Tom Jennings.
-
-The state charts in this document were done by Vince Perriello.
-
-Rick Huebner designed  and  implemented  the  basic  WaZOO  file  request
-method.  Update  request functionality was added by Vince Perriello.  Bob
-Hartman is responsible for the addition of Domain support.
-
-FTS-0001, describing the base FidoNet protocol, was created by Randy Bush.
-
-FTS-0007, describing enhancement to FTS-0001 using SEAlink and/or SEAlink
-Overdrive, was created by Phil Becker.
-
-YooHoo and YooHoo/2u2                                              Page 2
-Overview
-
-
-
-UPFRONT
--------
-
-YOOHOO and YOOHOO/2U2 are  the  initial  handshakes  for the WaZOO e-mail
-protocol.  They are designed to let two systems establish a common ground
-for a netmail session while making  sure  that non-WaZOO software doesn't
-get upset by material it can't understand.
-
-The YOOHOO procedure begins as a single  byte  (0xf1).   If the system on
-the other end doesn't reply to that byte,  no  further  YOOHOO  or  WaZOO
-transmissions are attempted.  To a non-WaZOO netmail system,  the  YOOHOO
-byte will simply seem like a byte of debris.
-
-The  calling  system  initiates  the  YOOHOO  by  sending  the  attention
-character.   If the receiving system seems interested, the calling system
-sends a  128  byte packet containing such information as system and sysop
-names as well as a "capability mask." A 16-bit CRC protects the integrity
-of the 128-byte packet.
-
-In response, the receiving  system  prepares  a  128  byte packet to send
-back.  This is the YOOHOO/2U2 procedure.
-
-
-FEATURES
---------
-
-The features of YOOHOO and YOOHOO/2U2 include
-
-      * non-interference with systems that don't understand the
-        handshake
-
-      * almost foolproof method for identifying a remote system
-        and establishing a common ground for transmission
-
-      * built-in room to expand the capabilities of WaZOO without
-        having to resort to a kludge
-
-
-USAGE
------
-
-A calling system simply uses  a  routine  that  transmits both YooHoo and
-TSYNC  handshake initiating characters to the  called  system.    If  the
-called system responds with an XMODEM 'NAK',  an FTS-0001 session will be
-initiated.  If an 'ENQ' is received, the  `YooHoo_Sender()'  routine will
-be invoked to handle the session negotiation.
-
-A  receiving  system  can call a routine like `YooHoo_Receiver()'  if  it
-detects the YOOHOO character, or just drop into the FTS-0001  logic if it
-sees a TSYNC.
-
-This simple method allows a mailer to take care of both the TSYNC and the
-YOOHOO handshakes.
-
-YooHoo and YooHoo/2u2                                              Page 3
-WaZOO Protocols
-
-
-
-PROTOCOLS
----------
-
-Currently there are four WaZOO methods in use:
-
-1. ZedZap 
-   ------
-
-        a Zmodem variant. The originator does a batch send then goes into a
-        receive batch mode.  The called system does receive then send. In 
-        the event of a file request (see description below) made by the 
-        called system, one more turnaround is made to service the request.
-
-      * Unlike the "True" Zmodem protocol described by Chuck Forsberg, 
-        ZedZap routines must be able to handle a batch mode that has no 
-        actual files. In other words, it is possible for there to be a 
-        init sequence followed immediately by a ZFIN.
-
-      * The maximum packet size is 8192. This is usually varied based on 
-        the baud rate. For example, at 2400 it might be 2048 bytes, then 
-        for 9600 baud and above the maximum of 8192 could apply. Note that
-        THIS IS A SIGNIFICANT VARIATION FROM STRICT ZMODEM IMPLEMENTATION.
-        (There's another WaZOO capability bit for those systems which 
-        can not handle this block size)
-
-      * Netmail packets are transmitted as files with names in the form
-        "12345678.PKT". Because of this, multiple packets may be sent in 
-        a single session.
-
-      * If the calling system transmits a .REQ file for file requests, the
-        receiving system can respond to it.  See "WaZOO File Requests" 
-        (below) for information on the .REQ file.
-
-2. ZedZip
-   ------
-
-        This capability is identical to ZedZap, but does not use buffers
-        greater than 1K in size (like "True" Zmodem). It is also 
-        permissible to send a "null" packet in a ZedZip session. This
-        allows a system which must use a strict Zmodem implementation to
-        participate in a WaZOO session using Zmodem.
-
-
-3. DietIFNA
-   --------
-
-        The session operates like FTS-0001/FTS-0007. The notable exceptions 
-        are as follows:
-
-      * The same packet naming convention as ZedZap applies, allowing more
-        than one packet to be transmitted in a single session.
-
-YooHoo and YooHoo/2u2                                              Page 4
-WaZOO Protocols
-
-
-
-      * Telink file transfers don't even attempt to exchange file names
-        using modem7. The receiving system extracts the file name from the 
-        Telink or SEAlink header block.
-
-      * If SEAlink is used, run-ahead (the number of blocks to slide) is 
-        based on the baud rate:  BlocksToSlide = BaudRate / 400, up to a 
-        max of 24 blocks.
-
-      * When there is nothing to send, a system should remain quiet.  In 
-        other words, the end of a session can be determined by a timeout.
-
-      * Under no circumstances should "BARK" file request logic be active
-        during a DietIFNA session. File requests, if any, should be 
-        transmitted using a .REQ file.
-
-
-        Many implementations of DietIfna have been accomplished by the mere
-        exchange of packets, followed by straight FTS-0001/0007 code. This
-        is incorrect but probably not easily remedied at this point. We have
-        made an effort to document this change in "reality" in this revision
-        of the document.
-
-4. Janus
-   -----
-
-        Janus is a full-duplex simultaneous bidirectional file transfer
-        protocol. In other words, it can send and receive files at the same
-        time.  It's very loosely derived from ZModem and HDLC/X.25 protocol
-        technology, in that it uses variable length data-typed packets, and
-        that transmission of file data does not require ACKs.
-
-        The protocol is documented elsewhere; it is beyond the scope of this
-        document to do so.
-
-YooHoo and YooHoo/2u2                                              Page 5
-Choosing WaZOO Methods
-
-
-
-How to decide which WaZOO method to use
----------------------------------------
-
-
-Since the called system has all the information  necessary to decide what
-WaZOO method to employ,  the best way to implement the process is for the
-calling  system  to send,  in its  capability  mask,  all the  bits which
-correspond to methods it can use (or wants to use)  in communicating with
-the called system.  The called  system then looks at these bits and sends
-back only the bit which corresponds to the method it wants to use.
-
-If the  called system  sends  back a mask  which contains  more  than one
-capability of the  calling system,  it can create a  problem situation if
-one system  arrives at its choice of methods  differently from the other.
-Thus, when the called system doesn't make the choice, both systems should
-choose as follows:
-
-1. Janus
-
-2. ZedZap
-
-3. ZedZip
-
-4. DietIFNA
-
-The capability highest on the list which both systems indicate ability to
-execute should be the one employed.
-
-YooHoo and YooHoo/2u2                                              Page 6
-WaZOO Filename conventions
-
-
-
-WaZOO FILENAMES
----------------
-
-
-1. MESSAGE PACKETS ... xxxxxxxx.PKT
-
-        Normal (unarchived) messages are sent in a file name that has a tag 
-        of .PKT.  The "x" characters should be hex digits.
-
-
-2. ARCmail ... xxxxxxxx.{MO|TU|WE|TH|FR|SA|SU}#
-
-        Message packets are often shipped in an archive that has been
-        compressed with some LZ utility.
-
-        The file name consists of a name with hex digits. The tag is one of
-        seven two-character prefixes ("MO", "TU", "WE", "TH", "FR", "SA" or
-        "SU") and a number (0-9).
-
-        This particular naming convention was established by ARCmail version
-        0.60, which is a defacto standard in FidoNet.
-
-
-3. FILE REQUESTS ... xxxxxxxx.REQ
-
-        This is explained below.
-
-        In a nutshell, the file name consists of the receiving system's 
-        Fidonet address expressed as two 4-digit hex numbers.  The file tag 
-        is .REQ.
-
-        In a Janus session, the .REQ file isn't actually sent. Janus has
-        a transaction system which sends the .REQ file one line at a time
-        and then accepts the file(s) which the request generates.
-
-YooHoo and YooHoo/2u2                                              Page 7
-Flow of a ZedZap or ZedZip Session
-
-
-
-FLOW OF A ZEDZAP OR ZEDZIP SESSION
-----------------------------------
-
-
-
-The calling system:
-
-
-      * Send YooHoo
-
-      * Receive YooHoo/2u2
-
-      * In a single batch, send bundles, files, file request (.REQ) files 
-        (in that order)
-
-      * In a single batch, receive bundles, files, file requests, and 
-        requested files (in that order)
-
-      * If a file request (.REQ) file came in, send all requested files 
-        in a single batch.
-
-
-Receiving system:
-
-      * Receive YooHoo
-
-      * Send YooHoo/2u2
-
-      * In a single batch, receive bundles, files, file requests
-
-      * In a single batch, send bundles, files, our file requests, and 
-        respond to file requests that arrived from the remote system.
-
-      * If we sent a .REQ file in the preceding step, receive all files 
-        in a single batch.
-
-
-YooHoo and YooHoo/2u2                                              Page 8
-WaZOO File Requests
-
-
-
-WAZOO FILE REQUESTS
--------------------
-
-Rick Huebner, who adapted the ZModem routines for Opus, and the architect of
-the Janus file transfer protocol, designed the ".REQ file"-based file request
-system.
-
-
-REQ FILE:
-
-A WaZOO file request is based on a request file.  The name of a request file
-is similar to the .OUT and .FLO files used by Opus-CBCS and similar mail
-products (such as BinkleyTerm).
-
-         TEMPLATE: netnode.REQ
-
-         EXAMPLE:  00010002.REQ   ... a request being sent to 1/2
-
-The .REQ file is simply a text file that contains the files we want from the
-remote system. Those file names can include wildcards, but should not contain
-a path. Optionally, there can be a password if the sending system requires one.
-
-The "netnode" part of the file name is built from the remote systems net and
-node numbers.  Both numbers become 4-character hex numbers in the file name.
-
-Let's say we're requesting THIS.ARC and all node lists from 12/2.  The file
-name would be 000C0002.REQ.  The contents would look like this:
-
-                  this.arc
-                  nodelist.*
-
-If the sysop of 12/2 requires a password of THAT to get the file THIS.ARC, the
-REQ file contents would have to change:
-
-                  this.arc !that
-                  nodelist.*
-
-Transaction-level passwords (of 6 or fewer characters) follow the file name:
-
-                  <filename><single-space-character>!<password><cr>
-
-YooHoo and YooHoo/2u2                                              Page 9
-WaZOO File Requests
-
-
-
-
-If the request is of the "update" genre, the type of update and the time,
-expressed as a UNIX-style long decimal ASCII number, follows the name, or in
-the event that there is a transaction-level password, the password. For
-example, an update request for file NEWOPUS.*, where you already have a file
-dated 1-January 1989, 00:00 and you live on the East Coast (GMT+06) would be:
-
-                  NEWOPUS.* +599634000
-
-The sign is required, it indicates the type of update request. A '+' means
-that all files matching the filespec "NEWOPUS.*" newer than the shown time
-will be sent, a '-' means that all matching files with dates up to and
-including the indicated time will be sent.
-
-
-The complete format of an action line in an REQ file is, then:
-
-          <filename>[<space>!<password>][<space><+/-><time>]<cr>
-
-
-
-MECHANISM:
-
-In a ZedZap or DietIfna session, the .REQ file is simply transmitted to the 
-other system.  It goes "as is" like any other file. In a Janus session, the
-.REQ file will be sent one line at a time and individually serviced by the
-other end.
-
-The other system can ignore the request, send some of the files, or send all
-of the files.  There is no accounting or responsibilities on the part of the
-remote system.
-
-If your implementation is unable to process the update information for any
-reason, then you should process the line as a "regular" file request.
-
-
-
-NOTE:
-
-In the YooHoo packet, there's a bit that lets you know if the remote system
-currently accepts .REQ files.  This will be a clue as to whether a .REQ file
-would be a waste of time or not. Procedurally, you just should not send a .REQ
-file to a system which indicates that it won't process it.
-
-YooHoo and YooHoo/2u2                                              Page 10
-Structures and Definitions
-
-
-
-STRUCTURES AND DECLARATIONS
----------------------------
-
-
-#define ACK    0x06
-#define NAK    0x15
-#define ENQ    0x05
-#define YOOHOO 0xf1
-#define TSYNC  0xae
-
-struct   _Hello
-    {
-    word     signal;           /* always 'o'     (0x6f)                   */
-    word     hello_version;    /* currently 1    (0x01)                   */
-    word     product;          /* product code                            */
-    word     product_maj;      /* major revision of the product           */
-    word     product_min;      /* minor revision of the product           */
-    char     my_name[60];      /* Other end's name, will include domain   */
-                               /* if DO_DOMAIN is set in capabilities mask*/
-    char     sysop[20];        /* sysop's name                            */
-    word     my_zone;          /* 0== not supported                       */
-    word     my_net;           /* out primary net number                  */
-    word     my_node;          /* our primary node number                 */
-    word     my_point;         /* 0 == not supported                      */
-    byte     my_password[8];   /* This is not necessarily null-terminated */
-    byte     reserved2[8];     /* reserved by Opus                        */
-    word     capabilities;     /* see below                               */
-    byte     reserved3[12];    /* for non-Opus systems with "approval"    */
-    };                         /*          total size 128 bytes           */
-
-
-
-/*------------------------------------------------------------------------*/
-/* YOOHOO<tm> CAPABILITY VALUES                                           */
-/*------------------------------------------------------------------------*/
-#define Y_DIETIFNA 0x0001  /* Can do fast "FTS-0001"  0000 0000 0000 0001 */
-#define FTB_USER   0x0002  /* Reserved by Opus-CBCS   0000 0000 0000 0010 */
-#define ZED_ZIPPER 0x0004  /* Does ZModem, 1K blocks  0000 0000 0000 0100 */
-#define ZED_ZAPPER 0x0008  /* Can do ZModem variant   0000 0000 0000 1000 */
-#define DOES_IANUS 0x0010  /* Can do Janus            0000 0000 0001 0000 */
-#define Bit_5      0x0020  /* reserved by FTSC        0000 0000 0010 0000 */
-#define Bit_6      0x0040  /* reserved by FTSC        0000 0000 0100 0000 */
-#define Bit_7      0x0080  /* reserved by FTSC        0000 0000 1000 0000 */
-#define Bit_8      0x0100  /* reserved by FTSC        0000 0001 0000 0000 */
-#define Bit_9      0x0200  /* reserved by FTSC        0000 0010 0000 0000 */
-#define Bit_a      0x0400  /* reserved by FTSC        0000 0100 0000 0000 */
-#define Bit_b      0x0800  /* reserved by FTSC        0000 1000 0000 0000 */
-#define Bit_c      0x1000  /* reserved by FTSC        0001 0000 0000 0000 */
-#define Bit_d      0x2000  /* reserved by FTSC        0010 0000 0000 0000 */
-#define DO_DOMAIN  0x4000  /* Packet contains domain  0100 0000 0000 0000 */
-#define WZ_FREQ    0x8000  /* WZ file req. ok         1000 0000 0000 0000 */
-
-YooHoo and YooHoo/2u2                                              Page 11
-Domain addressing in Hello Packet
-
-
-Since the invention of the WaZOO handshake, nearly every change in the
-FidoNet transport has been accessible by defining bits for new protocols,
-using the point number field in the structure, etc.
-
-With the advent of Domain addressing in FidoNet, this was no longer the
-case. There was no place set aside in the hello packet where domain info
-could be passed from one system to another.
-
-We have addressed this requirement by using some of the space set aside
-in the system name field for the domain. It is backward-compatible with
-all systems which determine the end of a string by use of a null.
-
-WaZOO systems that support domains communicate that fact by setting the
-DO_DOMAIN bit (hex 2000) in the capabilities mask. This tells the other
-side that they can expect to find a domain address in the packet.
-
-The domain name is stored at the end of the 'my_name' field. It is stored
-in its entirety (no abbreviations as in FSC-0045) after the system name.
-If the length of the system name plus the null terminator plus the length
-of the domain name plus terminator exceeds 60, the system name will be
-truncated (right to left) to make it fit.
-
-So, for a system named "FUBAR" at address 1:234/567@fidonet.org, the
-address and name fields in the header would look like this:
-
-hello.my_zone  = 1
-hello.my_net   = 234
-hello.my_node  = 567
-hello.my_point = 0
-hello.my_name  = 'F','U','B','A','R', 0, 'f','i','d','o','n','e','t',
-                 '.','o','r','g',0
-hello.capabilities will contain the usual capabilities plus DO_DOMAIN.
-
-A remote system receiving this packet should look past the null in
-my_name to get the domain name.
-
-YooHoo and YooHoo/2u2                                              Page 12
-Caller State Tables
-
-
-
-Calling System:
-
-
-The parts of FTS-0001 and FTS-0007 which deal with synchronization of calling
-and called system must be modified to deal with the reception and processing
-of the YooHoo character and exchange of Hello packets. The following state
-table may be used to initiate an FTS-0001 or a WaZOO session by the calling
-system.  It replaces state S3 in the FTS-0001 table.
-
-
-
- .-----+----------+-------------------------+-------------------------+-----.
- |State| State    | Predicate(s)            | Action(s)               | Next|
- |  #  | Name     |                         |                         | Stat|
- |-----+----------+-------------------------+-------------------------+-----|
- | SS0 | SyncInit |                         | Prepare 3 sec Sync timer|     |
- |     |          |                         | Prepare .5 sec NAK tmr  |     |
- |     |          |                         | Init NAK Count          |     |
- |     |          |                         | Start 60 sec master tmr | SS1 |
- |-----+----------+-------------------------+-------------------------+-----|
- | SS1 | SendSync | 1. Over 60 seconds      |                         |     |
- |     |          |    or carrier lost      | no response             | exit|
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 2. 3 sec elapsed        | Clear Inbound buffer    |     |
- |     |          |    or timer not started | Send YOOHOO, then TSYNC |     |
- |     |          |                         | Start 3 sec Sync timer  | SS2 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 3. not elapsed          |                         | SS2 |
- |-----+----------+-------------------------+-------------------------+-----|
- | SS2 | WaitResp | 1. Nothing received     | require a response      | SS1 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 2. ENQ received         | WaZOO Protocol selected | exit|
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 3. 'C' received         | probable FTS-0001       | SS3 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 4. NAK received         | probable FTS-0001       | SS3 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 5. Debris (might include| Reset NAK timer         |     |
- |     |          |    (YOOHOO|TSYNC) & 127)| if started              | SS1 |
- |-----+----------+-------------------------+-------------------------+-----|
- | SS3 | NAKTmr   | 1. Timer not expired    | Zero NAK count          |     |
- |     |          |    or timer not started | Start .5 sec NAK timer  | SS1 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 2. Timer expired        | Bump NAK count          | SS4 |
- |-----+----------+-------------------------+-------------------------+-----|
- | SS4 | NAKCount | 1. Count >= 2?          | assume FTS-0001         | exit|
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 2. Count < 2            | Keep looking            | SS1 |
- `-----+----------+-------------------------+-------------------------+-----'
-
-YooHoo and YooHoo/2u2                                              Page 13
-Caller State Tables
-
-
-Calling System (continued):
-
-
-
-The FTS-0001 exits from the above table should operate using the FTS-0001 
-state tables, starting at state S4. The "WaZOO detected" case should proceed 
-using the following state table:
-
-
-
- .-----+----------+-------------------------+-------------------------+-----.
- |State| State    | Predicate(s)            | Action(s)               | Next|
- |  #  | Name     |                         |                         | Stat|
- |-----+----------+-------------------------+-------------------------+-----|
- | YS1 | SndHello | Successful              | Looks like WaZOO        | YS2 |
- |     | (state   +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |  SH1)    | Not successful          | Repeat whole thing      | exit|
- |-----+----------+-------------------------+-------------------------+-----|
- | YS2 | WaitResp | 30 sec timer expires    | repeat whole thing      | exit|
- |     |          | or lost carrier         |                         |     |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Received YOOHOO         | Another WaZOO, go       | YS3 |
- |     |          |                         | process receive         |     |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Received debris         | Repeat whole thing      | YS2 |
- |-----+----------+-------------------------+-------------------------+-----|
- | YS3 | GetHello | Information             | Report Success          | exit|
- |     | (state   | Successfully            |                         |     |
- |     |  RH1)    | Exchanged               |                         |     |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Failure                 | Repeat whole thing      | exit|
- `-----+----------+-------------------------+-------------------------+-----'
-
-
-
-The failure cases in this table may be retried. The retry should be from 
-the point of synchronization. This means redoing the process in the SendSync
-table on Page 11. A really smart mailer could therefore do a YooHoo, exchange
-information, decide that it doesn't want to do WaZOO, fail out, and attempt 
-an FTS-0001 session.
-
-
-If the packet exchange is successful, session method selection proceeds and
-then the chosen session method should be employed to exchange mail and files.
-
-YooHoo and YooHoo/2u2                                              Page 14
-Called System State Tables
-
-
-
-The following state table may be used to initiate an FTS-0001 or a WaZOO
-session by the called system.  It replaces states R1 and R2 in the FTS-0001
-table.
-
-
- .-----+----------+-------------------------+-------------------------+-----.
- |State| State    | Predicate(s)            | Action(s)               | Next|
- |  #  | Name     |                         |                         | Stat|
- |-----+----------+-------------------------+-------------------------+-----|
- | RS0 | SyncInit |                         | Start 5 second idle tmr | RS1 |
- |-----+----------+-------------------------+-------------------------+-----|
- | RS1 | IdleWait | 1. 5 sec tmr expired    | Take the initiative     | RS2 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 2. Carrier lost         | Session aborted         | exit|
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 3. Peek = YOOHOO        | Looks like a live WaZOO | RS3 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 4. Peek = TSYNC         | Live FTS-0001, we think | RS3 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 5. Peek = CR, LF, space | He looks alive          | RS2 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 6. Other character      | Eat it                  | RS1 |
- |-----+----------+-------------------------+-------------------------+-----|
- | RS2 |SendBanner| 1. Error returned       | Session aborted         | exit|
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 2. Banner sent OK       |                         | RS3 |
- |-----+----------+-------------------------+-------------------------+-----|
- | RS3 |RecvInit  |                         | Start 20 sec timer      | RS4 |
- |     |          |                         | Init 10 sec timer       |     |
- |-----+----------+-------------------------+-------------------------+-----|
- | RS4 |SendSync  | 1. Error returned       | Session aborted         | exit|
- |     |(xmit sync+-------------------------+-------------------------+-----|
- |     |string)   | 2. String sent OK       | Watch for sender sync   | RS5 |
- |-----+----------+-------------------------+-------------------------+-----|
- | RS5 | WaitSync | 1. Carrier lost         | Session aborted         | exit|
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 2. YOOHOO received      | WaZOO session selected  | exit|
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 3. TSYNC received       | probable FTS-0001       | RS6 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 4. CR received          | Still sync'ing          | RS4 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 5. Other character rcvd | Get next input character| RS5 |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 6. 10 sec timer elapsed | FTS-0001 selected       | exit|
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 7. 20 sec timer elapsed | Not a mail session      | exit|
- |-----+----------+-------------------------+-------------------------+-----|
- | RS6 | TsyncTmr | 1. Timer not running    | Start 10 second timer   | RS5 |
- |     |          |                         | Reset 20 sec timer      |     |
- |     |          +-------------------------+-------------------------+-----|
- |     |          | 2. Timer running        | Two TSYNCS = FTS-0001   | exit|
- `-----+----------+-------------------------+-------------------------+-----'
-
-YooHoo and YooHoo/2u2                                              Page 15
-Called System State Tables
-
-
-
-The FTS-0001 exits from the above table should operate using the FTS-0001 
-state tables, starting at state R3. The "WaZOO detected" case should proceed
-using the following state table:
-
-
-
- .-----+----------+-------------------------+-------------------------+-----.
- |State| State    | Predicate(s)            | Action(s)               | Next|
- |  #  | Name     |                         |                         | Stat|
- |-----+----------+-------------------------+-------------------------+-----|
- | YR1 | GetHello | Information             | Start 20 sec timer      | YR2 |
- |     | (state   | Successfully            | Initialize retry count  |     |
- |     |  RH1)    | Exchanged               | Send YooHoo             |     |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Failure                 | Repeat whole thing      | exit|
- |-----+----------+-------------------------+-------------------------+-----|
- | YR2 | WaitResp | 20 sec timeout          | try again               | YR3 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Lost carrier            | Failure                 | exit|
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Received ENQ            | Go send hello           | YR4 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Received debris         | Keep looking            | YR2 |
- |-----+----------+-------------------------+-------------------------+-----|
- | YR3 | PollPeer | More than 3 retries     | Give it up              | exit|
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Less than 3 retries     | Bump retry count        | YR2 |
- |     |          |                         | Clear input buffer      |     |
- |     |          |                         | Send YOOHOO             |     |
- |     |          |                         | Restart 20 sec timer    |     |
- |-----+----------+-------------------------+-------------------------+-----|
- | YR4 | SndHello | Successful              | All done, report success| exit|
- |     | (state   +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |  SH1)    | Not successful          | Repeat whole thing      | exit|
- `-----+----------+-------------------------+-------------------------+-----'
-
-
-
-The failure cases in states YR1, YR3 and YR4 of this table may be retried. 
-The retry should be from the point of synchronization. This means redoing the
-process in the RecvSync table on Page 13, beginning at state RS3. A really
-smart mailer could therefore do a YooHoo, exchange information, decide that 
-it doesn't want to (or cannot) do a WaZOO session, fail out, and attempt 
-an FTS-0001 session.
-
-
-If the packet exchange is successful, session method selection proceeds and
-then the chosen session method should be employed to exchange mail and files.
-
-YooHoo and YooHoo/2u2                                              Page 16
-Packet Exchange State Tables
-
-
-
-The following state table describes the transmission of the "Hello" packet 
-from one system to its partner:
-
-
-
- .-----+----------+-------------------------+-------------------------+-----.
- |State| State    | Predicate(s)            | Action(s)               | Next|
- |  #  | Name     |                         |                         | Stat|
- |-----+----------+-------------------------+-------------------------+-----|
- | SH1 | InitSend |                         | Disable XON/XOFF        | SH2 |
- |     |          |                         | Set retry count to 0    |     |
- |-----+----------+-------------------------+-------------------------+-----|
- | SH2 | SendHedr |                         | Send Hex 1f, then       | SH3 |
- |     |          |                         | Send HELLO struct       |     |
- |-----+----------+-------------------------+-------------------------+-----|
- | SH3 | SendCRC  |                         | Clear Input Buffer      | SH4 |
- |     |          |                         | Send two-byte CRC of pkt|     |
- |     |          |                         | MSB followed by LSB     |     |
- |     |          |                         | Start 40 second timer   |     |
- |-----+----------+-------------------------+-------------------------+-----|
- | SH4 | GetResp  | 40 second timer expires | Failed to send packet   | exit|
- |     |          | or carrier lost         |                         |     |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | ACK received            | Successful transmission | exit|
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | '?' received            | Error, try retransmit   | SH2 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | ENQ received            | Out of sync?            | SH2 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | other character recvd   | Debris, keep watching   | SH4 |
- `-----+----------+-------------------------+-------------------------+-----'
-
-YooHoo and YooHoo/2u2                                              Page 17
-Packet Exchange State Tables
-
-
-The following state table describes the reception of the "Hello" packet sent
-to a system by its partner:
-
- .-----+----------+-------------------------+-------------------------+-----.
- |State| State    | Predicate(s)            | Action(s)               | Next|
- |  #  | Name     |                         |                         | Stat|
- |-----+----------+-------------------------+-------------------------+-----|
- | RH1 | SendENQ  |                         | Start 2 minute timer    | RH2 |
- |     |          |                         | Send an ENQ character   |     |
- |-----+----------+-------------------------+-------------------------+-----|
- | RH2 | WaitHedr | 2 minute timer expires  | Report failure          | exit|
- |     |          | or carrier lost         |                         |     |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Received Hex 1f         | Got header, get packet  | RH5 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Received other char     | Debris, throw away      | RH3 |
- |     |          |                         | Start 10 sec timer      |     |
- |-----+----------+-------------------------+-------------------------+-----|
- | RH3 | TossJunk | 10 sec timer expires    | Too much noise          | RH4 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Received Hex 1f         | Got header, get packet  | RH5 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Input buffer empty      | Try to resynch          | RH4 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Carrier lost            | Report failure          | exit|
- |-----+----------+-------------------------+-------------------------+-----|
- | RH4 | ReSynch  |                         | Clear input buffer      | RH2 |
- |     |          |                         | Send ENQ                |     |
- |-----+----------+-------------------------+-------------------------+-----|
- | RH5 | HdrSetup |                         | Initialize CRC          |     |
- |     |          |                         | Set 30 second timer     | RH6 |
- |-----+----------+-------------------------+-------------------------+-----|
- | RH6 | GetHChar | 30 sec timer expires or |                         |     |
- |     |          | carrier lost            | Report failure          | exit|
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | Character received      | Process character       | RH7 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | 10 seconds with no char | Error, try resync       | RH9 |
- |-----+----------+-------------------------+-------------------------+-----|
- | RH7 | StoHChar | Buffer and CRC filled   | Compare CRC             | RH8 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | More characters needed  | Reset 30 sec timer      | RH6 |
- |-----+----------+-------------------------+-------------------------+-----|
- | RH8 | CheckCRC | CRC matches             | Finish Receive          | RH10|
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | CRC doesn't match       | Handle error            | RH9 |
- |-----+----------+-------------------------+-------------------------+-----|
- | RH9 | CountERR | Less than 10 errors     | Send '?' (0x3f)         | RH2 |
- |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
- |     |          | 10 errors               | Hang up, report failure | exit|
- |-----+----------+-------------------------+-------------------------+-----|
- | RH10| HelloOK  |                         | Clear inbound buffer    | exit|
- |     |          |                         | Send ACK                |     |
- `-----+----------+-------------------------+-------------------------+-----'
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-0007.html b/html/ftsc/fts-0007.html deleted file mode 100755 index 34706a67..00000000 --- a/html/ftsc/fts-0007.html +++ /dev/null @@ -1,1645 +0,0 @@ - - - -An Enhanced FidoNet(r) Technical Standard. - - - - -
-Document: FTS-0007
-Version:  003
-Date:     15-Oct-1990
-Updates:  FTS-0001
-
-
-
-
-                  An Enhanced FidoNet(r) Technical Standard
-                Extending FTS-0001 to include SEAlink protocol
-                    (Including Overdrive and File Restart)
-
-                             October 15, 1990
-
-
-
-
-Status of this document:
-
-    This document specifies an optional standard for the FidoNet community.
-    Implementation of the protocols defined in this document is not mandatory,
-    but all implementations of these protocols are expected to adhere to this
-    standard.  Distribution of this document is subject to the limitations of
-    the copyright notice displayed below.
-
-
-    Copyright 1989-90 by Philip L. Becker.  Portions of this document are
-    copyright 1986-90 by Randy Bush and are incorporated with his consent.
-    All rights reserved.  A right to distribute only without modification and
-    only at no charge is granted.  Under no circumstances is this document to
-    be reproduced or distributed as part of or packaged with any product or
-    other sales transaction for which any fee is charged.  Any and all other
-    reproduction or excerpting requires the explicit written consent of the
-    copyright holders.
-
-
-
-
-    Introduction
-
-    While the basic FTS-0001 protocol has become reasonably standardized, it
-    is technically inferior when used with modem speeds of 2400bps or higher,
-    and results in considerably slower file transfers than more sophisticated
-    protocols under many line and modem configurations.
-
-    Very sophisticated protocols exist to allow absolute maximum efficiency,
-    but these protocols are much more difficult to implement than the basic
-    XMODEM used by FTS-0001.  A need exists for a standardized, easy to
-    implement extension to the FTS-0001 protocol which can gain much better
-    performance.  SEAlink is such an extension.  It is nearly as easy to
-    implement as the FTS-0001 protocol with which it is fully backward
-    compatible.  Despite its ease of implementation, it provides several
-    significant performance advantages. Among these advantages are:
-
-         o  Transparently communicates with strict FTS-0001 implementations.
-
-         o  Transparently communicates with FTS-0001 variants which omit
-            either the MODEM7 file name or the TeLink header block.
-
-         o  Transparently becomes a sliding window XMODEM protocol when
-            communicating with a like implementation.  This sliding window
-            protocol gives significantly improved throughput when there is
-            an end-to-end delay.
-
-         o  Offers a negotiated streaming mode for high speed asymmetrical
-            modems to further enhance throughput for such links.
-
-         o  Offers a negotiated file restart capability which allows an
-            interrupted transfer to restart where it left off, reducing
-            time spent to retransmit the file.
-
-    This document defines the  data structures and communication protocols
-    which a FidoNet SEAlink implementation must provide.  The implementor of
-    FidoNet compatible systems is the intended audience of this document.
-
-    This document has the same overall format and state table descriptions
-    as FTS-0001.  SEAlink is implemented by modifying the following tables:
-
-       Session Layer:   Sender - S1
-       Network Layer:   Batch File Sender - BS0
-       Network Layer:   Batch File Receiver - BR0
-       Data Link Layer: XMODEM/TeLink Sender - XS0
-       Data Link Layer: XMODEM/TeLink Receiver - XR0
-
-
-
-
-                                                                             1
-                              Table of Contents
-
-
-                                                                          Page
-    The purpose of the SEAlink protocol ...................................  3
-
-    How SEAlink negotiates its enhancements ...............................  4
-
-    Basic requirements for a FidoNet Implementation .......................  5
-
-    Levels of Compliance ..................................................  5
-
-    The ISO/OSI Reference Model ...........................................  5
-
-    Data Description Language .............................................  6
-
-    Finite State Machine Notation .........................................  7
-
-    Glossary of variables and terms .......................................  7
-
-    Application layer .....................................................  8
-
-    Presentation layer ....................................................  8
-
-    Session layer protocol ................................................  8
-         Session State Table: Sender (S0) .................................  9
-         Session State Table: Receiver (R0) ............................... 10
-
-    Transport layer ....................................................... 10
-
-    Network layer ......................................................... 11
-         Data Definition: MODEM7 file name ................................ 11
-         Network State Table: Batch File Sender (BS0) ..................... 12
-         Network State Table: Batch File Receiver (BR0) ................... 13
-
-    Data Link Layer ....................................................... 14
-         Data Definition: XMODEM data block (CRC) ......................... 14
-         Data Definition: XMODEM data block (Checksum) .................... 15
-         Data Definition: TeLink header block ............................. 15
-         Data Definition: SEAlink header block ............................ 16
-         Data Definition: SEAlink RESYNC packet ........................... 16
-         DDL Definition: XMODEMBlock, TeLink header ....................... 17
-         DDL Definition: SEAlink header, ACK, NAK, RESYNC block ........... 18
-         Checksum and CRC calculation algorithms .......................... 19
-         Data Link Layer protocol ......................................... 20
-         Data Link State Table: XMODEM/TeLink/SEAlink Sender (XS0) ........ 21
-         Data Link State Table: Transmitter ACK/NAK check (AC0) ........... 22
-         Data Link State Table: XMODEM/TeLink/SEAlink Receiver (XR0) ...... 24
-         Data Link State Table: Send NAK (SN0) ............................ 26
-         Data Link State Table: Send ACK (SA0) ............................ 26
-         Data Link State Table: MODEM7 Filename Sender (MS0) .............. 27
-         Data Link State Table: MODEM7 Filename Receiver (MR0) ............ 27
-
-
-
-
-                                                                            2
-    The purpose of the SEAlink protocol
-
-    The purpose of the SEAlink protocol is to provide a much higher level
-    of capability than the XMODEM protocol provides, while retaining the
-    ease of implementation which has made the XMODEM protocol ubiquitous.
-
-    In order for an extended protocol to function in FidoNet, it has to be
-    fully upward compatible with FTS-0001 mailers, and also those slight
-    variants of FTS-0001 which can communicate well with FTS-0001 mailers.
-    To meet this requirement, any extension to the FTS-0001 protocol has
-    to be capable of transparently negotiating away its extended capabilities
-    and communicate with strict FTS-0001 mailers (and their approved variants)
-    properly and reliably.
-
-    This means that an extended protocol must miminally do the following:
-
-        o  Detect that the other mailer can or cannot support its extensions
-           automatically, and within the framework of a legitimate FTS-0001
-           protocol encounter.
-
-        o  Support mail sessions with or without MODEM7 file names and with
-           or without TeLink headers in either combination.
-
-    To be useful such an extended protocol should also be able to reliably
-    detect when the other mailer can support its extensions so they can
-    be used to maximum benefits.
-
-    The major problems which exist with a standard FidoNet FTS-0001 session
-    result from the use of the XMODEM protocol.  This is a half duplex protocol
-    which forces a line turnaround on every transmitted block.  As a result,
-    any end-to-end delay in the transmission link is directly added to each
-    transmitted data block twice (once for each line turnaround).
-
-    To dramatize how easily XMODEM is impacted by even small line delays, let's
-    examine a 2400bps call on a line with 500ms (1/2 second) delay on each line
-    turnaround.  This is not an uncommon delay time on long distance calls.  A
-    single data block in the XMODEM CRC format contains 133 characters.  This
-    means it will be transmitted in 554ms.  The ACK/NAK response is a single
-    character and will take 4ms.  Thus with no delay (an ideal link) an XMODEM
-    transfer would send 128 data characters in 558ms for an effective data
-    throughput of about 230cps.  With a 500ms line turnaround delay, these same
-    128 data bytes will take 1558ms resulting in a throughput of 82cps.  If
-    faster modem speeds are used, the percentage impact is even greater.
-
-    The solution to this problem is to enhance the XMODEM protocol by adding
-    a "sliding window" capability which allows more than one block to be sent
-    before an acknowledgment is received.  This converts the protocol to a
-    full duplex protocol, and if the "window size" (the number of blocks which
-    may be sent before the sender must wait for an acknowledgment) is larger
-    that the line turnaround delay, then the ideal throughput can be restored
-    even to lines with long turnaround delays.  SEAlink is such a protocol.
-
-    The standard SEAlink window size is 6 blocks, but the state tables given
-    below implement a receiver which will operate correctly with any window
-    size up to 127 blocks.  Thus an implementation which uses a larger window
-    size will be totally compatible with the standard 6 block window versions.
-
-    A second problem with the XMODEM protocol arises when asymmetrical high
-    speed modems are used.  These modems achieve much higher throughput when
-    data is sent in only one direction.  Since they provide error free links,
-    a protocol which does not send any positive acknowledgments, but only
-    reports any bad blocks received will achieve a significantly higher
-
-
-
-                                                                             3
-    throughput than a protocol which is either full duplex or which turns
-    around between each block such as XMODEM or normal SEAlink.  It is for
-    this purpose that SEAlink Overdrive is provided.  It is a streaming version
-    of SEAlink designed to provide much higher throughput on asymmetrical
-    high speed links which provide end-to-end data flow control.
-
-    Finally, there is the annoying problem which occurs when a large data file
-    transfer has nearly completed and a loss of connection occurs.  Normally
-    the entire file must be retransmitted on a new call, resulting in lost
-    time and money.  The SEAlink RESYNC enhancement allows an interrupted
-    file transfer to be resumed at the point it was interrupted thus minimizing
-    the impact of such an interruption.
-
-    How SEAlink Negotiates its enhancements
-
-    SEAlink makes some assumptions about how FTS-0001 mailer implementations
-    react to various stimuli in order to negotiate its enhancements.  For the
-    sender, the test consists of two parts:
-
-    1.  Send a SEAlink header and see if the other end acknowledges it.  In
-        general it will, because most XMODEM implementations will think that
-        the SEAlink header is a "previous block" and ACK and discard it.  If
-        the receiver refuses to accept a SEAlink header block in three tries,
-        then it clearly cannot do SEAlink protocol and the negotiation is over.
-
-    2.  Since the receiver's acknowledgment of the SEAlink header is not a
-        sufficient criteria to determine if the receiver in fact supports
-        SEAlink, the sender dynamically examines the acknowledgments the
-        receiver provides to determine if their format indicates support of
-        SEAlink or not and adjusts its sending techniques accordingly.  This
-        is also the technique used to detect whether the receiver is in fact
-        supporting any extensions (such as SEAlink Overdrive) which have been
-        requested in the header.
-
-    For the receiver, the negotiation occurs during the receipt of the first
-    valid block.
-
-    1.   If the first block received is a valid SEAlink header, then the
-         transmitter supports SEAlink and the receiver can switch to it.  This
-         same header also indicates if the transmitter wants or can support the
-         SEAlink options such as Overdrive and File RESYNC.
-
-     2.  If the first block received is a valid TeLink header, then the
-         transmitter supports a variant of FTS-0001 and SEAlink support may
-         be assumed to be absent.
-
-     3.  If the first block received is an XMODEM data block then SEAlink
-         support may also be assumed to be absent.
-
-    If the receiver gets a SEAlink header, it can then arbitrarily decide
-    which of any requested options it wishes to use.  It may not use an option
-    for which support is not indicated in the sender's SEAlink header block.
-
-    The remainder of this document provides the details for a full SEAlink
-    implementation with Overdrive and RESYNC support.  A glossary of terms and
-    indicators is provided along with a full state table description of the
-    protocol implementation.
-
-
-
-
-
-
-
-
-                                                                             4
-    This document follows the format of FTS-0001 to allow ease of
-    comparison of the two protocols.  This document could not have been
-    generated without the tremendous efforts of those whose work resulted in
-    FTS-0001.  FidoNet owes a great debt to those efforts.  The following
-    introduction is reprinted from FTS-0001.
-
-    The layered metaphor of the ISO Open Systems Interface reference model
-    has been used to view FidoNet from a standard perspective.  As with most
-    prospective ISO/OSI descriptions, FidoNet does not always make this easy.
-
-
-   1. Basic Requirements for a FidoNet Implementation
-
-      Compatibility is a set of abilities which, when taken as a whole, make
-      it safe to list a net or node in the IFNA nodelist.  In other words,
-      if another node should attempt contact, does it have a reasonable
-      chance of successful communication?  This is a social obligation, as
-      the calling system pays money for the attempt.  Conversely, an
-      implementation should be able to successfully contact other systems,
-      as life is not a one-way street.
-
-      A FidoNet implementation must be able to call other nodes and transfer
-      messages and files in both directions.  This includes pickup and poll.
-
-      A FidoNet implementation must be able to accept calls from other nodes
-      and transfer messages and files in both directions.  This includes
-      pickup.
-
-      A FidoNet implementation must be able to receive and process the IFNA
-      format nodelist, and transfer nodelists to other nodes.  A companion
-      document, FTS-0005, defines the IFNA format nodelist and how to
-      interpret and process it.
-
-      A FidoNet implementation must route messages which do not have files
-      attached through net hosts as shown in an IFNA format nodelist.
-
-
-   2. Levels of Compliance
-
-      This documents represents an extended FidoNet implementation.  It
-      defines a well tested extension which is optional but provides
-      sufficient additional function that implementors should seriously
-      consider it.  SEAdog(tm), from System Enhancement Associates,
-      is the inspiration for this extended FidoNet implementation.
-      System Enhancement Associates is the creator of the SEAlink protocol.
-
-
-   3. The ISO/OSI Reference Model (cribbed from "Protocol Verification via
-      Executable Logic Specifications", D. P. Sidhu, in Rudin & West)
-
-      In the ISO/OSI model, a distributed system consists of entities that
-      communicate with each other according to a set of rules called a
-      protocol.   The model is layered, and there are entities associated
-      with each layer of the model which provide services to higher layers
-      by exchanging information with their peer entities using the services
-      of lower layers.  The only actual physical communication between two
-      systems is at the lowest level.
-
-
-
-
-
-
-
-
-                                                                             5
-      Several techniques have been used in the specification of such
-      protocols.  A common ingredient in all techniques is the notion of the
-      extended finite state automata or machine.  Extensions include the
-      addition of state variables for the storing of state information about
-      the protocol.  The state of an automaton can change as a result of
-      one of the following events:
-
-      o Request from an upper network layer for service
-
-      o Response to the upper layer
-
-      o Request to the lower network layer to perform a service
-
-      o Response from the lower layer
-
-      o Interaction with the system and environment in which the protocol is
-        implemented (e.g. timeouts, host operating system aborts, ...)
-
-      A protocol specification, in a large part, consists of specifying
-      state changes in automata which model protocol entities and in
-      describing the data which they exchange.
-
-      For historical reasons, the term packet is used in FidoNet to
-      represent a bundle of messages, as opposed to the more common use as a
-      unit of communication, which is known as a block in FidoNet.
-
-
-   4. Data Description
-
-      A language specific notation was avoided.  Please help stamp out
-      environmental dependencies.   Don't panic, there are rectangular record
-      layouts too.  The following defines the data description language used.
-
-      (* non-terminals *)
-      UpperCaseName - to be defined further on
-
-      (* literals *)
-      "ABC"         - ASCII character string, no termination implied
-      nnH           - byte in hexadecimal
-
-      (* terminals *)
-      someName      - 16-bit integer, low order byte first (8080 style)
-      someName[n]   - field of n bytes
-      someName[.n]  - field of n bits
-      someName(n)   - Null terminated string allocated n chars (incl Null)
-      someName{max} - Null terminated string of up to max chars (incl Null)
-      someName<max> - String of up to max chars, NOT null terminated
-
-      (* punctuation *)
-      a b           - one 'a' followed by one 'b'
-      ( a | b )     - either 'a' or 'b', but not both
-      { a }         - zero or more 'a's
-      [ b ]         - zero or one 'b'
-      (* comment *) - ignored
-
-      (* predeclared constant *)
-      Null          = 00H
-
-
-
-
-
-
-
-
-                                                                             6
- 5. Finite State Machine Notation
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | fnn*|          |                         |                         |     |
-    `-----+----------+-------------------------+-------------------------+-----'
-
-    State #      - Number of this state (e.g. R13).
-                   f  - FSM initial (Window, Sender, Receiver, ...)
-                   nn - state number
-                   *  - state which represents a lower level protocol  which
-                        is represented by yet another automation.
-
-    State Name   - Descriptive name of this state.
-
-    Predicate(s) - Conditions which terminate the state.  If predicates are
-                   non-exclusive, consider them ordered.
-
-    Action(s)    - Action(s) corresponding to predicate(s)
-
-    Next State   - Subsequent state corresponding to predicate(s)
-
-    Ideally, there should be a supporting section for each state which
-    should give a prose description of the state, its predicates, actions,
-    etc.  So much for ideals.  The following is a list of all of the terms
-    and variables used in the following state machine descriptions:
-
-
-                     Glossary of variables and terms
-
-    SEAlink - Flag indicating SEAlink or XMODEM mode
-
-    SLO - Flag indicating overdrive if in SEAlink mode
-
-    RESYNC - Flag indicating whether transmitting end can honor RESYNC
-             file positioning requests or only NAKs
-
-    MACFLOW - Flag indicating whether the sender supports the Macintosh flow
-              control option.  This is an optional feature used by TABBY
-              because the Macintosh serial port does not support RTS/CTS.
-
-    CRC - Flag indicating whether block check is done using CRC or Checksum
-
-    T1 and T2 - Timeout Timers which run asynchronously with the code
-
-    WINDOW - Number of unacknowledged blocks which may be transmitted
-
-    SendBLK - Next 128 byte block number in file to send.  May not occur in
-              sequential order, so file positioning may be necessary when
-              it is time to send this block
-
-    ACKBLK - Highest block number in file which has been acknowledged by
-             the receiver as received without error
-
-    Last Blk - Block number of last 128 byte block (or partial block) in the
-               file being sent.
-
-    NumNAK - Number of NAKs received since last ACK
-
-    ACKs Rcvd - Number of ACKs received since the start of this file send
-
-
-
-                                                                             7
-                     Glossary of variables and terms (cont.)
-
-    ACKST - State of ACK/NAK machine during auto-detect of SEAlink or XMODEM
-            style ACK/NAK block receipt
-
-    RESYNC BLK# - Block number in file requested by a received RESYNC packet
-
-    ARBLK8 - Block # (0-255) received in a SEAlink style ACK/NAK packet
-
-    ARBLK - Block # in file (calculated from ARBLK8) which is the actual
-            block being referenced in the SEAlink ACK/NAK packet
-
-    blocknum - Block # (0-255) sent in a SEAlink style ACK/NAK packet
-
-    WriteBLK - Block # in file to write next correctly received data block.
-               Note: Block 1 is the first byte of the file.
-
-    CHR - Temp holding variable for received character during send operation
-
-
- B. Application Layer : the System from the User's View
-
-    This is unchanged from FTS-0001.
-
-
- C. Presentation Layer : the User from the System's View
-
-    This is unchanged from FTS-0001.
-
-
- D. Session Layer Protocol : Connecting to Another FidoNet Machine
-
-    A session is a connection between two FidoNet machines.  It is currently
-    assumed to be over the DDD telephone network via modems.  The calling
-    machine starts out as the sender and the called machine as the receiver.
-    The pickup feature is described by the sender and receiver changing
-    roles midway through the session, after the sender has transferred the
-    message packet and any attached files.  Due to the lack of security in
-    the pickup protocol (danger of pickup by a fake node), extensions to the
-    basic Session protocol have been developed.  This document describes only
-    the minimum Session Layer protocol (as in FTS-0001).
-
-    Once a connection has been established, each system should ensure that
-    the physical connection remains throughout the session.  For physical
-    layers implemented through modems, this means monitoring the carrier
-    detect signal, and terminating the session if it is lost.
-
-    Error detection at the physical layer should be monitored for both sent
-    and received characters.  Parity, framing, and other physical errors
-    should be detected.
-
-    The only change to the Session Layer state tables from FTS-0001 is in the
-    Sender state "S1", Predicate "1" (S1.1) entry.
-
-
-
-                                                                             8
-    Sender
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | S0  | SendInit |                         | dial modem              | S1  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S1  | WaitCxD  |1| carrier detected      | delay 1-5 seconds       | S2  |
-    |     |  (*1)    | |                       | Set SLO if > 2400bps,   |     |
-    |     |          | |                       | Reset SLO if <= 2400bps |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| busy, etc.            | report no connection    | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| voice                 | report no carrier       | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| carrier not detected  | report no connection    | exit|
-    |     |          | | within 60 seconds     |                         |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S2  | WhackCRs |1| over 30 seconds       | report no response <cr> | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| ?? <cr>s received     | delay 1 sec             | S3  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| <cr>s not received    | send <cr> <sp> <cr> <sp>| S2  |
-    |     |          | |                       |   delay ??? secs        |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S3  | WaitClear|1| no input for 0.5 secs | send TSYNCH = AEH       | S4  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| over 60 seconds       | hang up, report garbage | exit|
-    |     |          | | and line not clear    |                         |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S4* | SendMail |                         | (XMODEM send packet XS0)| S5  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S5  | CheckMail|1| XMODEM successful     | (Fido registers success)| S6  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| XMODEM fail or timeout| hang up, report mail bad| exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S6* | SendFiles|                         | (BATCH send files BS0)  | S7  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S7  | CheckFile|1| BATCH send successful |                         | S8  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| BATCH send failed     | hang up, rept files fail| exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S8  | TryPickup|1| wish to pickup        | note send ok            | R2* |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| no desire to pickup   | delay 5 secs            | exit|
-    |     |          | |                       |   hang up, rept send ok |     |
-    `-----+----------+-+-----------------------+-------------------------+-----'
-    Although the above shows the sender emitting only one TSYNCH, it is
-    recommended that a timeout of 5-20 seconds should initiate another TSYNCH.
-    The receiver should tolerate multiple TSYNCHs.
-
-    *1 - The action for (S1.1) is the only change from the corresponding
-         FTS-0001 state table.
-
-
-
-                                                                             9
-    Receiver
-
-    The receiving FSM is given an external timer, the expiration of which
-    will cause termination with a result of 'no calls' (R0.2).
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R0  | WaitCxD  |1| carrier detected      |                         | R1  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| external timer expires| report no calls         | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R1  | WaitBaud |1| baud rate detected    | send signon with <cr>s  | R2  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| no detect in ?? secs  | hang up, report no baud | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R2  | WaitTsync|1| TSYNCH received       | ignore input not TSYNCH | R3  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| 60 seconds timeout    | hang up, report not Fido| exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R3* | RecMail  |                         | (XMODEM rec packet XR0) | R4  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R4  | XRecEnd  |1| XMODEM successful     | delay 1 second          | R5  |
-    |     |          | |                       |   flush input           |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| XMODEM failed         | hang up, rept mail fail | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R5* | RecFiles |                         | (BATCH rec files BR0)   | R6  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R6  | ChkFiles |1| BATCH recv successful | delay 2 secs            | R7  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| BATCH recv failed     | hang up, report bad file| exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R7  | AllowPkup|1| have pickup for sender| receiver becomes sender | S3* |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| nothing to pickup     | hang up, rept recv ok   | exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-    There is no change in the Session Layer Receiver state table from FTS-0001.
-
-
- E. Transport Layer : ?????
-
-    This is unchanged from FTS-0001.
-
-
-
-                                                                            10
- F. Network Layer : the Network's View of the System, Routing and Packets
-
-   1. Network Layer Data Definition : the Packet Header
-
-      This is unchanged from FTS-0001.
-
-
-   2. Network Layer Data Description : a File with Attributes
-
-      The BATCH protocol uses the MODEM7 filename and/or SEAlink/TeLink/XMODEM
-      file transfer protocols to transfer the file with attributes.
-
-      When a file is transferred via FidoNet, an attempt is made to also
-      pass the operating system's attributes for the file such as length,
-      modification date, etc.  FidoNet does this via a special prefix block
-      to the XMODEM file transfer using a protocol known as TeLink.  As the
-      TeLink protocol relies on a modification to the XMODEM file transfer
-      protocol, it is documented at the data link layer level.  Optionally,
-      if both sender and receiver implement the SEAlink extension, file
-      information is passed using the SEAlink header block which also
-      contains feature negotiation information.
-
-      The MODEM7 file name is redundant if there is also a TeLink or SEAlink
-      block, in which case the name may be taken from either or both.  In this
-      extended implementation, the MODEM7 file name is never required.  It
-      is sent, however, if it appears that the other node is using a strict
-      FTS-0001 implementation.  This implementation will adapt to an FTS-0001
-      variant which only sends the TeLink header without the MODEM7 filename
-      also so that it is compatible with all know variants of FTS-0001 which
-      are currently in the FidoNet network.
-
-
-                          FileName as Sent by MODEM7
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |                   fileName                    |
-              ~                   8  bytes                    ~
-              |           left adjusted blank filled          |
-              +-----------------------------------------------+
-        8   8 |                    fileExt                    |
-              ~                    3  bytes                   ~
-              |           left adjusted blank filled          |
-              `-----------------------------------------------'
-
-
-                                                                            11
- 3. Network Layer Protocol : BATCH File Finite State Machines
-
-    BATCH File Sender
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BS0 | MoreFiles|1| more files to send    |                         | BS1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| no more files to send |                         | BS4 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BS1 | WaitType |1| rec NAK               | (MODEM7 FName send MS0) | BS2 |
-    |     |    (*1)  +-+-----------------------+-------------------------+-----+
-    |     |          |2| rec 'C'               | (SEAlink send file XS0) | BS3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| rec other char        | eat character           | BS1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| > 20 sec in BS1       | report name send bad    | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BS2 | CheckFNm |1| MODEM7 Filename ok    | (TeLink send file XS0T) | BS3 |
-    |     |    (*2)  +-+-----------------------+-------------------------+-----+
-    |     |          |2| MODEM7 Filename bad   | report name send bad    | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BS3 | CheckFile|1| File send ok          |                         | BS0 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| File send bad         | report file send bad    | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BS4 | EndSend  |1| rec NAK or 'C'        | send EOT, report send ok| exit|
-    |     |    (*3)  +-+-----------------------+-------------------------+-----+
-    |     |          |2| 10 secs no NAK or 'C' | send EOT, report no NAK | exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-    *1 - Note: Filenames must be upper case ASCII.  The data link layer uses
-         lower case "u" as a control character during MODEM7 name transmission.
-
-    *2 - Note: SEAdog (through version 4.51b) does not possess a state "XS0T".
-         It therefore calls XS0 from state BS2, resulting in a MODEM7 file name
-         being sent with no TeLink header on batch file transmissions when it
-         is not in SEAlink mode.
-
-    *3 - When no files remain, the sender responds to the receiver's NAK with
-         an EOT.  The EOT is not ACK/NAKed by the receiver.
-
-
-
-                                                                            12
-   BATCH File Receiver
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | BR0 | TestSL   |                         | Send 'C',               | BR1 |
-    |     |          |                         |   Set T1 to 10 sec      |     |
-    |     |          |                         |   Set T2 to 120 sec     |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BR1 | CheckSL  |1| > 2 sec with no data  | Send 'C'                | BR1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Timer T2 expired      | (MODEM7 FName recv MR0) | BR2 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Character Waiting     | "Peek" char to CHR (*1) | BR4 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| Timer T1 expired      | (MODEM7 FName recv MR0) | BR2 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BR2 | CheckFNm |1| no more files         | report files recd ok    | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Filename ok           | (Rcv file Telink XR0)   | BR3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Filename bad          | report name recv bad    | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BR3 | CheckFile|1| File received ok      |                         | BR0 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| File received bad     | report file recv bad    | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | BR4 | FindType |1| CHR = NUL             | eat character,          | BR1 |
-    |     |          | |                       |   Reset T1 to 20 secs   |     |
-    |     |   (*2)   +-+-----------------------+-------------------------+-----+
-    |     |          |2| CHR = SOH             | (Rcv File SEAlink XR0B) | BR3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| CHR = SYN             | (Rcv File Telink XR0B)  | BR3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| CHR = EOT or          | eat character,          | exit|
-    |     |          | | CHR = SUB             |   report files recd ok  |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| CHR = Other char      | eat character           | BR1 |
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-    *1 - "Peek" a character means to place it in CHR but leave it in the input
-         buffer so the next read operation will re-read it.
-
-    *2 - "Eat" a character means to remove it from the input buffer.
-
-
-
-
-                                                                            13
- G. Data Link Layer : Error-Free Data Transfer
-
-   1. Data Link Layer Data Definition : XMODEM/TeLink/SEAlink Blocks
-
-      XMODEM transfers are in blocks of 128 uninterpreted data bytes
-      preceded by a three byte header and followed by either a one byte
-      checksum or a two byte crc remainder.  XMODEM makes no provision  for
-      data streams which are not an integral number of blocks long.
-      Therefore, the sender pads streams whose length is not a multiple of
-      128 bytes with the end-of-file character (^Z for MS-DOS), and uses some
-      other means to convey the true data length to the receiver (e.g.
-      SEAlink or TeLink file info header block).
-
-      Data blocks contain sequence numbers so the receiver can ensure it has
-      the correct block.  Data block numbers are sequential unsigned eight bit
-      integers beginning with 01H and wrapping to 00H.  A TeLink or SEAlink
-      header block is given sequence number 00H.
-
-      For files which are attached to the mail packet (but not the mail packet
-      itself), if the sending system is aware of the file attributes as they
-      are known to the operating system, then the first block of the XMODEM
-      transfer may be a special TeLink block to transfer that information.
-      This block differs in that the first byte is a SYN character as
-      opposed to an SOH, and it is always sent checksum as opposed to CRC.
-      Should the receiver be unwilling to handle such information, after four
-      NAKs (or "C"s), the sender skips this special block and goes on to the
-      data itself.
-
-      In this extended protocol the TeLink header block may be replaced by
-      the SEAlink header block which conveys protocol negotiation information
-      in addition to the file attributes if both nodes implement SEAlink.
-
-
-
-                        XMODEM Data Block (CRC mode)
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |        SOH  -  Start Of Header -  01H         |
-              +-----------------------------------------------+
-        1   1 |                 BlockNumber                   |
-              +-----------------------------------------------+
-        2   2 |               BlockComplement                 |
-              +-----------------------------------------------+
-        3   3 |                128 bytes  of                  |
-              ~                uninterpreted                  ~
-              |                    data                       |
-              +-----------------------------------------------+
-      131  83 |             CRC high order byte               |
-              +-----------------------------------------------+
-      132  84 |             CRC  low order byte               |
-              `-----------------------------------------------'
-
-
-                                                                            14
-                      XMODEM Data Block (Checksum mode)
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |        SOH  -  Start Of Header -  01H         |
-              +-----------------------------------------------+
-        1   1 |                 BlockNumber                   |
-              +-----------------------------------------------+
-        2   2 |               BlockComplement                 |
-              +-----------------------------------------------+
-        3   3 |                128 bytes  of                  |
-              ~                uninterpreted                  ~
-              |                    data                       |
-              +-----------------------------------------------+
-      131  83 |                Checksum byte                  |
-              `-----------------------------------------------'
-
-
-                       TeLink File Descriptor Block
-       Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |       SYN  -  File Info Header -  16H         |
-              +-----------------------------------------------+
-        1   1 |                     00H                       |
-              +-----------------------------------------------+
-        2   2 |                     FFH                       |  dec  hex
-              +-----------------------------------------------+
-        3   3 |     File Length, least significant byte       |  0    0
-              +-----------------------------------------------+
-        4   4 | File Length, second to least significant byte |  1    1
-              +-----------------------------------------------+
-        5   5 |  File Length, second to most significant byte |  2    2
-              +-----------------------------------------------+
-        6   6 |      File Length, most significant byte       |  3    3
-              +-----------------------------------------------+
-        7   7 |            Creation Time of File              |  4    4
-              |                "DOS Format"                   |
-              +-----------------------------------------------+
-        9   9 |            Creation Date of File              |  6    6
-              |                "DOS Format"                   |
-              +-----------------------------------------------+
-       11   B |                 File  Name                    |  8    8
-              ~                  16 chars                     ~
-              |        left justified  blank filled           |
-              +-----------------------------------------------+
-       27  1B |                    00H                        | 24   18
-              +-----------------------------------------------+
-       28  1C |            Sending Program Name               | 25   19
-              ~                  16 chars                     ~
-              |         left justified  Null filled           |
-              +-----------------------------------------------+
-       44  2B |            01H (for CRC) or 00H               | 41   29
-              +-----------------------------------------------+
-       45  2C |                    fill                       | 42   2A
-              ~                  86 bytes                     ~
-              |                  all zero                     |
-              +-----------------------------------------------+
-      131  83 |                Checksum byte                  |
-              `-----------------------------------------------'
-
-
-
-
-
-                                                                            15
-      Offset           SEAink File Descriptor Block
-      dec hex
-              .-----------------------------------------------.
-        0   0 |       SOH  -  Start of Header -   01H         |
-              +-----------------------------------------------+
-        1   1 |                     00H                       |
-              +-----------------------------------------------+
-        2   2 |                     FFH                       |  dec  hex
-              +-----------------------------------------------+
-        3   3 |         File Length, (4 bytes, LSB first)     |  0    0
-              +-----------------------------------------------+
-        7   7 |            Creation Date/Time of File         |  4    4
-              |   (4 bytes, LSB first, seconds since 1979)    |
-              +-----------------------------------------------+
-       11   B |                 File  Name                    |  8    8
-              ~                  17 chars                     ~
-              |        left justified   Null filled           |
-              +-----------------------------------------------+
-       28  1C |            Sending Program Name               | 25   19
-              ~                  15 chars                     ~
-              |         left justified  Null filled           |
-              +-----------------------------------------------+
-       43  2B |            > 0 if SLO Requested               | 40   28
-              +-----------------------------------------------+
-       44  2C |           > 0 if RESYNC Supported             | 41   29
-              +-----------------------------------------------+
-       45  2D |           > 0 if MACFLOW Supported            | 42   2A
-              +-----------------------------------------------+
-       46  2E |                    fill                       | 43   2B
-              ~                  85 bytes                     ~
-              |                  all zero                     |
-              +-----------------------------------------------+
-      131  83 |            CRC high order byte                |
-              +-----------------------------------------------+
-      132  84 |            CRC  low order byte                |
-              `-----------------------------------------------'
-  
-
-      Offset                SEAlink RESYNC packet
-      dec hex
-              .-----------------------------------------------.
-        0   0 |       SYN - Start of RESYNC packet - 16H      |
-              +-----------------------------------------------+
-        1   1 |     ASCII Decimal 128 byte block number in    |
-              ~     file to restart sending.  (No leading     ~
-        n     |     or trailing blanks, MSD first).           |
-              +-----------------------------------------------+
-        n+1   |       ETX -  End of RESYNC packet  - 03H      |
-              +-----------------------------------------------+
-        n+2   |     (*1)     CRC  low order byte              |
-              +-----------------------------------------------+
-        n+3   |     (*1)     CRC high order byte              |
-              `-----------------------------------------------'
-
-              *1 - CRC does not include the SYN or ETX and is
-                   in the reverse byte order from the CRC in a
-                   normal XMODEM data packet.  The following is
-                   a sample RESYNC packet for file block 27 (1BH).
-
-                     SYN   '2'   '7'   ETX  CRCLO CRCHI 
-                   .-----+-----+-----+-----+-----+-----.
-                   | 16H | 32H | 37H | 03H | 43H | 25H |
-                   `-----+-----+-----+-----+-----+-----'
-
-
-                                                                            16
-    Data Description language definitions of block types:
-
-      XMODEMData   =   XMODEMBlock    (* block of data with hdr and trailer *)
-                     | SEALinkBlock   (* SEALink File Descriptor Block *)
-                     | TeLinkBlock    (* TeLink File Descriptor Block *)
-                     | ReSyncBlock    (* SEAlink RESYNC request packet *)
-                     | ACK            (* acknowledge data received ok *)
-                     | NAK            (* negative ACK & poll 1st block *)
-                     | SEAlinkACK     (* acknowledge data received ok *)
-                     | SEAlinkNAK     (* negative ACK & poll 1st block *)
-                     | EOT            (* end of xfer, after last block *)
-                     | "C"            (* 43H *)
-
-
-      XMODEMBlock  = SOH              (* Start of Header, XMODEM Block *)
-                     blockNumber[1]   (* sequence, i'=mod( i+1, 256 ) *)
-                     blockCompl[1]    (* one's complement of blockNumber *)
-                     data[128]        (* uninterpreted user data block *)
-                     (CRC | Checksum) (* error detect/correction code *)
-
-
-      TeLinkBlock  = SYN              (* File Info Header *)
-                     00H              (* block no, must be first block *)
-                     FFH              (* one's complement of block no *)
-                     fileLength[4]    (* length of data in bytes *)
-                (*2) CreationTime[2]  (* time file last modified or zero *)
-                (*2) CreationDate[2]  (* date file last modified or zero *)
-                     fileName(16)     (* name of file, not vol or dir *)
-                     00H              (* header version number *)
-                     sendingProg(16)  (* name of program on send side *)
-                (*1) crcMode[1]       (* 01H for CRC 00H for Checksum *)
-                     fill[87]         (* zeroed *)
-                     Checksum         (* error detect/correction code *)
-
-    *1 -  Note that the crcMode is always set to 01H in current implementations
-          as all TeLink/XMODEM implementations use the CRC method.  Therefore,
-          it is always set to 01H by the sender, and is ignored by the receiver.
-
-    *2 -  CreationDate and CreationTime are MS-DOS format as follows:
-
-      CreationDate = year[.7]         (* 7 bits, years since 1980, 0-127  *)
-                     month[.4]        (* 4 bits, month of year, 1-12 *)
-                     day[.5]          (* 5 bits, day of month, 1-31 *)
-
-      CreationTime = hour[.5]         (* 5 bits, hour of day, 0-23 *)
-                     minute[.6]       (* 6 bits, minute of hour, 0-60 *)
-                     biSeconds[.2]    (* 6 bits, seconds/2, 0-29 *)
-
-
-                                                                            17
-    Data Description Language definition of the block types added by this
-    extended protocol specification:
-
-     SEALinkBlock  = SOH              (* File Info Header *)
-                     00H              (* block no, must be first block *)
-                     FFH              (* one's complement of block no *)
-                     fileLength[4]    (* length of data in bytes *)
-              (*1)   Creation[4]      (* Seconds since 1979 file last chgd *)
-                     fileName(17)     (* name of file, not vol or dir *)
-                     sendingProg(15)  (* name of program on send side *)
-                     SLO[1]           (* 01H for Overdrive supported *)
-                     RESYNC[1]        (* 01H for file Restart supported *)
-                     MACFLOW[1]       (* 01H for Macintosh flow supported *)
-                     fill[85]         (* zeroed *)
-                     CRC              (* error detect/correction code *)
-
-    *1 - Creation is a long integer number of seconds since January 1, 1979.
-
-     SEAlinkACK    = ACK              (* indicator data block received ok *)
-                     blockNumber[1]   (* sequence, i'=mod( i+1, 256 ) *)
-                     blockCompl[1]    (* one's complement of blockNumber *)
-
-     SEAlinkNAK    = NAK              (* indicator block not received ok *)
-                     blockNumber[1]   (* sequence, i'=mod( i+1, 256 ) *)
-                     blockCompl[1]    (* one's complement of blockNumber *)
-
-     ReSyncBlock   = SYN              (* File Restart Position *)
-                (*1) RestartBlock<20> (* ASCII decimal file block # *)
-                     ETX              (* End of block number text *)
-                     CRC(rev order)   (* error detection code *)
-
-     *1 - RestartBlock is a text ASCII version of the decimal block number
-          in the file desired.  Note:  The first block of the file is block 1.
-
-
-    Definitions of Single byte Character values used in protocol:
-
-      ACK          = 06H              (* acknowledge data received ok *)
-      NAK          = 15H              (* negative ACK & poll 1st block *)
-      SOH          = 01H              (* start of header, begins block *)
-      SYN          = 16H              (* start of TeLink file info blk *)
-      EOT          = 04H              (* end of xfer, after last block *)
-      ETX          = 03H              (* end of RESYNC request data field*)
-
-
-                                                                            18
-    Block Verification calculated values used by this protocol:
-
-      CRC          = crc[2]           (* CCITT Cyclic Redundancy Check *)
-
-      Checksum     = checksum[1]      (* low 8 bits of sum of data bytes
-                                         using unsigned 8 bit arithmetic *)
-
-    Calculating Checksum
-    --------------------
-
-    For blocks which use a checksum to do error detection, the checksum is
-    calculated by initializing an accumulator to zero and doing successive
-    addition of each character in the data field.  Carry is discarded on
-    each addition.  The resulting 8 bit value is the checksum.
-
-    Calculating CRC
-    ---------------
-
-    For blocks which use CRC to do error detection, the CRC is calculated
-    using the CCITT V.41 generator polynomial.  An accumulator is initialized
-    to zero, and then each character of the data field is processed by the
-    CRC generator polynomial.  This process can be quite complex to explain,
-    but is not so complex in practice.  The following CRC routine is
-    given here as an aid to understanding the CRC generation process.
-
-    8086 assembler routine to implement CCITT V.41 CRC algorithm
-    ;---------------------------------------------------------------+
-    ;       CRCUPD - Update CRC value from character in AL          |
-    ;                                                               |
-    ;  CRC is calculated using the CCITT V.41 generator polynomial. |
-    ;    That polynomial is: X^16 + X^12 + X^5 + 1 (X^0)            |
-    ;                                                               |
-    ;  As an aid to understanding, remember that XOR is bitwise     |
-    ;    addition without carry.                                    |
-    ;---------------------------------------------------------------+
-    CRCVAL  DW      0                   ;16 bit CRC accumulator
-    ;
-    CRCUPD: PUSH    AX                  ;All registers preserved
-            PUSH    CX
-            PUSH    DX
-            MOV     DX,[CRCVAL]
-            XOR     DH,AL               ;init X^16 term
-            XOR     DL,DL
-            MOV     CX,8
-    CRCUP1: SHL     DX,1
-            JNC     CRCUP2
-            XOR     DX,1021h            ;X^12 + X^5 + 1
-    CRCUP2: LOOP    CRCUP1
-            XOR     DH,BYTE PTR[CRCVAL] ;finish X^16 term
-            MOV     [CRCVAL],DX         ;update CRC accumulator
-            POP     DX
-            POP     CX
-            POP     AX
-            RET
-
-
-                                                                            19
- 2. Data Link Layer Protocol : XMODEM/TeLink/SEAlink Finite State Machines
-
-    The protocol is receiver driven, the receiver polling the sender for
-    each block.  If the receiver polls for the first block using a "C"
-    (43H) as  the poll character, it would prefer to have the CRC-CCITT V.41
-    polynomial remainder error detection code at the end of each block as
-    opposed to a one byte unsigned checksum.  The sender will respond to
-    the "C" poll if it can  comply. If the sender chooses checksum as
-    opposed to CRC, it waits for the receiver to poll with  NAK (15H).
-    Should the checksum method be preferable to the receiver, it polls
-    with NAK rather than "C".
-
-    The sender returns an EOT instead of a data block when no data remain.
-
-    With this extended implementation, the sender and the receiver may send
-    blocks or ACK/NAK responses while there is data being received, once the
-    SEAlink protocol has been negotiated.  This full duplex operation allows
-    the throughput gains of a sliding window protocol.  When SEAlink is not
-    set the window size of 1 prohibits data being sent at the same time and
-    restores the attributes of a standard XMODEM protocol.
-
-    ------------------
-    In this extended protocol, the FTS-0001 single state table
-    "XMODEM Sender" is replaced by two state tables.
-
-    The top level table is equivalent to the FTS-0001 XMODEM Sender table.
-    It in turn calls the new state table named "Transmitter ACK/NAK Check"
-    which implements the full duplex adaptive SEAlink/XMODEM dynamic switching
-    along with the Overdrive and file Restart sending features of the extended
-    protocol.
-
-    -----------------
-    In this extended protocol, the FTS-0001 single state table
-    "XMODEM Receiver" is replaced by three state tables.
-
-    The top level table is equivalent to the FTS-0001 XMODEM Receiver table.
-    It in turn calls the two new state tables named "Send NAK" and "Send ACK"
-    which implement the full duplex adaptive SEAlink/TeLink/XMODEM dynamic
-    switching along with the Overdrive and file Restart receiving features of
-    the extended protocol.
-
-
-    Caution!!!!
-    -----------
-    Many current implementations keep file block numbers as 16 bit numbers.
-    This limits the max file size to either 4 megabytes (if number is signed)
-    or 8 megabytes (if number is unsigned).  To handle files up to the maximum
-    size DOS allows (4 gigabytes) at least 25 bits plus sign are required for
-    these numbers.  Good practice is to make file block numbers 32 bit values.
-
-
-                                                                            20
-    XMODEM/TeLink/SEAlink - Sender
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | XS0 | XmtStart |  Normal Entry Point     | reset SEAlink flag,     | XS1 |
-    |     |          |  for file send          |   SendBLK=1, ACKST=0,   |     |
-    |     |          |                         |   ACKBLK= -1, WINDOW=1, |     |
-    |     |          |                         |   ACKs Rcvd=0,          |     |
-    |     |          |                         |   NumNAK=0,             |     |
-    |     |          |                         |   T1=30 seconds,        |     |
-    |     |          |                    (*1) |   Build SEAlink hdr blk |     |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | XS0T| XmTeStrt |  Alternate entry from   | reset SEAlink flag,     | XS1 |
-    |     |          |  Batch Send if TeLink   |   SendBLK=1, ACKST=0,   |     |
-    |     |          |  mode send required     |   ACKBLK= -1, WINDOW=1, |     |
-    |     |          |                         |   ACKs Rcvd=0,          |     |
-    |     |          |                         |   NumNAK=0,             |     |
-    |     |          |                         |   T1=30 seconds,        |     |
-    |     |          |                         |   Build TeLink hdr blk  |     |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | XS1 | CheckACK |                         | (Check ACK/NAK AC0)     | XS2 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | XS2 | SendBlk  |1| NumNAK > 4 &          | If header = SEAlink     | XS0T|
-    |     |   (*2)   | |   SendBLK = 0         +-------------------------+-----+
-    |     |          | |                       | If header = TeLink,     | XS2 |
-    |     |          | |                       |   NumNAK = 0,           |     |
-    |     |          | |                       |   Incr ACKBLK,          |     |
-    |     |          | |                       |   Incr SendBLK          |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| NumNAK > 10           | report too many errors  | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Timer T1 expired      | report fatal timeout    | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| SendBLK > Last Blk+1  |                         | XS3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| SendBLK >ACKBLK+Window|                         | XS1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |6| SendBLK = Last Blk+1  | Send EOT, Incr SendBLK, | XS1 |
-    |     |          | |                       |   Set T1 to 30 seconds  |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |7| SLO set & SEAlink set | Send SendBLK, (*3)      | XS1 |
-    |     |          | |                       |   ACKBLK = SendBLK,     |     |
-    |     |          | |                       |   Incr SendBLK,         |     |
-    |     |          | |                       |   Set T1 to 60 seconds  |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |8| SLO reset or          | Send SendBLK, (*3)      | XS1 |
-    |     |          | |     SEAlink reset     |   Incr SendBLK,         |     |
-    |     |          | |                       |   Set T1 to 30 seconds  |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | XS3 | WaitEnd  |1| ACKBLK < Last Blk+1   |                         | XS1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| ACKBLK = Last Blk+1   | report send success     | exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-    *1 - Build SEAlink Header block with RESYNC set.  Set SLO if line speed >
-         2400 bps, reset SLO otherwise.
-
-    *2 - State (XS2.1) allows the receiver to refuse one or both header blocks.
-
-    *3 - If SendBLK = 0, then send the SEAlink (or TeLink) header block.
-         If SendBLK > 0, send the corresponding 128 byte file data block where
-                         block #1 begins with the first byte of the file.
-
-                                                                            21
-    XMODEM/TeLink/SEAlink - Transmitter ACK/NAK Check
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC0 | ChkRcvd  |1| No character waiting  |                         | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Character waiting     | Read character to CHR   | AC1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC1 | SLCheck  |1| ACKST > 2             |                         | AC2 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| ACKST <=2             |                         | AC6 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC2 | SLVerify |1| ARBLK8 = 1's comp(CHR)| ARBLK = SendBLK -       | AC3 |
-    |     |          | |                       | ((SendBLK-ARBLK8)&0FFh) |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| ARBLK8 # 1's comp(CHR)| Reset SEAlink flag,     | AC6 |
-    |     |          | |                       |   WINDOW=1,             |     |
-    |     |          | |                       |   ACKST=0               |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC3 | SLACKNAK |1| ARBLK not valid (*1)  |                         | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| ACKST = 3             | Set SEALink flag,       | AC5 |
-    |     |     (*2) | |                       |   WINDOW = 6,           |     |
-    |     |          | |                       |   ACKBLK = ARBLK,       |     |
-    |     |          | |                       |   Incr ACKs Rcvd,       |     |
-    |     |          | |                       |   ACKST=0               |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| ACKST = 4             | SendBLK = ARBLK,        | AC4 |
-    |     |          | |                       |   ACKST=0               |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC4 | XMCheck  |1| NumNAK < 4            | Set SEAlink Flag,       | exit|
-    |     |          | |                       |   WINDOW = 6            |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| NumNAK >= 4           | Reset SEAlink flag,     | exit|
-    |     |          | |                       |   WINDOW = 1            |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC5 | SLOCheck |1| SLO Reset             |                         | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| ACKs Rcvd < 10        |                         | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| ACKs Rcvd >= 10       | Reset SLO               | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC6 | SL1Check |1| ACKST = 1 or 2        | ARBLK8 = CHR,           | AC6 |
-    |     |          | |                       |   ACKST = ACKST+2       |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| SEAlink reset         |                         | AC7 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| ACKST = 0             |                         | AC7 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| ACKST > 2             |                         | exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-                            (Continued on next page)
-
-    *1 - ARBLK is valid only if all of the following are true:
-
-         a. ARBLK >= 0
-         b. ARBLK <= SendBLK
-         c. ARBLK >  SendBLK-128
-
-    *2 - Software error if ACKST is not 3 or 4 in state AC3
-
-
-                                                                            22
-    XMODEM/TeLink/SEAlink - Transmitter ACK/NAK Check
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC7 | ACKNAK   |1| CHR = ACK             | ACKST = 1               | AC8 |
-    |     |          | |                       |   NumNAK = 0            |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| CHR = NAK or 'C'      | Set CRC/Chksm if 1st,   | AC9 |
-    |     |     (*1) | |                       |   ACKST = 2,            |     |
-    |     |          | |                       |   Incr NumNAK,          |     |
-    |     |          | |                       |   Delay 0.6 seconds     |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |     (*1) |3| CHR = SYN             | Receive RESYNC packet,  | AC10|
-    |     |          | |                       |   ACKST = 0             |     |
-    |     |     (*2) +-+-----------------------+-------------------------+-----+
-    |     |          |4| CHR = other           |                         | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC8 | XMACK    |1| SEAlink set           |                         | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| SEAlink reset         | Incr ACKBLK             | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC9 | XMNAK    |1| SEAlink set           |                         | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| SEAlink reset         | SendBLK = ACKBLK+1      | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | AC10| RESYNC   |1| RESYNC pkt invalid    | Send NAK                | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| RESYNC pkt valid      | Set SEAlink flag,       | exit|
-    |     |          | |                       |   WINDOW = 6,           |     |
-    |     |          | |                       |   SendBLK = RESYNC Blk#,|     |
-    |     |          | |                       |   ACKBLK = SendBLK-1,   |     |
-    |     |          | |                       |   Send ACK              |     |
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-    *1 - If the output is buffered in local computer memory, any characters
-         which remain in the local buffer should be purged before leaving
-         states (AC7.2) or (AC7.3) to aid in resynchronizing the link.
-
-    *2 - If the implementation is honoring MACFLOW protocol, set the flag in
-         the SEAlink header block and add the following state to (AC7):
-
-    .-----+--------+---+-----------------------+-------------------------+-----.
-    | AC7 |        |3.5| CHR = ^S (13H) &      | Delay 10 seconds or     | exit|
-    |     |        |   |   SEAlink set &       |   until ^Q (11H) rcvd   |     |
-    |     |        |   |   ACKST = 0           |                         |     |
-    `-----+--------+---+-----------------------+-------------------------+-----'
-
-
-
-                                                                            23
-    XMODEM/TeLink/SEAlink - Receiver
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | XR0 | RecInit  |                         | reset SEAlink flag,     | XR1 |
-    |     |          |                         |   reset SLO flag,       |     |
-    |     |          |                         |   reset RESYNC flag,    |     |
-    |     |          |                         |   set CRC flag,         |     |
-    |     |          |                         |   set blocknum=0,       |     |
-    |     |          |                         |   set WriteBLK=1,       |     |
-    |     |          |                         |   reset retry cnt       |     |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | XR0B| BrecInit |  Alternate Entry from   | reset SEAlink flag,     | XR2 |
-    |     |          |  Batch Receive (BR4.2)  |   reset SLO flag,       |     |
-    |     |          |  or (BR4.3)             |   reset RESYNC flag,    |     |
-    |     |          |                         |   set CRC flag,         |     |
-    |     |          |                         |   set blocknum=0,       |     |
-    |     |          |                         |   set WriteBLK=1,       |     |
-    |     |          |                         |   reset retry cnt       |     |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | XR1 | RecStart |                         | (Send NAK SN0)          | XR2 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | XR2 | WaitFirst|1| 10 retries or 1 minute| report receive failure  | exit|
-    |     |          | |   w/o valid input     |                         |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| > 3 retries or 30 secs| reset CRC flag          | XR1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| EOT received          | (Send ACK SA0),         | exit|
-    |     |          | |                       |   report no file        |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |     (*1) |4| TeLink block recd     | (Send ACK SA0),         | XR3 |
-    |     |          | |                       |   reset retry cnt       |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |     (*2) |5| SEAlink block recd    | set SEAlink,            | XR4 |
-    |     |          | |                       |   set RESYNC as         |     |
-    |     |          | |                       |   indicated by header   |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |     (*3) |6| XMODEM data block 1   | Write block to file,    | XR3 |
-    |     |          | |   received            |   Incr WriteBLK,        |     |
-    |     |          | |                       |   Incr blocknum,        |     |
-    |     |          | |                       |   (Send ACK SA0),       |     |
-    |     |          | |                       |   reset retry cnt       |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |7| bad block or 2-10 secs| incr retry count        | XR1 |
-    |     |          | |   without input       |                         |     |
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-                              (Continued on next page)
-
-    *1 - A TeLink header packet has the standard XMODEM data block format except
-         that it begins with an SYN instead of an SOH character and has a block
-         number of 0.  Note: SEAdog (through version 4.51b) does not possess
-         (XR2.4) and therefore will consider a TeLink header a bad block and
-         process it according to (XR2.7) when communicating with mailers which
-         do not do SEAlink protocol.
-
-    *2 - A SEAlink header packet has the standard XMODEM data block format
-    *3   except that is has a block number of 0. The first block is an XMODEM
-         data block if its block number is not 0.
-
-
-
-
-                                                                            24
-    XMODEM/TeLink/SEAlink - Receiver (cont.)
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | XR3 | WaitBlock|1| 10 retries or 1 minute| report receive failure  | exit|
-    |     |          | |   w/o expected block  |                         |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| EOT received          | reset SLO flag,         | exit|
-    |     |          | |                       |   (Send ACK SA0)        |     |
-    |     |          | |                       |   report recd ok        | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| expected data         | Decrement blocknum,     | XR3 |
-    |     |          | |   block-1 received    |   (Send ACK SA0)        |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| expected data         | Write block to file,    | XR3 |
-    |     |          | |   block received      |   Incr WriteBLK,        |     |
-    |     |          | |                       |   (Send ACK SA0),       |     |
-    |     |          | |                       |   reset retry cnt       |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| SEAlink set &         | Discard block - resync  | XR3 |
-    |     |          | |   expected block+1 to |   in progress,          |     |
-    |     |          | |   expected block+127  | Send Conditional NAK(*5)|     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |6| bad block or 2-10 secs| (Send NAK SN0),         | XR3 |
-    |     |          | |   without input       |   incr retry cnt        |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | XR4 | Restart  |1| Want entire file      | (Send ACK SA0),         | XR5 |
-    |     |          | |   or RESYNC not set   | reset retry cnt         |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Want to resume an     |  WriteBLK = file restart| XR5 |
-    |     |          | |   interrupted xfer    |    block number,        |     |
-    |     |          | |   and RESYNC is set   |  blocknum=WriteBLK&0FFh,|     |
-    |     |          | |                       |    (Send NAK SN0)       |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | XR5 | SetOvrdr |                         | Set SLO as indicated    | XR3 |
-    |     |          |                         |   by SEAlink header     |     |
-    `-----+----------+-------------------------+-------------------------+-----'
-    Note: The routine that receives a header/data block should do the following:
-
-    1. Report a bad block if the checksum or CRC is not correct or if the
-       physical layer encounters errors (e.g. parity, framing, etc.) regardless
-       of checksum or CRC.  Report a bad block if the length of the block is
-       less than expected (Use a 5 second timeout to detect short blocks).
-    2. If the block's sequence number does not match the complement, then
-       report a bad block if not in SEAlink. If in SEAlink mode don't report
-       this as a bad block, just restart the block search looking for SOH.
-       Check for SOH, BLK, ~BLK characters in a "sliding" fashion and keep
-       cycling until a valid start of block (or timeout) is detected before
-       assembling the remainder of the block.  This procedure makes a resync
-       occur much more rapidly, and with far fewer errors reported.
-    3. If the sequence number and block are good but not the expected number,
-       report state (XR3.3) if previous block.  If not in SEAlink, abort on any
-       other out of sequence block.  If in SEAlink, report back state (XR3.5)
-       or (XR3.6) as indicated by the out of sequence received block number.
-    4. If an EOT is received on a data block prior to the filesize specified
-       in the SEAlink or TeLink header block, a NAK should be issued to ensure
-       that spurious data did not cause a premature EOF.  A NAK should also
-       be issued for the first EOT received in an Xmodem transfer when the
-       final file size is not known.  A second EOT without intervening data
-       would ensure that the file really has been sent, and should be ACK'd.
-    5. If you last sent an ACK, then send a NAK here.  If you last sent a NAK
-       then only NAK evry 32 blocks after the first NAK.  This allows buffer
-       drain in overdrive.  Use (Send NAK SN0) to send the NAK.
-                                                                            25
-    XMODEM/TeLink/SEAlink - Send NAK
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SN0 | ClearLine|1| RESYNC flag set       | Send RESYNC packet      | SN3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| SEAlink flag set      |                         | SN1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| > 30 sec contin data  | report failure          | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| character waiting     | eat character           | SN0 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| clear line            |                         | SN1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SN1 | SendNAK  |1| CRC flag set          | Send "C"                | SN2 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| CRC flag reset        | send NAK                | SN2 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SN2 | SEAlink  |1| SEAlink flag reset    |                         | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| SEAlink flag set      | send blocknum, ~blocknum| exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SN3 | AckResync|1| Rcv ACK               |                         | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Rcv NAK               | Resend RESYNC packet    | SN3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Rcv Other Char        | eat character           | SN3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| No char for 10 secs   | Resend RESYNC packet    | SN3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| 30 seconds in SN3     |                         | exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-    Note: RESYNC packet should send WriteBLK as its desired block number.
-
-
-    XMODEM/TeLink/SEAlink - Send ACK
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SA0 | ClearLine|1| SLO flag set          |                         | SA3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| SEAlink flag set      |                         | SA1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| > 30 sec contin data  | report failure          | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| character waiting     | eat character           | SA0 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| No char waiting       |                         | SA1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SA1 | SendACK  |                         | Send ACK                | SA2 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SA2 | SEAlink  |1| SEAlink flag reset    |                         | SA3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| SEAlink flag set      | send blocknum, ~blocknum| SA3 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SA3 | IncBlk   |                         | Incr blocknum           | exit|
-    `-----+----------+-------------------------+-------------------------+-----'
-
-
-
-
-                                                                            26
- 3. Data Link Layer Protocol : MODEM7 Filename Finite State Machines
-    (There is no change to the MODEM7 state tables from FTS-0001).
-
-    MODEM7 Filename Sender
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | MS0 | WaitNak  |1| 20 retries or 1 minute| filename send failed    | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| NAK received          | send ACK & 1st ch of fn | MS1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | MS1 | WaitChAck|1| ACK rcd, fname done   | send SUB = 1AH          | MS2 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| ACK rcd, fname ~done  | send next ch of fname   | MS1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| other char or 1 sec   | send "u", incr retry cnt| MS0 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | MS2 | WaitCksm |1| cksum recd and ok     | send ACK, report fn ok  | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| cksum recd but bad    | send "u", incr retry cnt| MS0 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| no cksum in 1 sec     | send "u", incr retry cnt| MS0 |
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-
-    MODEM7 Filename Receiver
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | MR0 | SendNak  |1| 20 tries or 1 minute  | report filename failure | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2|                       | send NAK, incr try cnt  | MR1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | MR1 | WaitAck  |1| rcd ACK               |                         | MR2 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| rcd EOT               | report no files remain  | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| 5 secs & no ACK/EOT   |                         | MR0 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | MR2 | WaitChar |1| recd EOT (can happen?)| report no files remain  | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| recd SUB              | send checksum byte      | MR3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| recd "u"              |                         | MR0 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| recd char of name     | send ACK                | MR2 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| no char in 1 second   |                         | MR0 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | MR3 | WaitOkCk |1| recd ACK within 1 sec | report recd filename ok | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| recd "u" or other char|                         | MR0 |
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-    SUB  is the ASCII character ^Z or 1AH.  The checksum is the unsigned low
-    order eight bits of the sum of the characters in the transferred filename
-    including the SUB.
-
-    Although 1 second timeouts are used successfully by Fido and SEAdog, some
-    fear that this is too small a value for some satellite and packet networks.
-
-                                                                            27
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-0008.html b/html/ftsc/fts-0008.html deleted file mode 100755 index 83de361e..00000000 --- a/html/ftsc/fts-0008.html +++ /dev/null @@ -1,491 +0,0 @@ - - - -Bark file-request protocol extension. - - - - -
-Document: FTS-0008
-Version:  003
-Date:     15-Oct-1990
-Updates:  FTS-0001
-
-
-
-                  An Enhanced FidoNet(r) Technical Standard
-                 Extending FTS-0001 to include Bark requests
-
-                            October 15, 1990
-
-
-
-
-Status of this document:
-
-    This document specifies an optional standard for the FidoNet community.
-    Implementation of the protocols defined in this document is not mandatory,
-    but all implementations of these protocols are expected to adhere to this
-    standard.  Distribution of this document is subject to the limitations of
-    the copyright notice displayed below.
-
-
-    Copyright 1989-90 by Philip L. Becker.  Portions of this document are
-    copyright 1986-90 by Randy Bush and are incorporated with his consent.
-    All rights reserved.  A right to distribute only without modification and
-    only at no charge is granted.  Under no circumstances is this document to
-    be reproduced or distributed as part of or packaged with any product or
-    other sales transaction for which any fee is charged.  Any and all other
-    reproduction or excerpting requires the explicit written consent of the
-    copyright holders.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- A. Introduction
-
- 1. This Document
-
-    This document describes the standard for "Bark" type FidoNet file
-    request operation.  Bark file requests are an extension to the basic
-    FTS-0001 mail session, and this document presents these requests as a
-    modification to that document.
-
- 2. What are File Requests?
-
-    File Requests are a way of requesting that a specific file be sent during
-    a FidoNet mail session.  This has many advantages over simply logging on to
-    a BBS and downloading a file:
-
-       o  You need not be a validated user
-
-       o  You don't have to spend time searching for the file on the BBS
-
-       o  You can schedule the file request to take place at any time without
-          your being near your computer.
-
-    There are two commonly used types of file requests on FidoNet today, WaZOO
-    and Bark requests.  WaZOO requests are used by Opus and BinkleyTerm, and
-    are not documented here.  See the document FTS-0006 by V. Perriello for a
-    description of these.   Bark requests were the first file request extension
-    to the FTS-0001 protocol, and are supported (at least partially) by many
-    mailers, including SEAdog, Dutchie, BinkleyTerm, and to a certain extent
-    Opus.  This document describes how to implement Bark-type file requests.
-
-
- B. Terms Used in this Document
-
- 1. The diagrams and notations used in this document are the same as those used
-    in the FTS-0001 document.  Please see FTS-0001 for a description of these.
-    This document should be considered as an extension to the FTS-0001 session
-    layer protocol, and you will require FTS-0001 in addition to this document
-    to fully understand what is presented here.
-  
-    In addition to the data description language described in FTS-0001 section
-    A.4, one extra terminal used in this notation:
-  
-    (* terminals *)
-    someName<max> - String of up to max chars, NOT null terminated
-
-
- C. Performing File Requests
-
- 1. Introduction
-
-    A Bark request consists of transmitting a special Bark Request packet which
-    contains a filename, a date (used for update requests), and optionally a
-    password.  The system receiving the request then decides if it can send the
-    requested file or not, and if it can does so using the same protocol used
-    to send attached files.  Bark request handling is always controlled by the
-    answering system, and consists of two phases.  In phase one, the receiving
-    system asks the calling system to honor requests it may have to ask for
-    files from the caller.  In phase two, the receiving system allows the
-    calling system to request files from it.
-
-    Update file requests are the same as normal file requests, with one
-    exception.  If the date in the Bark Request packet (described below) is
-    greater than or equal to the date of the actual file requested, the file
-    will not be sent.  The requestor should set the date to the date of the
-    the actual file on its own end if an update request is desired.
-
-
- D. The Bark Request Packet
-
- 1. Data Link Layer Data Definition.
- 
-    The Bark Request packet is a variable-sized packet containing a header, a
-    filename, a date (which is used only for update requests - in a normal file
-    request it's 0) and an optional password. When receiving a Bark Request
-    packet, the ETX may be used to determine the end of the data portion. Note
-    that the CRC is sent in the reverse byte order of a normal CRC XMODEM data
-    block (see FTS-0001 section G.1).
-
-    Note: some systems will send a password in the data block even if none is
-    needed.  Incoming passwords should be ignored unless the other system is
-    trying to request a passworded file.
-
-  
-
-                          Bark File Request Packet
-      Offset
-      dec hex
-              .-----------------------------------------------.
-        0   0 |       ACK - Start of Bark Request - 06H       |
-              +-----------------------------------------------+
-        1   1 |     Filename - Packed DOS file format         |
-              +-----------------------------------------------+
-        n   n |              SPACE - 20H                      |
-              +-----------------------------------------------+
-        n   n |              Date (0 if not Update Request)   |
-              +-----------------------------------------------+
-        n   n |      SPACE - 20H  (only if pswd follows)      |
-              +-----------------------------------------------+
-        n   n |         Password (optional)                   |
-              +-----------------------------------------------+
-        n   n |       ETX -  End of RESYNC packet  - 03H      |
-              +-----------------------------------------------+
-        n   n |     (*1)     CRC  low order byte              |
-              +-----------------------------------------------+
-        n   n |     (*1)     CRC high order byte              |
-              `-----------------------------------------------'
-
-              *1 - CRC does not include the ACK or ETX and is
-                   in the reverse byte order from the CRC in a
-                   normal XMODEM data packet.
-
- 2. Data Description Notation of Bark Request Packet
-
-    DataBlock (no password) = ACK
-                              Filename<12>
-                              Space
-                              Date<11>
-                              ETX
-                              CRC
-  
-    DataBlock (with password) = ACK
-                                Filename<12>
-                                Space
-                                Date<11>
-                                Space
-                                Password<6|8>
-                                ETX
-                                CRC
-  
-    ACK   = 06H       (* Header for file request block *)
-    Space = 20H       (* Space character *)
-    ETX   = 03H       (* End of block *)
-  
-    Filename          (* Name of file requested *)
-    Date              (* ASCII string; the number of seconds
-                         since midnight, January 1, 1970 *)
-    Password          (* The password needed to request this
-                         file, if any.  Maximum length is 6 for
-                         BinkleyTerm and Opus, 8 for SEAdog
-                         and Dutchie. *)
-  
-    CRC = crc[2]      (* CCITT Cyclic Redundancy Check.  The
-                         same algorithm as used for XModem
-                         CRCs.  The CRC is calculated on
-                         all data in the block between but
-                         not including the ACK and the ETX *)
-
- E. Session Layer Protocol:
-
-    This section describes the modified FTS-0001 session layer protocol.  This
-    is the only area of FTS-0001 which is modified to implement Bark style file
-    requests.  File Requests are performed at the end of the normal FidoNet
-    mail session, after any mail pickup is performed.
-
-    The diagrams below desribe the session level protocol with Bark file
-    requests implemented.  The state tables have been broken into subroutines
-    but the FTS-0001 portion is not functionally changed.  FTS-0001 sender
-    states S4 through S7 are now table "Send Mail SM0".  FTS-0001 receiver
-    states R3 through R6 are now table "Receive Mail RM0".  They are not
-    functionally changed in any way from FTS-0001, they are just broken out
-    to allow them to be used as subroutines.  Finally Sender states S0 through
-    S3 are unchanged, as are Receiver states R0 through R2.
-
-    The remaining FTS-0001 states are enhanced to implement the Bark file
-    request protocol. In addition, the subroutine state tables "Send Bark SB0"
-    and "Receive Bark RB0" have been added to handle the actual file requests.
- 
-    The following diagrams fully replace the Session Layer protocol state
-    tables in FTS-0001.  No other changes to FTS-0001 are required to implement
-    the Bark File request feature.
-
-    Sender  (Top level)
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | S0  | SendInit |                         | dial modem              | S1  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S1  | WaitCxD  |1| carrier detected      | delay 1-5 seconds       | S2  |
-    |     |  (*1)    | |                       | Set SLO if > 2400bps,   |     |
-    |     |          | |                       | Reset SLO if <= 2400bps |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| busy, etc.            | report no connection    | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| voice                 | report no carrier       | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| carrier not detected  | report no connection    | exit|
-    |     |          | | within 60 seconds     |                         |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S2  | WhackCRs |1| over 30 seconds       | report no response <cr> | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| ?? <cr>s received     | delay 1 sec             | S3  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| <cr>s not received    | send <cr> <sp> <cr> <sp>| S2  |
-    |     |          | |                       |   delay ??? secs        |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S3  | WaitClear|1| no input for 0.5 secs | send TSYNCH = AEH       | S4  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| over 60 seconds       | hang up, report garbage | exit|
-    |     |          | | and line not clear    |                         |     |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S4  | SendMail |                         | (Send Mail SM0)         | S5  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | S5  | TryPickup|1| Rcv TSYNC             | (Receive Mail RM0)      | S5  |
-    |     |   (*2)   +-+-----------------------+-------------------------+-----+
-    |     |          |2| Rcv SYN               | (Receive Bark Req RB0)  | S5  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Rcv ENQ               | (Do Bark Requests SB0)  | S5  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| Rcv 'C' or NAK        | Send EOT                | S5  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| Rcv Other Char        | Send SUB                | S5  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |6| No Data for 45 secs   | Hang Up                 | exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-    *1 - This state is shown for the extended SEAlink protocol.  Omit the
-         set/reset SLO actions if adding Bark to a strict FTS-0001 protocol
-         implementation, or if not implementing overdrive in SEAdog.
-   
-    *2 - To refuse to pickup mail (S5.1) may send a CAN and stay in (S5).
-
-    Note: Although the above shows the sender emitting only one TSYNCH, it is
-    recommended that a timeout of 5-20 seconds should initiate another TSYNCH.
-    The receiver should tolerate multiple TSYNCHs.
-    Receiver (Top Level)
-
-    The  receiving FSM is given  an external timer, the expiration of  which
-    will cause termination with a result of 'no calls' (R0.2).
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R0  | WaitCxD  |1| carrier detected      |                         | R1  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| external timer expires| report no calls         | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R1  | WaitBaud |1| baud rate detected    | send signon with s  | R2  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| no detect in ?? secs  | hang up, report no baud | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R2  | WaitTsync|1| TSYNCH received       | ignore input not TSYNCH | R3  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| 60 seconds timeout    | hang up, report not Fido| exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R3  | RecMail  |                         | (Receive Mail RM0)      | R4  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R4  | AllowPkup|1| Have pickup for sender| Send Tsync,             | R5  |
-    |     |          | |                       |   Set T1=1 sec          |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| No pickup for sender  |                         | R6  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R5  | WtPickup |1| Rcv NAK or 'C'        | (Send Mail SM0)         | R6  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Rcv SUB               | Send Tsync,             | R5  |
-    |     |          | |                       |   Set T1=1 sec          |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Rcv CAN               | Report Mail Refused     | R6  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| T1 expired            | Send Tsync,             | R5  |
-    |     |          | |                       |   Set T1=1 sec          |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| 45 secs in R5         | Hang Up, report error   | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R6  | AskBark  |1| Wish to make requests | Send SYN                | R7  |
-    |     |   (*1)   +-+-----------------------+-------------------------+-----+
-    |     |          |2| No requests to make   |                         | R8  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R7  | DoRequest|1| Rcv CAN               | Report Requests Refused | R8  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Rcv ENQ               | (Send Bark SB0)         | R8  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Rcv SUB               | Send SYN                | R7  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| Rcv NAK or 'C'        | Send EOT                | R6  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| Rcv Other             | eat character           | R7  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |6| 5 sec, no input       | Send SYN                | R7  |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |7| 45 secs in R7         |                         | R8  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | R8  | WtPickup |1| Allow File Request    | (Receive Bark RB0),     | exit|
-    |     |          | |                       |   Hang Up               |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Disallow Requests     | Hang Up                 | exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-    *1 - Some implementations always do (R6.1) even if they have no requests.
-    Sender - Send Mail
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | SM0 | SendMail |                         | (XMODEM send packet XS0)| SM1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SM1 | CheckMail|1| XMODEM successful     | (Fido registers success)| SM2 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| XMODEM fail or timeout| hang up, report mail bad| exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SM2 | SendFiles|                         | (BATCH send files BS0)  | SM3 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SM3 | CheckFile|1| BATCH send successful | report success          | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| BATCH send failed     | hang up, rept files fail| exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-
-
-    Sender - Send Bark
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SB0 | SendBark |1| File to request       | Build Bark Request Pkt, | SB1 |
-    |     |          | |                       |   Set tries = 0         |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| No more files to req  | Send ETB                | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SB1 | AskFile  |                         | Send Bark Packet        | SB2 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SB2 | RcvFile  |1| Rcv ACK               | (Batch Receive BR0)     | SB3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Tries > 5             | Send ETB, report failed | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Rcv Other             | Purge input, Incr tries | SB1 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| 10 sec w/o ACK        | Incr tries              | SB1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | SB3 | NxtFile  |1| Rcv ENQ               |                         | SB0 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Rcv Other             | Purge Input             | SB3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| 5 sec, no input       | Send SUB                | SB3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| 45 sec in SB3         | Hang up, report error   | exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-    Sender & Receiver - Receive Mail
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-------------------------+-------------------------+-----+
-    | RM0 | RecMail  |                         | (XMODEM rec packet XR0) | RM1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | RM1 | XRecEnd  |1| XMODEM successful     | delay 1 second          | RM2 |
-    |     |          | |                       |   flush input           |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| XMODEM failed         | hang up, rept mail fail | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | RM2 | RecFiles |                         | (BATCH rec files BR0)   | RM3 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | RM3 | ChkFiles |1| BATCH recv successful | delay 2 secs, rprt good | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| BATCH recv failed     | hang up, report bad file| exit|
-    `-----+----------+-+-----------------------+-------------------------+-----'
-
-
-    Sender & Receiver - Receive Bark
-
-    .-----+----------+-------------------------+-------------------------+-----.
-    |State| State    | Predicate(s)            | Action(s)               | Next|
-    |  #  | Name     |                         |                         | St  |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | RB0 | HonorReq |1| Ok to honor request   | Purge Input, Send ENQ,  | RB1 |
-    |     |          | |                       |   Set T1 = 2 seconds    |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Don't wish to honor   | Send CAN                | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | RB1 | WaitBark |1| Got ACK               | Rcv Bark Packet (*1)    | RB2 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Got ETB               | Report done             | exit|
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| Got ENQ               | Send ETB                | RB0 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |4| T1 expired            | Purge Input, Send ENQ,  | RB1 |
-    |     |          | |                       |   Set T1 = 2 seconds    |     |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |5| 20 seconds in RB1     | Hang Up, Report error   | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | RB2 | AckBark  |1| Bark Pkt Rcvd Good    | Send ACK                | RB3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| Bark Pkt Rcv Error    | Send NAK                | RB1 |
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | RB3 | WaitStrt |1| Got 'C' or NAK        |                         | RB4 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |2| No data for 3 seconds | Send ACK                | RB3 |
-    |     |          +-+-----------------------+-------------------------+-----+
-    |     |          |3| 15 seconds in RB3     | Hang Up, Report Error   | exit|
-    +-----+----------+-+-----------------------+-------------------------+-----+
-    | RB4 | SendFile |1| Can snd requested file| (Batch Send File BS0)   | RB0 |
-    |     |   (*2)   +-+-----------------------+-------------------------+-----+
-    |     |          |2| Can't send file       | Send EOT                | RB0 |
-    `-----+----------+-+-----------------------+-------------------------+-----'
-    *1 - If SUB (16H) received before ETX go to RB0 to resync bark receive
-
-    *2 - While deciding if file exists, and if the password allows it to be
-         sent etc., a NUL may be sent to buy 20 seconds more on the timeout
-         on the other end if it is using the SEAlink extended FTS-0001
-         specification protocol.  Sending a NUL is harmless for a strict
-         FTS-0001 session, but will not buy more time.
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-0009.html b/html/ftsc/fts-0009.html deleted file mode 100755 index 2d41cf4e..00000000 --- a/html/ftsc/fts-0009.html +++ /dev/null @@ -1,105 +0,0 @@ - - - -Message identification and reply linkage. - - - - -
-Document: FTS-0009
-Version:  001
-Date:     17-Dec-91
-
-
-
-
-                               MSGID / REPLY
-                  A standard for unique message identifiers
-                          and reply chain linkage
-
-                            17 December, 1991
-
-                                 jim nutt
-                             1:114/30@fidonet
-
-
-
-
-Status of this document:
-
-     This FTS (FidoNet(r) Technical Standard) specifies an optional
-     standard for the FidoNet community.  Implementation of the
-     protocols defined in this document is not mandatory,  but all
-     implementations of these protocols are expected to adhere to this
-     standard.  Distribution of this document is unlimited.
-
-     Fido and FidoNet are registered marks of Tom Jennings and Fido
-     Software.
-
-
-MSGID
-
-     A MSGID line consists of the string "^AMSGID:" (where ^A is a
-     control-A (hex 01) and the double-quotes are not part of the
-     string),  followed by a space,  the address of the originating
-     system,  and a serial number unique to that message on the
-     originating system,  i.e.:
-
-          ^AMSGID: origaddr serialno
-
-     The originating address should be specified in a form that
-     constitutes a valid return address for the originating network.   
-     If the originating address is enclosed in double-quotes,  the
-     entire string between the beginning and ending double-quotes is 
-     considered to be the orginating address.  A double-quote character
-     within a quoted address is represented by by two consecutive
-     double-quote characters.  The serial number may be any eight
-     character hexadecimal number,  as long as it is unique - no two
-     messages from a given system may have the same serial number
-     within a three years.  The manner in which this serial number is
-     generated is left to the implementor.
-
-
-REPLY
-
-     A REPLY line consists of the string "^AREPLY:" (where ^A is a
-     control-A (hex 01) and the double-quotes are not part of the
-     string),  followed by a space, and the origaddr and serialno
-     fields of the MSGID line of the message to which this message is a
-     reply,  i.e.:
-
-        ^AREPLY: origaddr serialno
-
-     The origaddr and serialno fields must be identical to the
-     corresponding fields in the MSGID of the message to which this
-     message is a reply.  A REPLY line is never generated in a 
-     message that is a reply to a message that does not contain a
-     MSGID line.
-
-
-GENERAL
-
-     MSGID and REPLY lines should be placed before the text body of the
-     message in which they appear.
-
-     Finally,  a MSGID is generated only at the time of message
-     creation.  An existing MSGID and/or REPLY should never be stripped
-     from a message passing through an intermediate system.  No system
-     should ever add an MSGID and/or REPLY to,  or modify an existing
-     MSGID / REPLY contained in,  a message not originating on that
-     system.
- 
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-4001.html b/html/ftsc/fts-4001.html deleted file mode 100755 index 79292fdf..00000000 --- a/html/ftsc/fts-4001.html +++ /dev/null @@ -1,193 +0,0 @@ - - - -Addessing Control Paragraphs. - - - - -
-**********************************************************************
-FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication:    FTS-4001
-Revision:       1
-Title:          ADDRESSING CONTROL PARAGRAPHS
-Author(s):      FTSC
-
-Revision Date:  1 October 2000
-Expiry Date:    1 October 2002
-----------------------------------------------------------------------
-Contents:
-                1. Credits
-                2. General
-                3. FMPT
-                4. TOPT
-                5. INTL
-----------------------------------------------------------------------
-
-Status of this document
------------------------
-
-  This document is a Fidonet Standard (FTS).
-
-  This document specifies a Fidonet standard for the Fidonet
-  community.
-
-  This document is released to the public domain, and may be used,
-  copied or modified for any purpose whatever.
-
-
-1. Credits
-----------
-
-  This document is based on the work of Randy Bush and many others.
-
-
-2. General
-----------
-
-  The general control paragraph format is specified in separate FTSC
-  documents.
-
-  The addressing control paragraphs specified in this document are
-  normally only used in netmail messages and not in echomail messages.
-
-  While it would be technically correct to use them also in echomail,
-  it is known that certain programs will misbehave if they are present
-  there. It is therefore recommended that they should not be used in
-  echomail at the present time.
-
-  If a program processing messages detects these control paragraphs in
-  an echomail message it is recommended that they are disregarded and
-  deleted from any copies of that message exported to other systems.
-
-  Addressing of and address resolution for echomail messages should
-  instead be done with the help of packet and message header
-  information. See separate FTSC documents.
-
-  To determine the address of the original sender of an echomail
-  message, the information in the Origin line should be used. See
-  separate FTSC documents.
-
-
-3. FMPT
--------
-
-  The FMPT control paragraph shall be used to give information about
-  the point number of the original sender of a message if that point
-  number is not 0. If the point number of the original sender of a
-  message is 0 that message should not contain any FMPT control
-  paragraph.
-
-  The format of a FMPT control paragraph shall be:
-
-    <SOH>"FMPT <point number>"<CR>
-
-  where <point number> is the ASCII representation of the point number
-  of the sender. The point number shall be an unsigned integer in the
-  range 1-65535.
-
-  E.g. a message from point number 1 of a certain node shall contain
-  the following FMPT control paragraph
-
-    <SOH>"FMPT 1"<CR>
-
-  Note that the format of a FMPT control paragraph deviates from the
-  general format specified in separate FTSC documents in that it does
-  not contain any colon after the control tag.
-
-
-4. TOPT
--------
-
-  The TOPT control paragraph shall be used to give information about
-  the point number of the ultimate addressee of a message if that
-  point number is not 0. If the point number of the ultimate addressee
-  of a message is 0 that message should not contain any TOPT control
-  paragraph.
-
-  The format of a TOPT control paragraph shall be:
-
-    <SOH>"TOPT "<point number><CR>
-
-  where <point number> is the ASCII representation of the point number
-  of the addressee. The point number shall be an unsigned integer in
-  the range 1-65535.
-
-  E.g. a message to point number 1 of a certain node shall contain the
-  following TOPT control paragraph
-
-    <SOH>"TOPT 1"<CR>
-
-  Note that the format of a TOPT control paragraph deviates from the
-  general format specified in separate FTSC documents in that it does
-  not contain any colon after the control tag.
-
-
-5. INTL
--------
-
-  The INTL control paragraph shall be used to give information about
-  the zone numbers of the original sender and the ultimate addressee
-  of a message.
-
-  The format of an INTL control paragraph shall be:
-
-    <SOH>"INTL "<destination address>" "<origin address><CR>
-
-  where <destination address> shall be the representation of the
-  address of ultimate destination and <origin address> is the
-  representation of the address of the original sender of the message
-  in question. These addresses shall be given on the form
-  <zone>:<net>/<node> where <zone> is the ASCII representation of the
-  zone number, <net> is the ASCII representation of the net number and
-  <node> is the ASCII representation of the node number. Any point
-  number information shall be given in FMPT and TOPT control
-  paragraphs.
-
-  E.g. a message from address 1:123/4.5 to 2:345/6.7 shall contain the
-  following INTL control paragraph
-
-    <SOH>"INTL 2:345/6 1:123/4"<CR>
-
-  Note that the format of an INTL control paragraph deviates from the
-  general format specified in separate FTSC documents in that it does
-  not contain any colon after the control tag.
-
-  INTL control paragraphs are also often used even when both the
-  originating and the destination systems are in the same zone. This
-  gives both the originating system and the destination system as well
-  as any intermediate routing systems unambiguous zone information
-  even in a situation where one system may be active in a number of
-  different (possibly non-FidoNet) zones.
-
-  Although it is known that some programs may route messages
-  incorrectly if the INTL control paragraph is present in messages
-  where both the originating and the destination systems are in the
-  same zone, it is recommended that the INTL control paragraph is
-  always inserted into netmail messages in packet files.
-
-
-
-A. History
-----------
-
-   Rev.1, 20001001: Initial Release.
-                    Principal author Goran Eriksson.
-
-**********************************************************************
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-4008.html b/html/ftsc/fts-4008.html deleted file mode 100755 index 0fce474d..00000000 --- a/html/ftsc/fts-4008.html +++ /dev/null @@ -1,191 +0,0 @@ - - - -Time zone information (TZUTC). - - - - -
-**********************************************************************
-FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication:  FTS-4008
-Revision:     2
-Title:        Time zone information (TZUTC)
-Author:       FTSC
-Issue Date:   16 May 2003
-Review Date:  16 May 2005
-Obsoletes:    FTS-0010.001
-----------------------------------------------------------------------
-Contents:
-              1. Introduction
-              2. Scope
-              3. Current practice
-              4. Control paragraph specification
-              5. Time zone table
-              6. Examples
-              A. References
-              B. History
-----------------------------------------------------------------------
-
-
-Status of this document
------------------------
-
-  This document is a Fidonet Technical Standard (FTS), issued by the
-  FTSC for the benefit of the Fidonet community.
-
-  This document is based on the FSP-1001 proposal by Odinn Sorensen,
-  2:236/77.
-  
-  This document is released to the public domain, and may be used,
-  copied or modified for any purpose whatsoever.
-
-
-1. Introduction
----------------
-
-  Current practice in FidoNet is to transmit message times in local
-  time.  This document specifies a standard for transmission of time
-  zone information in FidoNet messages, in the form of a control
-  paragraph (also known as a "control line" or "kludge") named TZUTC.
-
-
-2. Scope
---------
-
-  This standard is specified for the transmission of FidoNet messages
-  in any form where time zone information is not integrated into the
-  transport format, specifically any form where the information would
-  be lost if not transmitted in a control paragraph, eg. Type 2 packed
-  messages. [1]
-
-
-3. Current practice
--------------------
-
-  Some control paragraphs already exist to specify the time zone of
-  messages, notably "TZUTC" and "TZUTCINFO".  From observations of
-  these control paragraphs in actual messages, TZUTC and TZUTCINFO are
-  identical except for the name.  TZUTCINFO is probably named after
-  the JAM message base's [2] subfield of the same name.
-
-  This document adopts the TZUTC control paragraph because is the
-  shortest ("TZUTC" vs "TZUTCINFO").  However, software
-  implementations should be prepared to read and interpret the
-  TZUTCINFO control paragraph as well.
-
-  The TZUTC control paragraph is inserted before the message body
-  upon initial message creation, or export from a format containing
-  time zone information, such as the aforementioned JAM message base.
-
-
-4. Control paragraph specification
------------------------------
-
-  Messages which conform to this specification must add the following
-  control paragraph:
-
-    ^aTZUTC: <current offset from UTC>
-
-  Where ^a is ASCII 1, 01h.
-
-  The offset has the format <[-]hhmm>, where hhmm is the number of
-  hours and minutes, zero-padded to two digits each, that local time
-  is offset from UTC.  If local time is WEST of UTC, then the offset
-  is NEGATIVE.  See the table below for typical offsets.
-
-  Note that the hh in a time zone offset is not limited to a maximum
-  of 12.  This is because the International Date Line does not run
-  exactly along the boundary between zone -1200 and +1200.  The
-  minutes part is 00 for most time zones.
-
-  All four digits must be present.  If the offset is negative, there
-  must be a minus ('-', ASCII 45, 2Dh) in front of the offset.
-
-  Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of
-  the offset for positive numbers, but robust implementations should
-  be prepared to find (and ignore) a plus if it exists.
-
-  If local time changes as a result of, for example, daylight savings
-  time, then the offset in the TZUTC control paragraph should change
-  to reflect this.
-
-
-5. Time zone table
-------------------
-
-  This table gives examples of typical time zones.
-
-  -1000   Alaska-Hawaii Standard Time (United States)
-  -0900   Hawaii Daylight Time
-  -0800   Pacific Standard Time
-  -0700   Pacific Daylight Time
-  -0700   Mountain Standard Time
-  -0600   Mountain Daylight Time
-  -0600   Central Standard Time
-  -0500   Central Daylight Time
-  -0500   Eastern Standard Time
-  -0400   Eastern Daylight Time
-  -0400   Atlantic Standard Time
-  -0330   Newfoundland Standard Time
-  -0300   Atlantic Daylight Time
-  -0100   West Africa Time
-   0000   Universal Time Coordinated (UTC)
-   0000   Greenwich Mean Time
-   0100   Central European Time
-   0100   British Summer Time
-   0200   Central European Summer Time
-   0200   Eastern European Time
-   0800   Australian Western Standard Time
-   0800   China Coast Time
-   0900   Japan Standard Time
-   0900   Australian Western Daylight Time
-   0930   Australian Central Standard Time
-   1000   Australian Eastern Standard Time
-   1030   Australian Central Daylight Time
-   1100   Australian Eastern Daylight Time
-   1200   New Zealand Standard Time
-   1300   New Zealand Daylight Time
-
-
-6. Examples
------------
-
-  ^aTZUTC: 0000
-  ^aTZUTC: 0200
-  ^aTZUTC: -0700
-
-
-A. References
--------------
-
-  [1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy Bush.
-  September 1995.
-
-  [2] "The JAM message base proposal", Joaquim Homrighausen, Andrew
-  Milner, Mats Birch and Mats Wallin. July 1993.
-
-
-B. History
-----------
-
-  Rev.1, 20030409: First release (revised from FSP-1001 by FTSC)
-  Rev.2, 20030516: Corrected status; clarified Section 2 on insertion
-                   position and export practice; fixed terminology.
-
-**********************************************************************
-
- -BackGo Back - - - diff --git a/html/ftsc/fts-4009.html b/html/ftsc/fts-4009.html deleted file mode 100755 index 49ca0b1f..00000000 --- a/html/ftsc/fts-4009.html +++ /dev/null @@ -1,245 +0,0 @@ - - - -Netmail Tracking (Via) - - - - -
-**********************************************************************
-FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication:  FTS-4009
-Revision:     1
-Title:        Netmail tracking (Via)
-Author:       FTSC
-Issue Date:   16 May 2003
-Review Date:  16 May 2005
-----------------------------------------------------------------------
-Contents:
-              1. Current practice
-              2. Control paragraph specification
-              3. Examples
-              4. Deprecated formats
-              A. References
-              B. History
-----------------------------------------------------------------------
-
-Status of this document
------------------------
-
-  This document is a Fidonet Technical Standard (FTS), issued by the
-  FTSC for the benefit of the Fidonet community.
-
-  This document is based on the FSP-1010 proposal by Colin Turner,
-  2:443/13, and Joaquim Homrighausen, 2:201/330.
-  
-  This document is released to the public domain, and may be used,
-  copied or modified for any purpose whatsoever.
-
-
-1. Current practice
--------------------
-
-  As Netmail messages are routed through FidoNet, or as they are
-  processed on a system, Via control paragraphs are added to track
-  their progress.
-  
-  The Via control paragraphs are stored in a block which starts after
-  any message text.  New Via lines should  be added to the end of the
-  block separated from the preceding control paragraph by a single
-  ASCII carriage-return character (0Dh).  There is no limit to the
-  number of Via control paragraphs in each message.
-
-  Note that the "Via" tag is in mixed case, not all upper case like
-  most control tags.
-  
-  A Via control paragraph is typically added:
-  
-    when a Netmail packer packs the Netmail for transmission to
-    another system;
-    
-    when a netmail tracker inspects a Netmail.
-
-
-2. Control paragraph specification
-----------------------------------
-
-  The Via control paragraph is formatted as a number of fields,
-  separated by single space (20h) characters, as follows
-  
-    ^AVia <FTN Address> @YYYYMMDD.HHMMSS[.Precise][.Time Zone] 
-    <Program Name> <Version> [Serial Number]<CR>
-    
-  Where ^A denotes the ASCII <SOH> (01h) character, and <CR> is the
-  carriage-return character (0Dh).
-  
-  The fields are defined as follows:
-  
-  FTN Address
-  -----------
-
-  This field is mandatory and is the FidoNet Technology address of 
-  the system inserting the control paragraph, using standard Fidonet
-  addressing notation, Z:N/F[.P][@domain]
-  
-  @YYYYMMDD.HHMMSS
-  ----------------
-  
-  This field is mandatory and consists of a time stamp.  This is the
-  time at which the stamp was placed.  The subcomponents are
-  
-  YYYY, the calendar year, in full four digit, decimal form;
-  MM,   the calendar month, in the range 01 to 12, this must be a
-        zero padded, two digit decimal number;
-  DD,   the day of the month, in the range 01 to 31, this must be a
-        zero padded, two digit decimal number;
-  HH,   hours, in the range 00 to 23, this must be a zero padded,
-        two digit decimal number;
-  MM,   minutes, in the range 00 to 59, this must be a zero padded,
-        two digit decimal number;
-  SS.   seconds, in the range 00 to 59, this must be a zero padded,
-        two digit decimal number.
-        
-  Precise
-  -------
-  
-  This field is optional and takes the form of extra precision in the
-  time stamp.
-  
-  If this field is present:
-  
-    it must begin with a single period character;
-    
-    this period must be followed by one or more decimal digits;
-    
-    the field has ended when another period or space is encountered;
-    
-    each decimal digit in the field following this character
-    represents the time of the via line in fractions of a second,
-    such that the the first digit represents tenths of a second,
-    the second digit represents hundreds of a second and so on.
-
-  Robust implementations must check to ensure this field is numeric to
-  avoid confusion with the Time Zone field.
-        
-  Time Zone
-  ---------
-
-  This field is optional, and must be a short, widely accepted
-  alphabetical abbreviation of the time zone that the time stamp
-  in the Via line pertains to.
-  
-  The use of various Time Zone values is deprecated, implementations
-  should attempt to convert the timestamp in the control paragraph to
-  Universal Time (GMT or UTC) and use the "UTC" Time Zone indicator,
-  where possible.
-  
-  The Time Zone field may only be omitted when it is not possible for
-  the implementation to determine the correct offset from UTC, and in
-  this case the time stamp must represent local time on the generating
-  system.
-
-  Robust implementations must check to ensure this field is not
-  numeric to avoid confusion with the Precise field.
-  
-  Program Name
-  ------------
-  
-  This field is a mandatory string field of up to ten (10) characters
-  naming the product inserting the Via line.
-  
-  Version
-  -------
-
-  This field is a mandatory string field of up to ten (10) characters
-  specifying the version of the product inserting the Via line,
-  including any alpha, beta or gamma status.
-  
-  Serial Number
-  -------------
-  
-  This field is an optional string field of up to ten (10) characters
-  identifying the specific copy of the product inserting the Via line.
-
-
-3. Examples
------------
-
-  Example of valid usage are
-  
-  ^AVia 1:2/3 @19990305.043212.UTC O/T-Track+ 2.69
-  ^AVia 1:2/3@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
-  ^AVia 1:2/3.0 @19990101.002102.UTC FastEcho 1.46.1 21321
-  ^AVia 1:2/3 @19990323.230132 FakeMail 1.2
-  ^AVia 1:2/3 @20030403.182824.UTC Gleipner/Java 1.0/pre
-  ^AVia 1:2/3 @20030403.193223.UTC hpt 1.2.2-stable/os2
-  ^AVia D'Bridge 1.58 1:2/3  04/03 20:47
-  ^AVia 1:2/3@fidonet @20030404.030004.UTC O/T-Track+ 2.66b
-  ^AVia Squish/386 1.11 1:2/3, Thu Apr 03 2003 at 23:16 UTC
-  ^AVia 1:2/3 FTrack 3.1/W32 04 Apr 2003 09:33:07 UTC+1000
-  ^AVia ifmail 1:2/3@fidonet, Fri Apr 11 2003 at 06:01 (2.15)
-  ^AVia RTrk+ 1:2/3@fidonet, Apr 22 2003 at 18:25
-  ^AVia BBBS/NT v4.01 Flag-4 1:2/3.0, @030505155114 EDT+5
-
-
-4. Deprecated formats
----------------------
-
-  Some other formats for the Via line are in use today, but these
-  formats are rather variable and inconsistent in nature, while
-  the format specified above is both more widespread and more
-  consistent.
-  
-  New implementations may need to parse these formats, but must not
-  generate them.
-  
-  The formats in use include, but are not limited to
-  
-  <NAME> [VERSION] [SERIAL] <ADDRESS> <TIMESTAMP> <TIMEZONE>
-  <NAME> <ADDRESS>, <TIMESTAMP> <TIMEZONE> <VERSION>
-  
-  Not that the time stamp in the above formats is also widely
-  variable, and takes forms which include, but may not be limited to
-  
-  <Day> <Month> <Year> AT <Hour>:<Min>:[Sec]
-  <Day of Week> <Month> <Day of Month> <Year>  <Hour>:<Min>:<Sec>
-  ON <Day of Month> <Month> <Year>  <Hour>:<Min>:<Sec>
-  <Month>/<Day> <Hour>:<Min>
-  @YYMMDDHHMMSS
-  
-  In the last listed format, observe in particular the two digit year
-  and lack of period to separate the date from time.
-
-
-A. References
--------------
-
-  [FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
-  Bush. September 1995.
-
-  [FSC-46] "A Product Identifier for FidoNet Message Handlers",
-  Joaquim Homrighausen, August 1994.
-
-
-B. History
-----------
-
-  Rev.1, 20030516: First release (revised from FSP-1010 by FTSC; note
-                   the lack of a colon after the "Via" tag)
-
-**********************************************************************
-
- -BackGo Back - - - diff --git a/html/ftsc/fts-5000.html b/html/ftsc/fts-5000.html deleted file mode 100644 index 95de067b..00000000 --- a/html/ftsc/fts-5000.html +++ /dev/null @@ -1,453 +0,0 @@ - - - -The Distribution Nodelist. - - - - - -**********************************************************************
-FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication:    FTS-5000
-Revision:       1
-Title:          THE DISTRIBUTION NODELIST
-Author(s):      Colin Turner, Andreas Klein, Michael McCabe,
-                David Hallford, Odinn Sorensen
-
-Revision Date:  27 June 1999
-Expiry Date:    17 June 2001
-----------------------------------------------------------------------
-Contents:
-                1. Supercessions
-                2. Purpose
-                3. Publication and Distribution
-                4. Contents
-                5. Nodediff
-----------------------------------------------------------------------
-
-Status of this document
------------------------
-
-  This document is a Fidonet Standard (FTS).
-
-  This document specifies a Fidonet standard for the Fidonet
-  community.
-
-  This document is released to the public domain, and may be used,
-  copied or modified for any purpose whatever.
-
-
-Abstract
---------
-
-  Current practice for Fidonet Technology Networks (FTN) is to
-  maintain a nodelist used to store the details of the nodes in
-  the network, and the network structure.
-
-
-1. Supercessions
-----------------
-
-  FTS-0005 superceded and replaced the documents known under the names
-  of FSC-0002, and FTS-0002.
-
-  This document supercedes and replaces FTS-0005, FSC-0009, FSC-0040,
-  FSC-0075, FSC-0091, and FSP-1012.
-
-2. Purpose
-----------
-  
-  Along with the companion technical standard (FTS-5001) this document
-  defines the format and content of the nodelist for the FidoNet
-  International Hobby Network. The FTS-5001 is seperated into two
-  parts - the first part is a listing of authorized flags and the
-  second part is a registry of userflags. The registry is used to
-  prevent a userflag from being used for more than one meaning. The
-  registry is maintained by the Fidonet Technical Standards Committee
-  Working Group D (the Nodelist).
-
-3. Publication and Distribution
--------------------------------
-
-  The nodelist is published as an ASCII text file named NODELIST.nnn,
-  where nnn is the day-of-year of the publication date.
-  For actual distribution,  NODELIST.nnn is packed into an archive
-  file named NODELIST.Pnn,  where nn are the last two digits of day-of
-  -year and P is the compression format used as listed below.
-        A = .arc
-        Z = .zip
-        J = .arj
-        R = .rar
-  Since .zip is useable on most computer platforms, it is recommended
-  that this format be used for distribution of the Distribution
-  Nodelist.
-
-
-4. Contents
------------
-
-  As stated above,  NODELIST.nnn is an ASCII text file.  It contains
-  two kinds of lines,  comment lines and data lines.  Each line is
-  terminated with an ASCII carriage return and line feed character
-  sequence, and contains no trailing white-space (spaces, tabs, etc.).
-  The file is terminated with an end-of-file character, ASCII <EOF>
-  (1AH).
-
-  Comments lines contain a semicolon (;) in the first character
-  position followed by zero or more alphabetic characters called
-  "interest flags". A program which processes the nodelist may use
-  comment interest flags to determine the disposition of a comment
-  line.  The remainder of a comment line (with one exception, treated
-  below) is free-form ASCII text.
-
-  There are five interest flags defined as follows:
-
-     ;S This comment is of particular interest to Sysops.
-
-     ;U This comment is of particular interest to BBS users.
-
-     ;F This comment should appear in any formatted "Fido List".
-
-     ;A This comment is of general interest (shorthand for ;SUF).
-
-     ;E This comment is an error message inserted by a nodelist
-        generating program.
-
-     ;  This comment may be ignored by a nodelist processor.
-
-  The first line of a nodelist is a special comment line containing
-  identification data for the particular edition of the nodelist. The
-  following is an example of the first line of a nodelist:
-
-  ;A FidoNet Nodelist for Friday, July 3, 1987 --
-       Day number 184 : 15943
-
-  This line contains the general interest flag,  the day,  date,  and
-  day-of-year number of publication,  and ends with a 5-digit decimal
-  number with leading zeros, if necessary.  This number is the decimal
-  representation of a check value derived as follows:
-
-     Beginning with the first character of the second line,  a 16-bit
-     cyclic redundancy check (CRC) is calculated for the entire file,
-     including carriage return and line feed characters,  but not
-     including the terminating EOF character.  The check polynomial
-     used is the same one used for many file transfer protocols:
-
-          2**16 + 2**12 + 2**5 + 2**0
-
-  The CRC may be used to verify that the file has not been edited. The
-  importance of this will become evident in the discussion of NODEDIFF
-  below.  CRC calculation techniques are well documented in the
-  literature,  and will not be treated further here.
-
-  The content of the remaining comments in the nodelist are intended
-  to be informative. Beyond the use of interest flags for distribution
-  , a processing program need not have any interest in them.
-
-  A nodelist data line contains eight variable length "fields"
-  separated by commas (,).  No space characters are allowed in a data
-  line, and  underscore characters are used in lieu of spaces.  The
-  term "alphanumeric character" is defined as the portion of the ASCII
-  character set from 20 hex through 7E hex, inclusive.  The following
-  discussion defines the contents of each field in a data line.
-
-
-  Field 1: Keyword
-
-  The keyword field may be empty, or may contain exactly one keyword
-  approved by the Zone Coordinator Council. Current approved keywords
-  are:
-
-     Zone  --
-          Begins the definition of a geographic zone and define its
-          coordinator.  All the data lines following a line with the
-          "Zone" keyword down to, but not including, the next
-          occurrence of a "Zone" keyword, are regions, nets, and
-          nodes within the defined zone.
-
-     Region --
-          Begins the definition of a geographic region and defines its
-          coordinator.  All the data lines following a line with the
-          "Region" keyword down to, but not including, the next
-          occurrence of a "Zone", "Region", or "Host" keyword, are
-          independent nodes within the defined region.
-
-     Host --
-          Begins the definition of a local network and defines its
-          host. All the data lines following a line with the Host
-          keyword down to, but not including,  the next occurrence of
-          a "Zone", "Region", or "Host" keyword, are local nodes,
-          members of the defined local network.
-
-     Hub --
-          Begins the definition of a routing subunit within a
-          multilevel local network.  The hub is the routing focal
-          point for nodes listed below it until the next occurrence
-          of a "Zone", "Region", "Host", or "Hub" keyword.  The hub
-          entry MUST be a redundant entry,  with a unique number,
-          for one of the nodes listed below it.  This is necessary
-          because some nodelist processors eliminate these entries
-          in all but the local network.
-
-     Pvt --
-          Defines a private node with unlisted number.  Private nodes
-          are only allowed as members of local networks.
-
-     Hold --
-         Defines a node which is temporarily down,or  is a region/zone
-         independent node which is reachable via IP only. Mail may be
-         sent to it and is held by its host or coordinator.
-
-     Down --
-          Defines a node which is not operational.  Mail may NOT be
-          sent to it.  This keyword may not be used for longer than
-          two weeks on any single node,  at which point the "down"
-          node is to be removed from the nodelist.
-
-
-     <empty> --
-          Defines a normal node entry.
-
-
-
-  Field 2 - Zone/Region/Net/Node number
-
-     This field contains only numeric digits and is a number in the
-     range of 1 to 32767.  If the line had the "Zone",  "Region",  or
-     "Host" keyword,  the number is the zone, net, or region number,
-     and the node has an implied node number of 0, therfore the use of
-     a 0 in this field is strictly forbidden.  Otherwise,  the
-     number is the node number. The zone number, region or net number,
-     and the node number, taken together, constitute a node's FidoNet
-     address.
-
-     Zone numbers must be unique.  Region or net numbers must be
-     unique within their zone.  Hub numbers must be within their net.
-     Node numbers must be unique within their region (for regional
-     independents) or net (for members of a local network).  Duplicate
-     node numbers under different hubs within the same net are not
-     allowed.
-
-  Field 3 - Node name
-
-     This field may contain any alphanumeric characters other than
-     commas and spaces.  Underscores are used to represent spaces.
-     This is the name by which the node is known.
-     For IP nodes this field may alternately contain an ip address or
-     E-Mail address for email tunneling programs.
-
-  Field 4 - Location
-
-     This field may contain any alphanumeric characters other than
-     commas and spaces.  Underscores are used to represent spaces.
-     This field contains the location of the node.  It is usually
-     expressed as the primary local location (town,  suburb,  city,
-     etc.) plus the identifier of the regional geopolitical admin-
-     istrative district (state,  province,  department,  county,
-     etc.).  Wherever possible,  standard postal abbreviations for
-     the major regional district should be used (IL, BC, NSW, etc.).
-
-  Field 5 - Sysop name
-
-     This field may contain any alphanumeric characters other than
-     commas and spaces.  Underscores are used to represent spaces.
-     This is the name of the system operator.
-
-  Field 6 - Phone number
-
-     This field contains at least three and usually four numeric
-     subfields separated by dashes (-).  The fields are country code,
-     city or area code, exchange code, and number.  The various parts
-     of the phone number are frequently used to derive cost and
-     routing information, as well as what number is to be dialed.
-     A typical example of the data in a phone number field is 1-800-
-     555-1212, corresponding to country 1 (USA),  area 800 (inbound
-     WATS), exchange 555, and number 1212.
-
-     Alternatively, this field may contain the notation -Unpublished-
-     in the case of a private node.  In this case, the keyword "Pvt"
-     must appear on the line.
-
-    This field may also contain the IP address for an IP node
-    utilizing the country code of 000.
-
-  Field 7 - Baud rate
-
-     This field contains the maximum baud rate supported by the node.
-     (eg: 9600, 14400, 38400, etc)
-
-  Field 8 - Flags
-
-     This optional field contains data about the specific operation of
-     the node, such as file requests, modem protocol supported, etc.
-     Any text following the seventh comma on a data line is taken
-     collectively to be the flags field.  The required format is zero
-     or more subfields, separated by commas.  Each subfield consists
-     of a flag, possibly followed by a value. The authorized flags
-     for use in the distribution nodelist are distributed as in
-     FTS-5001 to facilitate additions and deletions of the authorized
-     flags without requiring an amendment to this FTS.
-
-     FTSC recognizes that the FidoNet Zone Coordinator Council with
-     the International Coordinator as the ZCC Chairman is the
-     ultimate authority over what appears in the FidoNet nodelist.
-     Also, FTSC is by definition a deliberative body,  and adding or
-     changing a flag may take a considerable amount of time.
-     Therefore, the  FidoNet International Coordinator or Zone
-     Coordinators may temporarily  make changes or additions to the
-     flags as defined in FTS-5001.  The FidoNet International
-     Coordinator/Zone Coordinators will then consult with FTSC over
-     the changes needed to FTS-5001 to reflect these temporary
-     changes.
-
-
-
-     The following are examples of nodelist data lines:
-
-  Host,102,SOCALNET,Los_Angeles_CA,Richard_Mart,1-213-874-9484,2400,XP
-  
-  ,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
-  
-  ,102,fido.tree.com,Los_Angeles_CA,Bill_Smart,1-213-555-1212,9600,
-  CM,IP,ITN
-
-
-5. Nodediff
------------
-
-  With more than twenty thousand nodes as of this date,  the nodelist,
-  even in archive form,  is a substantial document (or file).  Since
-  distribution is via electronic file transfer,  this file is NOT
-  routinely distributed.  Instead, when a new nodelist is prepared, it
-  is compared with the previous week's nodelist, and a file containing
-  only the differences is created and distributed.
-
-  The distribution file,  called NODEDIFF.nnn,  where nnn is the
-  day-of-year of publication, is actually an editing script which will
-  transform the previous week's nodelist into the current nodelist.  A
-  definition of its format follows:
-
-  The first line of NODEDIFF.nnn is an exact copy of the first line of
-  LAST WEEK'S nodelist. This is used as a first-level confidence check
-  to insure that the right file is being edited.  The second and sub-
-  sequent lines are editing commands and editing data.
-
-  There are three editing commands and all have the same format:
-
-          <command><number>
-
-     <command> is a 1-letter command;  A,  C,  or D.  <number> is a
-     decimal number greater than zero,  and defines the number of
-     lines to be operated on by the command.  Each command appears on
-     a line by itself.  The commands have the following meanings:
-
-     Ann - Add the following nn lines to the output file.
-
-     Cnn - Copy nn unchanged lines from the input to the output file.
-
-     Dnn - Delete  nn lines from the input file.
-
-  The following illustrate how the first few lines of NODEDIFF.213
-  might look:
-
-     ;A Friday, July 25, 1986 -- Day number 206 : 27712
-     D2
-     A2
-     ;A Friday, August 1, 1986 -- Day number 213 : 05060
-     ;A
-     C5
-
-  This fragment illustrates all three editing commands. The first line
-  is the first line from NODELIST.206.  The next line says "delete the
-  first two lines" from NODELIST.206.  These are the identification
-  line and the line following it.  The next command says "add the next
-  two lines" to NODELIST.213.  The two data lines are followed by a
-  command which says "copy five unchanged lines" from NODELIST.206 to
-  NODELIST .213.  Notice that the first line added will ALWAYS contain
-  the new nodelist's CRC.
-
-  Since only the differences will be distributed,  it is important to
-  insure the accuracy of the newly created nodelist.  This is the
-  function of the CRC mentioned above.  It is sufficient for a program
-  designed to perform the above edits to pick the CRC value from the
-  first line added to the output file, then compute the CRC of the
-  rest of the output file.  If the two CRCs do not agree,  one of the
-  input files has been corrupted.  If they do agree,  the probability
-  is very high (but not 100%) that the output file is accurate.
-
-  For actual distribution, NODEDIFF.nnn is packed into an archive file
-  named NODEDIFF.Pnn,  where nn are the last two digits of day-of-year
-  and P is the compression format used as listed below.
-        A = .arc
-        Z = .zip
-        J = .arj
-        R = .rar
-  Since .zip is useable on most computer platforms, it is recommended
-  that this format be used for distribution of the Distribution
-  Nodediff.
-
-A. References
--------------
-
-  [FTS-5] "The distribution nodelist", Ben Baker, Rick Moore.
-  February 1989. Obsoleted by this document.
-  
-  [FSC-9] "Nodelist flag Changes draft document", Ray Gwinn, David
-  Dodell. November 1987. Obsoleted by this document.
-  
-  [FSC-40] "Extended Modem Handling", Michael Shiels. February 1990.
-  Obsoleted by this document.
-  
-  [FSC-75] "ISDN capability flags in the nodelist", Jan Ceuleers.
-  October 1993. Obsoleted by this document.
-  
-  [FSC-91] "ISDN nodelist flags", Arjen Lentz.
-  October 1995. Obsoleted by this document.
-  
-  [FSP-1012] "Integration of IP Nodes in the nodelist", Lothar Behet
-  June 1999.  
-
-B. Contact Data
----------------
-  
-  David Hallford  
-  Fidonet: 1:208/103
-
-  Andreas Klein
-  Fidonet: 2:2480/47
-  E-mail:  akx@gmx.net
-  
-  Michael McCabe
-  Fidonet: 1:297/11
-  
-  Odinn Sorensen
-  Fidonet: N/A
-  E-mail:  odinn@goldware.dk
-  WWW:     http://www.goldware.dk
-
-  Colin Turner
-  Fidonet: 2:443/13
-  E-mail:  ct@piglets.com
-  WWW:     http://www.piglets.com
-
-C. History
-----------
-
-   Rev.1, 19990627: Initial Release. Principal Author David Hallford
-
-
- - -BackGo Back - - - diff --git a/html/ftsc/fts-5001.html b/html/ftsc/fts-5001.html deleted file mode 100644 index 235993e0..00000000 --- a/html/ftsc/fts-5001.html +++ /dev/null @@ -1,403 +0,0 @@ - - - -The Distribution Nodelist. - - - - - -**********************************************************************
-FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication:    FTS-5001
-Revision:       1
-Title:          NODELIST FLAGS AND USERFLAGS
-Author(s):      Colin Turner, Andreas Klein, Michael McCabe,
-                David Hallford, Odinn Sorensen
-
-Revision Date:  27 June 1999
-Expiry Date:    27 June 2001 
-----------------------------------------------------------------------
-Contents:
-                1. Authorized Flags
-                2. Userflags
-----------------------------------------------------------------------
-
-Status of this document
------------------------
-
-  This document is a Fidonet Standard (FTS).
-
-  This document specifies a Fidonet standard for the Fidonet
-  community.
-
-  This document is released to the public domain, and may be used,
-  copied or modified for any purpose whatever.
-
-
-Abstract
---------
-
-  Current practice for Fidonet Technology Networks (FTN) is to
-  maintain a nodelist used to store the details of the nodes in
-  the network, and the network structure. Flags are used in this
-  nodelist to aid automatic and manual control of various tasks.
-
-
-1. Authorized flags
--------------------
-
- Flags authorized for use in the Fidonet nodelist:
-
-  A: OPERATING CONDITION FLAGS:
-
-          Flag      Meaning
-
-          CM        Node accepts mail 24 hours a day
-          MO        Node does not accept human callers
-          LO        Node accepts calls Only from Listed
-                    FidoNet addresses
-
-  B. MODEM FLAGS:
-     The following flags define modem protocols supported:
-
-          Flag      Meaning
-
-          V21       CCITT V.21     300 bps   full duplex
-          V22       CCITT V.22     1200 bps  full duplex
-          V29       CCITT V.29     9600 bps  half duplex
-          V32       CCITT V.32     9600 bps  full duplex
-          V32b      ITU-T V.32 bis 14400 bps full duplex
-          V32T      V.32 Terbo
-          V33       CCITT V.33
-          V34       CCITT V.34
-          HST       USR Courier HST
-          H14       USR Courier HST 14.4
-          H16       USR Courier HST 16.8
-          H96       Hayes V9600
-          MAX       Microcom AX/96xx series
-          PEP       Packet Ensemble Protocol
-          CSP       Compucom Speedmodem
-          ZYX       Zyxel series
-          VFC       V.Fast Class
-          Z19       Zyxel 19,200 modem protocol
-          V90C      ITU-T V.90 modem Client 
-          V90S      ITU-T V.90 Server. 
-          X2C       US Robotics x2 client. 
-          X2S       US Robotics x2 server. 
-
-
-
-     The following flags define type of error correction available. A
-     separate error correction flag should not be used when the error
-     correction type can be determined by the modem flag. For instance
-     a modem flag of HST implies MNP.
-
-          Flag      Meaning
-
-          MNP       Microcom Networking Protocol error correction
-                    of type MNP1 to MNP4
-          V42       LAP-M error correction w/fallback to MNP
-
-  C: COMPRESSION FLAGS:
-
-     The following flags define the type(s) of compression of mail
-     packets supported.
-
-          Flag      Meaning
-
-          MN        No compression supported
-
-     The following flags define the type(s) of data compression
-     available.
-
-          V42b      ITU-T V42bis
-
-
-  D: FILE/UPDATE REQUEST FLAGS:
-
-     The following flags indicate the types of file/update requests
-     supported.
-
-
-  |--------------------------------------------------|
-  |      |         Bark        |        WaZOO        |
-  |      |---------------------|---------------------|
-  |      |   File   |  Update  |   File   |  Update  |
-  | Flag | Requests | Requests | Requests | Requests |
-  |------|----------|----------|----------|----------|
-  | XA   |    Yes   |    Yes   |    Yes   |    Yes   |
-  | XB   |    Yes   |    Yes   |    Yes   |    No    |
-  | XC   |    Yes   |    No    |    Yes   |    Yes   |
-  | XP   |    Yes   |    Yes   |    No    |    No    |
-  | XR   |    Yes   |    No    |    Yes   |    No    |
-  | XW   |    No    |    No    |    Yes   |    No    |
-  | XX   |    No    |    No    |    Yes   |    Yes   |
-  |--------------------------------------------------|
-
-  E: GATEWAY FLAG:
-
-     The following flag defines gateways to other domains (networks).
-
-          Flag      Meaning
-
-          Gx..x     Gateway to domain 'x..x', where 'x..x` is a string
-                    of alphanumeric characters. Valid values for
-                    'x..x' are assigned by the FidoNet International
-                    Coordinator.  Current valid values of 'x..x' may
-                    be found in the notes at the end of the FidoNet
-                    nodelist.
-
-  F: MAIL PERIOD FLAGS:
-     The following flags define the dedicated mail periods supported.
-     They have the form "#nn" or !nn where nn is the UTC hour the mail
-     period begins,  # indicates Bell 212A compatibility,  and !
-     indicates incompatibility with Bell 212A.
-
-          Flag      Meaning
-
-
-           #01       Zone 5 mail hour (01:00 - 02:00 UTC)
-           #02       Zone 2 mail hour (02:30 - 03:30 UTC)
-           #08       Zone 4 mail hour (08:00 - 09:00 UTC)
-           #09       Zone 1 mail hour (09:00 - 10:00 UTC)
-           #18       Zone 3 mail hour (18:00 - 19:00 UTC)
-           #20       Zone 6 mail hour (20:00 - 21:00 UTC)
-
-                    NOTE:  When applicable,  the mail period flags may
-                    be strung together with no intervening commas, eg. 
-                    "#02#09".  Only mail hours other than that
-                    standard within a node's zone should be given.
-                    Since observance of mail hour within one's zone is
-                    mandatory,  it should not be indicated.
-
-  G: ISDN CAPABILTY FLAGS:
-
-   Nodelist  Specification of minimal support required for this flag;
-   flag      any additional support to be arranged via agreement 
-           between users
-
-   V110L     ITU-T V.110 19k2 async ('low').
-   V110H     ITU-T V.110 38k4 async ('high').
-   V120L     ITU-T V.120 56k async, layer 2 framesize 259, window 7,
-             modulo 8.
-   V120H     ITU-T V.120 64k async, layer 2 framesize 259, window 7,
-             modulo 8.
-   X75       ITU-T X.75 SLP (single link procedure) with 64kbit/s B
-             channel; layer 2 max.framesize 2048, window 2, non-ext.
-             mode (modulo 8); layer 3 transparent (no packet layer).
-   ISDN      Other configurations. Use only if none of the above
-             fits.
-             
-   NOTE: No flag implies another. Each capability MUST be specifically
-       listed.
-   If no modem connects are supported, the nodelist speed field should
-   be 300.
-
-   Conversion from old to new ISDN capability flags:
-     ISDNA -> V110L
-     ISDNB -> V110H
-     ISDNC -> X75
-
-  H: INTERNET CAPABILITY FLAGS: 
-
-    FLAG   MEANING
-
-    IBN - denotes a system that does BINKP  
-    IFC - denotes a system that is capable of RAW or IFCICO 
-    ITN - denote a system that does TELNET 
-    IVM - denotes a system that is capable of VMODEM 
-    IFT - denotes a system that allows FTP             
-    ITX - denotes a system that uses TransX encoding for email
-          tunneling
-    IUC - denotes a system that uses UUEncode for email tunneling      
-    IMI - denotes a system which uses MIME encoding for email
-          tunneling
-    ISE - denotes a system which supports SEAT receipts for anonymous
-          mail
-    IP  - denotes a system that can receive TCP/IP connects using a
-          protocol that is not covered by any other flag. 
-    IEM - is a deprecated flag, and new implementations must not
-          write it in nodelist entries. This was used as a single
-          placeholder for the InterNet address of the system if it
-          supported several transport methods. Instead of placing
-          the system address in the deprecated form specified below
-          in each flag, the address would be placed once only in this
-          flag. Implementations may need to parse this information
-          from nodelists created with older programs.
-
-  Conversion from old Internet capabilty flags to the new flags:
-
-    BND -> IBN
-    TEL -> ITN
-    TELNET -> ITN
-    VMD -> IVM
-    TCP -> IP
-
-  The Internet Address should be placed in the BBS name field.
-   
-  Previous usage has placed the InterNet address as part of the
-  I-flag (for example ITX:r10_tx@thevision.net); in this format the
-  flag, colon, and address combined cannot exceed 32 characters.
-  However, this practice is deprecated, and new implementations must
-  not place address data in the flag section of the nodelist entry,
-  implementations may however be required to read this data from the
-  flag section.
-
-  Telnet default port is 23. If the port is not 23 then the port
-  number must be placed after the ITN flag (eg ITN:60177) if the
-  Telnet address is part of the ITN flag (eg ITN:farsi.dynip.com) then
-  the port number should be last (eg ITN:farsi.dynip.com:60177) always
-  remember that the flag cannot exceed 32 characters total.
-  
-  The default ports for other protocols are shown below, and changes
-  from the default port must be flagged in a similar way.
-   
-  Protocol      Flag    Default Port
-  
-  FTP           IFT     21
-  BINKP         IBN     24554
-  RAW/IFCICO    IFC     60179
-  VMODEM        IVM     3141
-
-  Actual IP addresses can also be placed in the phone number field
-  using  the country code of 000.
-
-  I: SYSTEM ONLINE USERFLAGS
-
-   The flag Tyz is used by non-CM nodes online not only during ZMH,
-   y is a letter indicating the start and z a letter indicating the
-   end of the online period as defined below (times in UTC):
-
-        A  0:00,  a  0:30,   B  1:00,  b  1:30,   C  2:00,  c  2:30,
-        D  3:00,  d  3:30,   E  4:00,  e  4:30,   F  5:00,  f  5:30,
-        G  6:00,  g  6:30,   H  7:00,  h  7:30,   I  8:00,  i  8:30,
-        J  9:00,  j  9:30,   K 10:00,  k 10:30,   L 11:00,  l 11:30,
-        M 12:00,  m 12:30,   N 13:00,  n 13:30,   O 14:00,  o 14:30,
-        P 15:00,  p 15:30,   Q 16:00,  q 16:30,   R 17:00,  r 17:30,
-        S 18:00,  s 18:30,   T 19:00,  t 19:30,   U 20:00,  u 20:30,
-        V 21:00,  v 21:30,   W 22:00,  w 22:30,   X 23:00,  x 23:30.
-
-   For example TuB shows an online period from 20:30 until 1:00 UTC.
-
-   Daylight saving time
-
-   If a node changes online times with respect to UTC when daylight
-   saving time becomes effective (which would be the case with most
-   part time nodes), then this is to be taken into account when
-   assigning this flag. An online times flag assigned to a node should
-   not be altered for the specific purpose of adjusting due to
-   daylight saving time, since large difference files (NODEDIFF's)
-   would result if every node was allowed to do this, e.g. my node
-   used to be online from 2300 to 0800 in local time, which in winter
-   is UTC, but in the summer it becomes BST (British Summer Time).
-   This is one hour ahead of UTC, and the corresponding availability
-   times of my node during the summer period were 2200 to 0700 UTC.
-   Therefore my online times flag would have indicated availability
-   between the hours of 2300 and 0700 UTC, the daily time period
-   encompassing both times, so the flag would be TXH.
-
-2. Userflags
-------------
-
-  Registry of Userflags
-
-  A. FORMAT OF USER FLAGS
-
-     U,x..x
-               A user-specified string, which may contain any
-               alphanumeric character except blanks.  This string may
-               contain one to thirty-two characters of information
-               that may be used to add user-defined data to a specific
-               nodelist entry.  The character "U" must not be
-               repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ".
-               The 32 character limitation is per userflag, not for
-               the total of all userflags.
-
-               New implementations must place a comma after the
-               initial "U" before the user flags. Some
-               implementations will not place a separating comma
-               betweent the "U" and the first user flag, but this
-               practice is deprecated. Implementations should be
-               prepared to read flags in this format, and must strip
-               the "U" from the flag before analysis in this case.
-
-               Entries following the "U" flag must be of a technical
-               or administrative nature.  While experimentation of new
-               software functions using this flag is encouraged,
-               advertisement is strictly prohibited.
-
-               For applications other than those shown, or if you
-               have questions concerning the use of this field, please
-               contact your Regional or Zone Coordinator.
-
-
-  B: MAIL ORIENTED USER FLAGS:
-
-     ZEC       Zone EchoMail Coordinator. Not more than one entry
-               in the zone  segment may carry this flag and that entry
-               must be the current Zone EchoMail Coordinator.
-
-     REC       Regional EchoMail Coordinator. Not more than one
-               entry in any region may carry this flag and that entry
-               must be the current Regional EchoMail Coordinator.
-
-     NEC       Network EchoMail coordinator. Not more than one entry
-               in any net may carry this flag and that entry must be
-               the current Network EchoMail Coordinator of that Net.
-
-
-     SDS       Software Distribution System
-
-     SMH       Secure Mail Hub
-
-     NC        Network Coordinator. This flag is ONLY to be used by
-               the Network Coordinator of a net which has split the
-               duties of NC and Host and the NC does NOT occupy the
-               Net/0 position in the nodelist.
-
-
-A. Contact Data
----------------
-  
-  David Hallford  
-  Fidonet: 1:208/103
-
-  Andreas Klein
-  Fidonet: 2:2480/47
-  E-mail:  akx@gmx.net
-  
-  Michael McCabe
-  Fidonet: 1:297/11
-  
-  Odinn Sorensen
-  Fidonet: N/A
-  E-mail:  odinn@goldware.dk
-  WWW:     http://www.goldware.dk
-
-  Colin Turner
-  Fidonet: 2:443/13
-  E-mail:  ct@piglets.com
-  WWW:     http://www.piglets.com
-
-
-B. History
-----------
-
-   Rev.1, 19990627: Initial Release. Principal Author David Hallford
-
-
- - -BackGo Back - - - diff --git a/html/ftsc/ftscprod.html b/html/ftsc/ftscprod.html deleted file mode 100755 index 11c804db..00000000 --- a/html/ftsc/ftscprod.html +++ /dev/null @@ -1,312 +0,0 @@ - - - -FTSC Product ID List. - - - - -

FTSC Product codes 22 jan 2000

-

-0000,Fido,MS-DOS,Packer/mailer,Tom_Jennings,1:125/111
-0001,Rover,MS-DOS,Packer/mailer,Bob_Hartman,1:104/501
-0002,SEAdog,MS-DOS,Packer/mailer,Thom_Henderson,1:107/542.1
-0003,WinDog,MS-DOS,Mailer,Solar_Wind_Computing,1:115/333
-0004,Slick-150,HP-150,Packer/mailer,Jerry_Bain,????
-0005,Opus,MS-DOS,Packer/mailer,Doug_Boone,1:124/4227
-0006,Dutchie,MS-DOS,Packer/mailer,Henk_Wevers,2:500/1
-0007,WPL_Library,Amiga,Mailer,Russell_McOrmand,1:163/109
-0008,Tabby,Macintosh,Packer/mailer,Michael_Connick,1:107/412
-0009,SWMail,OS/2,Mailer,Solar_Wind_Computing,1:115/333
-000A,Wolf-68k,CPM-68k,Packer/mailer,Robert_Heller,1:321/153
-000B,QMM,QNX,Packer/mailer,Rick_Duff,1:167/201
-000C,FrontDoor,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
-000D,GOmail,MS-DOS,Packer,Scott_Green,????
-000E,FFGate,MS-DOS,Packer,Ruedi_Kneubuehler,2:301/580
-000F,FileMgr,MS-DOS,Packer,Erik_van_Emmerik,2:281/611
-0010,FIDZERCP,MS-DOS,Packer,Thorsten_Seidel,2:242/55
-0011,MailMan,MS-DOS,Packer,Ron_Bemis,1:124/1113
-0012,OOPS,MS-DOS,Packer,Tom_Kashuba,1:322/379
-0013,GS-Point,Atari_ST,Packer/mailer,Harry_Lee,1:124/4230
-0014,BGMail,????,????,Ray_Gwinn,1:265/104
-0015,ComMotion/2,OS/2,Packer/mailer,Michael_Buenter,2:301/602
-0016,OurBBS_Fidomailer,MS-DOS/Unix/Coherent,Packer/mailer,Brian_Keahl,1:133/524
-0017,FidoPcb,MS-DOS,Packer,Matjaz_Koce,2:380/100
-0018,WimpLink,Archimedes,Packer/mailer,Remco_de_Vreugd,2:283/307
-0019,BinkScan,MS-DOS,Packer,Shawn_Stoddard,1:362/101
-001A,D'Bridge,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
-001B,BinkleyTerm,MS-DOS,Mailer,Vince_Perriello,1:343/491
-001C,Yankee,MS-DOS,Packer,Randy_Edwards,????
-001D,uuGate,MS-DOS,Packer,Geoff_Watts,3:690/710
-001E,Daisy,Apple_][,Packer/mailer,Raymond_&_Ken_Lo,3:700/1
-001F,Polar_Bear,????,Packer/mailer,Kenneth_McLeod,1:101/190
-0020,The-Box,MS-DOS/Atari_ST,Packer/mailer,Jac_Kersing/Arjen_Lentz,2:283/333
-0021,STARgate/2,OS/2,Packer/mailer,Shawn_Stoddard,1:362/101
-0022,TMail,MS-DOS,Packer,Larry_Lewis,3:713/600.1701
-0023,TCOMMail,MS-DOS,Packer/mailer,Mike_Ratledge,1:372/888
-0024,GIGO,MS-DOS,Packer,Jason_Fesler,1:203/7707,,940228
-0025,RBBSMail,MS-DOS,Packer,Jan_Terpstra,2:512/10
-0026,Apple-Netmail,Apple_][,Packer/mailer,Bill_Fenner,1:129/87
-0027,Chameleon,Amiga,Mailer,Juergen_Hermann,2:241/2.12
-0028,Majik_Board,MS-DOS,Packer/mailer,Dale_Barnes,1:3601/14.20
-0029,QM,MS-DOS,Packer,George_Peace,1:270/101
-002A,Point_And_Click,Amiga,Packer,Rob_Tillotson,1:201/40.302
-002B,Aurora_Three_Bundler,MS-DOS,Packer,Oliver_McDonald,????
-002C,FourDog,MS-DOS,Packer,Shay_Walters,1:376/12
-002D,MSG-PACK,MS-DOS,Packer,Tom_Hendricks,1:261/662
-002E,AMAX,MS-DOS,Packer,Alan_Applegate,1:104/36
-002F,Domain_Communication_System,????,????,Hal_Duprie,1:101/106
-0030,LesRobot,????,Packer,Lennart_Svensonn,2:501/2
-0031,Rose,MS-DOS,Packer/mailer,Glen_Jackson,1:100/617
-0032,Paragon,Amiga,Packer/mailer,Jon_Radoff,1:322/545
-0033,BinkleyTerm/oMMM/ST,Atari_ST,Packer/mailer,Bill_Scull,1:363/112,,19951209
-0034,StarNet,Atari_ST,Mailer,Eric_Drewry,1:322/566
-0035,ZzyZx,MS-DOS,Packer,Jason_Steck,1:124/424
-0036,QEcho,MS-DOS,Packer,The_QuickBBS_Group,1:363/1701
-0037,BOOM,MS-DOS,Packer,Andrew_Farmer,1:243/1
-0038,PBBS,Amiga,Packer/mailer,Todd_Kover,1:261/1028
-0039,TrapDoor,Amiga,Mailer,Maximilian_Hantsch,2:310/6
-003A,Welmat,Amiga,Mailer,Russell_McOrmand,1:163/109
-003B,NetGate,Unix-386,Packer,David_Nugent,3:632/348
-003C,Odie,MS-DOS,Mailer,Matt_Farrenkopf,1:105/376
-003D,Quick_Gimme,CPM-80/MS-DOS,Packer/mailer,Laeeth_Isaacs,2:254/18
-003E,dbLink,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
-003F,TosScan,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
-0040,Beagle,MS-DOS,Mailer,Alexander_Holy,2:310/90
-0041,Igor,MS-DOS,Mailer,Harry_Lee,1:124/4230
-0042,TIMS,MS-DOS,Packer/mailer,Bit_Bucket_Software,1:104/501
-0043,Phoenix,MS-DOS,Packer/mailer,International_Telecommunications,1:296/5,,19930624
-0044,FrontDoor_APX,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
-0045,XRS,MS-DOS,Packer,Mike_Ratledge,1:372/888
-0046,Juliet_Mail_System,Amiga,Packer,Gregory_Kritsch,1:163/109.30
-0047,Jabberwocky,Macintosh,Packer,Eric_Larson,1:2605/620
-0048,XST,MS-DOS,Packer,Wayne_Michaels,1:380/100
-0049,MailStorm,Amiga,Packer,Russel_Miranda,1:268/106
-004A,BIX-Mail,????,Mailer,Bob_Hartman,1:104/501
-004B,IMAIL,MS-DOS,Packer,IMAIL_INC.,2:246/47
-004C,FTNGate,MS-DOS,Packer,Jason_Steck,1:104/424
-004D,RealMail,MS-DOS,Packer,Taine_Gilliam,1:372/42
-004E,Lora-CBIS,MS-DOS,Mailer,Marco_Maccaferri,2:332/402
-004F,TDCS,PDP-11,Packer/mailer,Terry_Ebdon,2:254/6
-0050,InterMail,MS-DOS,Packer/mailer,Peter_Stewart,1:369/35
-0051,RFD,MS-DOS,Packer,Doug_Belkofer,1:234/10
-0052,Yuppie!,MS-DOS,Packer,Leo_Moll,2:242/2
-0053,EMMA,MS-DOS,Packer,Johan_Zwiekhorst,2:292/100
-0054,QBoxMail,QDOS,Packer/mailer,Jan_Bredenbeek,2:283/500
-0055,Number_4,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
-0056,Number_5,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
-0057,GSBBS,MS-DOS,Packer,Michelangelo_Jones,1:260/244
-0058,Merlin,MS-DOS,Packer/mailer,Mark_Lewis,2:258/25
-0059,TPCS,MS-DOS,Packer,Mikael_Kjellstrom,2:201/211
-005A,Raid,MS-DOS,Packer,George_Peace,1:270/101
-005B,Outpost,MS-DOS,Packer/mailer,Mike_Dailor,????
-005C,Nizze,MS-DOS,Packer,Tomas_Nielsen,2:205/202
-005D,Armadillo,Macintosh,Packer,Erik_Sea,1:221/109
-005E,rfmail,Unix,Packer/mailer,Per_Lindqvist,2:201/332
-005F,Msgtoss,MS-DOS,Packer,Mike_Zakharoff,1:343/36
-0060,InfoTex,MS-DOS,Packer/mailer,Jan_Spooren,2:292/852
-0061,GEcho,MS-DOS,Packer,Gerard_van_der_Land,2:283/555,951209
-0062,CDEhost,MS-DOS,Packer,Dennis_D'Annunzio,1:379/28
-0063,Pktize,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
-0064,PC-RAIN,MS-DOS,Packer/mailer,Ray_Hyder,1:272/40
-0065,Truffle,MS-DOS/OS2,Mailer,Mike_Rissa,2:504/59
-0066,Foozle,Amiga,Packer,Peer_Hasselmeyer,2:247/4
-0067,White_Pointer,Macintosh,Packer/mailer,Alastair_Rakine,3:680/820
-0068,GateWorks,MS-DOS,Packer,Jamie_Penner,1:153/1025
-0069,Portal_of_Power,MS-DOS,Mailer,Soren_Ager,2:230/12
-006A,MacWoof,Macintosh,Packer/mailer,Craig_Vaughan,1:109/342
-006B,Mosaic,MS-DOS,Packer,Christopher_King,1:103/315
-006C,TPBEcho,MS-DOS,Packer,Gerd_Qualmann,2:242/1
-006D,HandyMail,MS-DOS,Packer/mailer,jim_nutt,1:114/30
-006E,EchoSmith,MS-DOS,Packer,Noel_Crow,1:170/409
-006F,FileHost,MS-DOS,Packer,Mark_Cole,2:252/186
-0070,SFTS,MS-DOS,Packer,Bruce_Anderson,1:3402/6
-0071,Benjamin,MS-DOS,Packer/mailer,Stefan_Graf,2:245/4.5436
-0072,RiBBS,OS9_(COCO),Packer/mailer,Ron_Bihler,1:104/54
-0073,MP,MS-DOS,Packer,Ivan_Leong,6:600/28
-0074,Ping,MS-DOS,Packer,David_Nugent,3:632/348
-0075,Door2Europe,MS-DOS,Packer/mailer,Michaela_Schoebel,2:247/14
-0076,SWIFT,MS-DOS,Packer/mailer,Hanno_van_der_Maas,2:500/2
-0077,WMAIL,MS-DOS,Packer,Silvan_Calarco,2:334/100.2
-0078,RATS,MS-DOS,Packer,Jason_DeCaro,1:260/205
-0079,Harry_the_Dirty_Dog,OS2,Mailer/packer,George_Edwards,3:632/340.7
-007A,Maximus-CBCS,MS-DOS/OS2,Packer,Scott_Dudley,1:249/106
-007B,SwifEcho,MS-DOS,Packer,Dana_Bell,1:3801/8
-007C,GCChost,Amiga,Packer,Davide_Massarenti,2:332/505.3
-007D,RPX-Mail,MS-DOS,Packer,Joerg_Wirtgen,2:241/4034
-007E,Tosser,MS-DOS,Packer,Albert_Ng,6:700/185
-007F,TCL,MS-DOS,Packer,Ulf_Hedlund,2:201/602
-0080,MsgTrack,MS-DOS,Packer,Andrew_Farmer,1:243/1
-0081,FMail,MS-DOS/DOS_DPMI/OS2/WIN32,Packer,Folkert_Wijnstra,2:283/619
-0082,Scantoss,MS-DOS,Packer,Michael_Matter,2:243/44.3443
-0083,Point_Manager,Amiga,Packer,Pino_Aliberti,2:335/602.2,,19931012
-0084,IMBINK,MS-DOS,Packer,Mike_Hartmann,2:246/48
-0085,Simplex,MS-DOS/OS2,Packer,Chris_Laforet,1:152/401
-0086,UMTP,MS-DOS,Packer,Byron_Copeland,1:272/26
-0087,Indaba,MS-DOS,Packer,Pieter_Muller,5:7102/11
-0088,Echomail_Engine,MS-DOS,Packer,Joe_Jared,1:103/200
-0089,DragonMail,OS2,Packer,Patrick_O'Riva,1:143/37
-008A,Prox,MS-DOS,Packer,Gerhard_Hoogterp,2:283/1.2
-008B,Tick,MS-DOS/OS2,Packer,Barry_Geller,1:266/12
-008C,RA-Echo,MS-DOS,Packer,Roger_Kirchhoff,2:245/4
-008D,TrapToss,Amiga,Packer,Maximilian_Hantsch,2:310/6
-008E,Babel,MS-DOS/OS2,Packer,Jorgen_Abrahamsen,2:230/100.9
-008F,UMS,Amiga,Packer,Martin_Horneffer,2:242/7.9
-0090,RWMail,MS-DOS,Packer,Remko_Westrik,2:285/309.5
-0091,WildMail,MS-DOS,Packer,Derek_Koopowitz,1:161/502
-0092,AlMAIL,MS-DOS,Packer,Alan_Leung,1:348/207
-0093,XCS,MS-DOS,Packer,Rudi_Kusters,2:512/34.4
-0094,Fone-Link,MS-DOS,Packer/mailer,Chris_Sloyan,1:269/602
-0095,Dogfight,MS-DOS,Packer,Chris_Tyson,2:256/36
-0096,Ascan,MS-DOS,Packer,Arjen_van_Loon,2:281/1.397
-0097,FastMail,MS-DOS,Packer,Jan_Berends,2:282/5
-0098,DoorMan,MS-DOS,Mailer,Christopher_Dean,1:105/70
-0099,PhaedoZap,Atari_ST,Packer,Jeff_Mitchell,1:229/422
-009A,SCREAM,MS-DOS,Packer/mailer,Jem_Miller,1:147/33
-009B,MoonMail,MS-DOS,Packer/mailer,Hasse_Wigdahl,2:206/101
-009C,Backdoor,Sinclair_QL,Packer,Erik_Slagter,2:283/500.3
-009D,MailLink,Archimedes,Packer/mailer,Jan-Jaap_v._d._Geer,2:500/133.1138
-009E,Mail_Manager,MS-DOS,Packer,Andreas_Brodowski,2:241/4006
-009F,Black_Star,Xenix_386,Packer/mailer,Jac_Kersing,2:283/333
-00A0,Bermuda,Atari_ST/MS-DOS,Packer,Jac_Kersing,2:283/333
-00A1,PT,MS-DOS,Packer/mailer,Jerry_Andrew,1:109/426
-00A2,UltiMail,MS-DOS,Mailer,Brett_Floren,1:363/1000
-00A3,GMD,MS-DOS,Packer,John_Souvestre,1:396/1
-00A4,FreeMail,MS-DOS,Packer,Chad_Nelson,1:109/536
-00A5,Meliora,MS-DOS,Packer,Erik_van_Riper,1:107/230
-00A6,Foodo,CPM-80,Packer/mailer,Ron_Murray,3:690/640.7
-00A7,MSBBS,CPM-80,Packer,Marc_Newman,1:106/601
-00A8,Boston_BBS,MS-DOS,Packer/mailer,Tom_Bradford,1:101/625
-00A9,XenoMail,MS-DOS,Packer/mailer,Noah_Wood,1:284/14
-00AA,XenoLink,Amiga,Packer/mailer,Jonathan_Forbes,1:250/642
-00AB,ObjectMatrix,MS-DOS,Packer,Roberto_Ceccarelli,2:332/305.1
-00AC,Milquetoast,Win3/MS-DOS,Mailer,Vince_Perriello,1:343/491
-00AD,PipBase,MS-DOS,Packer,Roberto_Piola,2:334/306
-00AE,EzyMail,MS-DOS,Packer,Peter_Davies,3:636/204
-00AF,FastEcho,MS-DOS,Packer,Tobias_Burchhardt,2:245/39
-00B0,IOS,Atari_ST/TT,Packer,Rinaldo_Visscher,2:280/3.1
-00B1,Communique,MS-DOS,Packer,Ian_Harris,3:620/251
-00B2,PointMail,MS-DOS,Packer,Michele_Clinco,2:331/302.11
-00B3,Harvey's_Robot,MS-DOS,Packer,Harvey_Parisien,1:249/114
-00B4,2daPoint,MS-DOS,Packer,Ron_Pritchett,1:376/74
-00B5,CommLink,MS-DOS,Mailer,Steve_Shapiro,1:382/35
-00B6,fronttoss,MS-DOS,Packer,Dirk_Astrath,2:241/5603
-00B7,SysopPoint,MS-DOS,Packer,Rudolf_Heeb,2:243/44
-00B8,PTMAIL,MS-DOS,Packer,Arturo_Krogulski,2:341/27.7
-00B9,MHS,MS-DOS/OS2/WINNT,Packer/mailer,Matthias_Hertzog,2:301/402,,19940310
-00BA,DLGMail,Amiga,Packer,Steve_Lewis,1:114/52
-00BB,GatePrep,MS-DOS,Packer,Andrew_Allen,1:382/92
-00BC,Spoint,MS-DOS,Packer,Conrad_Thompson,1:130/29.106
-00BD,TurboMail,MS-DOS,Packer,B._J._Weschke,1:2606/403
-00BE,FXMAIL,MS-DOS,Packer,Kenneth_Roach,1:208/401
-00BF,NextBBS,MS-DOS,Packer/mailer,Tomas_Hood,1:352/777
-00C0,EchoToss,MS-DOS,Packer,Mikel_Beck,1:107/218
-00C1,SilverBox,Amiga,Packer,David_Lebel,1:240/516
-00C2,MBMail,MS-DOS,Packer,Ruud_Uphoff,2:500/116.1928
-00C3,SkyFreq,Amiga,Packer,Luca_Spada,2:331/106
-00C4,ProMailer,Amiga,Mailer,Ivan_Pintori,2:335/311.21
-00C5,Mega_Mail,MS-DOS,Packer/mailer,Mirko_Mucko,2:242/94
-00C6,YaBom,MS-DOS,Packer,Berin_Lautenbach,3:620/248
-00C7,TachEcho,MS-DOS,Packer,Tom_Zacios,1:107/376
-00C8,XAP,MS-DOS,Packer,Jeroen_Smulders,2:512/1.8
-00C9,EZMAIL,MS-DOS,Packer,Torben_Paving,2:234/41
-00CA,Arc-Binkley,Archimedes,Mailer,Geoff_Riley,2:250/208
-00CB,Roser,MS-DOS,Packer,Chan_Kafai,6:700/158
-00CC,UU2,MS-DOS,Packer,Dmitri_Zavalishin,2:5020/32
-00CD,NMS,MS-DOS,Packer/mailer,Michiel_de.Bruijn,2:285/505.2
-00CE,BBCSCAN,Archimedes,Packer/mailer,E._G._Snel,2:512/222.17
-00CF,XBBS,MS-DOS,Packer,Mark_Kimes,1:380/16
-00D0,LoTek_Vzrul,,Packer/mailer,Kevin_Gates,gates@sasknet.sk.ca,19951229,20000122
-00D1,Private_Point_Project,MS-DOS,Packer,Oliver_von_Bueren,2:301/701
-00D2,NoSnail,MS-DOS,Packer,Eddie_Rowe,1:19/124
-00D3,SmlNet,MS-DOS,Packer,Steve_T._Gove,1:106/6
-00D4,STIR,MS-DOS,Packer,Paul_Martin,2:250/107.3
-00D5,RiscBBS,Archimedes,Packer,Carl_Declerck,2:292/500.10
-00D6,Hercules,Amiga,Packer/mailer,Andrew_Gray,1:231/590
-00D7,AMPRGATE,MS-DOS,Packer/mailer,Mike_Bilow,1:323/120.1
-00D8,BinkEMSI,MS-DOS,Mailer,Tobias_Burchhardt,2:245/39
-00D9,EditMsg,MS-DOS,Packer,G._K._Pace,1:374/26
-00DA,Roof,Amiga,Packer,Robert_Williamson,1:167/104
-00DB,QwkPkt,MS-DOS,Packer,Ross_West,1:250/412
-00DC,MARISCAN,MS-DOS,Packer,Mario_Elkati,2:341/14.9
-00DD,NewsFlash,MS-DOS,Packer,Chris_Lueders,2:241/5306
-00DE,Paradise,MS-DOS,Packer/mailer,Kenneth_Wall,1:300/5
-00DF,DogMatic-ACB,N/A,Packer/mailer,Martin_Allard,2:245/48
-00E0,T-Mail,MS-DOS,Packer/mailer,Andy_Elkin,2:5030/15
-00E1,JetMail,Atari_ST/STE/TT,Packer,Daniel_Roesen,2:243/93.8
-00E2,MainDoor,MS-DOS,Packer/mailer,Francisco_Sedano,2:341/20
-00E3,Starnet_Products,MS-DOS/OS2,Mailer/Packer,Starnet_Software_Development,1:102/925,,19951209
-00E4,BMB,Amiga,Packer,Dentato_Remo,2:335/311.33
-00E5,BNP,MS-DOS,Packer,Nathan_Moschkin,1:109/427
-00E6,MailMaster,MS-DOS,Packer/mailer,Gary_Murphy,1:130/85
-00E7,Mail_Manager_+Plus+,MS-DOS,Packer,Chip_Morrow,1:226/1240
-00E8,BloufGate,Atari_ST/Unix,Packer,Vincent_Pomey,2:320/100.2
-00E9,CrossPoint,MS-DOS,Packer/mailer,Peter_Mandrella,2:2454/97.80,19920713,19960601
-00EA,DeltaEcho,MS-DOS,Packer,Mikael_Staldal,2:201/337
-00EB,ALLFIX,MS-DOS,Packer,Harald_Harms,2:512/145
-00EC,NetWay,Archimedes,Mailer,Steve_Haslam,2:250/116.3
-00ED,MARSmail,Atari_ST,Packer,Folkert_val_Heusden,2:285/750.2,,19940122
-00EE,ITRACK,MS-DOS/OS2,Packer,Frank_Prade,2:2480/55,,19990119
-00EF,GateUtil,MS-DOS,Packer,Michael_Skurka,1:397/2.1
-00F0,Bert,MS-DOS,Packer/mailer,Arnim_Wiezer,2:241/2104.9
-00F1,Techno,MS-DOS,Packer,Patrik_Holmsten,2:203/133
-00F2,AutoMail,MS-DOS,Packer,Mats_Wallin,2:201/239
-00F3,April,Amiga,Packer,Nick_de_Jong,2:282/309.3
-00F4,Amanda,MS-DOS,Packer,David_Douthitt,1:121/99.14
-00F5,NmFwd,MS-DOS,Packer,Alberto_Pasquale,2:332/504
-00F6,FileScan,MS-DOS,Packer,Matthias_Duesterhoeft,2:241/4512.2
-00F7,FredMail,MS-DOS,Packer,Michael_Butler,3:712/515
-00F8,TP_Kom,MS-DOS,Packer/mailer,Per_Sten,2:201/124
-00F9,FidoZerb,MS-DOS,Packer,Ulrich_Schlechte,2:241/3410.12
-00FA,!!MessageBase,MS-DOS,Packer/mailer,Holger_Lembke,2:240/500.20
-00FB,EMFido,Amiga,Packer,Gary_Glendown,2:249/3.999
-00FC,GS-Toss,MS-DOS,Packer,Marco_Bungalski,2:241/2021
-00FD,QWKDoor,Atari_ST,Packer,Christian_Limpach,2:270/20.1
-00FE,No_product_id_allocated,Any,Packer,No_Author,3:3/20
-00FF,16-bit_product_id,Any,Packer/Mailer,No_Author,3:3/20
-0100,Reserved,None,None,No_Author,3:3/20,19951209
-0101,The_Brake!,Mailer,John_Gladkih,2:5051/16,19951209
-0102,Zeus_BBS,Amiga,Mailer,Alex_May,2:441/58.0,19951209
-0103,XenoPhobe-Mailer,Msdos/Windows/OS2/Linux,Mailer,Peter_Kling,1:374/969.0,19951209
-0104,None,None,None,None,0:0/0,
-0105,Terminate,Msdos/Os2/Windows,Mailer/Packer,SerWiz_Comm_&_Bo_Bendtsen,2:254/261,19951209
-0106,TeleMail,Msdos,Mailer/Packer,Juergen_Weigelt,2:2453/900,19951209
-0107,CMBBS,Msdos/Os2,Mailer/Packer,Christof_Engel,2:2490/5110,19951209
-0108,Shuttle,Windows,Mailer/Packer,MCH_Development_&_Marvin_Hart,1:106/500,19951209
-0109,Quater,Amiga,Mailer,Felice_Murolo,2:335/206,19951209
-010A,Windo,Windows,Mailer,Alan_Chavis,1:147/55,19951209
-010B,Xenia,Msdos/Os2,Mailer,Arjen_Lentz,2:283/512,19960601
-010C,GMS,AmigaOS,Mailer,Mirko_Viviani,2:331/213,19960601
-010D,HNET,Msdos,???,Pedro_Jaramillo,1:102/160,19960601
-010E,Shotgun_Professional,Msdos,???,Brent_Shellenberg,1:140/146,19960621
-010F,SLIPgate,Msdos,???,Kieran_Morrissey,3:634/376,19960723
-0110,BBBS,MSDOS/OS2/NT/Amiga/Unix,Mailer/Packer,Kim_Heino,2:22/222,19980216
-0111,NewsGate,Windows/NT,Packer/Gateway,Leilo_denna_Pietra,2:335/244,19980216
-01FF,BBBS,MSDOS/OS2/NT/Amiga/Unix,Mailer/Packer,Kim_Heino,2:22/222,19980216
-02FF,NewsGate,Windows/NT,Packer/Gateway,Leilo_denna_Pietra,2:335/244,19980216
-03FF,Ravel,Macintosh,Mailer/Packer,Cyril_Moorzin,2:5030/700,19980310
-04FF,Beemail,Windows,Mailer/Packer,Andrius_Cepaitis,2:470/1,19980310
-05FF,QuickToss,DOS,Packer,Sandra_Godinez,1:387/601.3,19980310
-06FF,SpaceMail,???,Mailer,Andreas_Habicht,2:244/6121,19980710
-07FF,Argus,Windows/NT,Mailer,Max_Masyutin,2:469/84,19990216
-08FF,Hurricane,Windows/NT/Solaris,Packer,Paul_Walker,2:254/175.44,19990216
-09FF,Hub_Mailer,OS2,Mailer,Viatcheslav_Odintsov,2:5020/181,19990216
-0AFF,FDInt,MSDOS,Packer,Colin_Turner,2:443/13,19990216
-0BFF,GPMail,OS2,Mailer,Igor_Vanin,2:5030/448,19990216
-0CFF,FTrack,NT/OS2,Tracker,Fyodor_Ustinov,2:5020/79,19990313
-0DFF,Nice_Tosser,DOS/OS2/Win32,Tosser,Robert_Agababyan,2:5020/234.1,19990518
-0EFF,LuckyGate,DOS/OS2/Linux,Packer,Pavel_Gulchouck,2:463/68,19990709
-0FFF,McMail,DOS,Mailer,Simon_Slater,2:443/777,20000102
-
- -BackGo Back - - - - diff --git a/html/ftsc/index.htm b/html/ftsc/index.htm index 83cf89e8..b59d462d 100644 --- a/html/ftsc/index.htm +++ b/html/ftsc/index.htm @@ -12,15 +12,16 @@
-
Last update 13-Jul-2003
+
Last update 11-Jan-2004

Fidonet Technical Standards

Introduction

This is an overview of used documents for the development of the MBSE BBS package. Note that there are more documents, but only the relevant and valid -documents are present here. Also note that these documents are just imported -into html documents without any changes. +documents are shown present here. The documents are not available in this +distribution anymore, you can get these from the FTSC +website.

Michiel Broek.

@@ -28,55 +29,55 @@ Michiel Broek.

FSC Documents

FSP Documents

FTA Documents

FTS Documents

diff --git a/html/known_bugs.html b/html/known_bugs.html index 1a4576ae..49c1c5f4 100644 --- a/html/known_bugs.html +++ b/html/known_bugs.html @@ -14,7 +14,7 @@
-
Last update 09-Nov-2003
+
Last update 11-Jan-2004

MBSE BBS - Known bugs.

There are always more bugs, but these are known.... @@ -29,6 +29,9 @@ slow links and over PPP. This is not a MBSE BBS problem. sessions and you use a session password you must also set a mail password and these passwords must be the same. This is a side effect of the way FTS-0001 handshake works, by sending a small mail packet wich contains the password. + +
  • Some Linux distributions have their glibc libraries compiled wrong, that +will cause the mbtask program to do nothing usefull. BackGo Back diff --git a/html/setup/global.html b/html/setup/global.html index 651919ff..362d6f95 100644 --- a/html/setup/global.html +++ b/html/setup/global.html @@ -14,7 +14,7 @@
    -
    Last update 28-Dec-2003
    +
    Last update 11-Jan-2004

    MBSE BBS Setup - Global Setup

    In this setup you can edit all global settings for MBSE BBS. All sections will @@ -368,33 +368,7 @@ XX,CM and TCP/IP systems (internet) should use the XX,CM,IBN,IFC flags. Max. MBytes Maximum MBytes to request, 0 is unlimited -

    1.15. FTPD Settings.

    -

    -A new program is mbftpd. This is a replacement for the normal -ftp server for GNU/Linux with special futures for MBSE BBS. This is not working -yet and is not included in the distribution. Setting it up is adviced. -

    -Upload pth        Incoming files (ie. /opt/mbse/ftp/incoming).
-Banner msg        The banner file to display before login.
-Path filter       The legal character in upload filenames.
-Path msg          Message to display if illegal characters in upload.
-Email addr        Your email address.
-Shutdown          Shutdown message if FTP server is closed.
-Readme login      Readme to display after login.
-Readme cwd*       Readme to display after chdir.
-Msg login         Welcome message after login.
-Msg cwd*          Message to display in directory.
-Userslimit        Maximum FTP users allowed.
-Loginfails        Maximum login failures.
-Compress          If compress command is allowed.
-Tar               If tar command is allowed.
-Mkdir ok          If users may create directories.
-Log commands      Log user commands.
-Anonymous         If anonymous login is allowed.
-User mbse         If user mbse is allowed. Dangerous!
-
    - -

    1.16. Edit HTML pages setup.

    +

    1.15. Edit HTML pages setup.

    Here you setup the HTML pages that can be created with the mbfile web command. These are HTML pages of your download @@ -411,23 +385,13 @@ there is no user authentication yet available. Link to ftp The link to the ftp directory. URL name The URL of your webserver. Charset The default character set, ISO-8859-1. -Table color The tables background color. -Header color The tables header background color. Author name The author name you want in the HTTP headers. Convert command The graphics convert command. (ImageMagick needed). Files/page The number of files to display per web page. -Icon Home The name of the Home icon file. -Text Home The text to display for Home. -Icon Back The name of the Back icon file. -Text Back The text to display for Back. -Icon Prev. The name of the Previous page icon file. -Text Prev. The text to display for Previous page. -Icon Next The name of the Next page icon file. -Text Next The text to display for Next page.

    -

    1.17. Manager flag Descriptions.

    +

    1.16. Manager flag Descriptions.

    In this menu you can give the 32 area-/filemgr flags a meaningfull description.